pseudo-base-prime as a field schema

If we take the additive identity as {}, the multiplicative identity as {1}, define addition as vector addition, and define multiplication via the squid operator (see previous posts), we can define a field (actually, a schema that accomodates a countably infinite number number of fields):
First, addition is associative and commutative, as it is just vector addition.
If we allow the exponents of the base-P number to be integers instead of just 0 or a natural number, we can have negative exponents,
such that {a,b,c,...} has a unique additive inverse {-a,-b,-c,...}. This also gives closure under addition.
For a multiplicative inverse, we have to allow at least one exponent to be a real number. In order to have unique multiplicative inverses, we must set some restrictions: only one specific exponents can be a real (the rest must be integers)---so, we could have a field using {R,Z,Z,Z,...}, a field using {Z,R,Z,Z,...}, a field using {Z,Z,R,Z,...}, etc. Thus, we have a schema and can definite a countably infinite number of possible fields from this.
It's probably also possible to set other restrictions, such as allowing only one (but any one exponent) to be a real, so that for {a,b,c,d,...}, only one of a,b,c,d,... is a real, and the remaining are integers. Another thought would be to define a restrictive relationship such that more than one exponent could be non-integral but still maintain unique multiplicative inverses. I haven't explored this, but it may be possible to construct an uncountably infinite number of possible restrictive relationships (since I suspect the relationships would have to be equalities or inequalities of a form such that one of the constants in the relationship is a real number, giving an uncountable infinite number of possible equalities/inequalities).
So, if we define our field to have {R,Z,Z,Z,...}, the multiplicative inverse {b,0,0,0,...} for A={a1,a2,a3,a4,a5,...} would be (I believe -- I tested it for a few simple cases, namely {1}, {0,1}, and {1,1}, but I think it could be proved to be a general case) {log(2)/(a1*log(2)+a2*log(3)+a3(log(5)+a4*log(7)+a5(log(11)+...),0,0,0,...}.
The only thing remaining is distributivity:
Recall what squid(a,b), our multipicative operation, produces for {a1,a2,a3,...} and {b1,b2,b3,...}:
It is (I think) {a1*b1,a2*b1+a1*b2,a3*b1+a2*b2+a3*b1,...}.
If we want to test (c+d)*b = c*b+d*b, let a={c1+d1,c2+d2,c3+d3,...}.
Then the left-hand side would be {c1*b1+d1*b1,c2*b1+d2*b1+d1*b2+c1*b2,c3*b1+d3*b1+c2*b2+d2*b2+c3*b1+d3*b1,...}
The right hand side is {c1*b1,c2*b1+c1*b2,c3*b1+c2*b2+c3*b1,...}+{d1*b1,d2*b1+d1*b2,d3*b1+d2*b2+d3*b1,...}, which we see to be identical
once the two lists undergo the additive operation.

pseudo-base-prime part...5?

More base-prime stuff.  I extended the bc code; there are function names matching the HP User-RPL programs, and the size of the array is stored as element 0
(Excluding a row/column pair; then it's the row in element 0 and the column in element 1)
Collapse )
Some new developments, too... run-length encoding, and converting a base-prime number to a binary string (which can in turn be evaluated as a normal number, for further pattern-finding)
Collapse )