paul c wrote [on the TTM list]:
Heh, not to criticize Darren's support for different bases but far more important to me is decimal support so that 0.1 + 0.2 = 0.3!
Philip Kelly wrote [on the TTM list]:
i don't know about any other particular bases but surely it is simpler to have arbitrary bases rather than four particular ones?
Just to clarify, the actual number values themselves are still radix agnostic; by default all real numbers are canonically either big-integers or a ratio of 2 of said, and so are exact precision; so a literal in base N will be parsed into a ratio whose denominator is a power of said base, notwithstanding subsequent coprime simplification. So the example would be represented as 1/10 + 1/5 = 3/10 (base-10) or 0b1/0b1010 + 0b1/0b101 = 0b11/0b1010 (base-2), which are the same post-parse values. The reason for the 4 particular bases is that they have well-known radix identifiers, such that: 0b101 = 5 0o101 = 65 # Perl 6 and Muldis D support that; 0101 otherwise well-known 0d101 = 101 # both syntaxes supported 0x101 = 257 # the A..F is often case-insensitive, I support A..F=a..f here In order to support a more general case we need to come up with or use a syntax that is not relatively well-known. Perl 6 uses :M<N> where the M is a base-10 number saying what base we have and the N is the literal proper; for example: :2<101> :8<101> :10<101> :16<101> The :A<B> sytax is derived from a more general Perl 6 specific design of that indicating a pair of 2 values A and B, the ":" is a mnemonic indicating "pair" with the 2 dots. Currently Muldis D uses this less verbose M;N general syntax: 1;101 7;101 9;101 F;101 The design choice was a matter of purity, where the radix specifier itself is written in the same base as what it is specifying; the radix specifier is the highest column value that the base allows, so "1" for binary, etc. This design limits to base 36 (eg, Z;101 = 1297 = :36<101>) for this format in both cases, because no other characters are defined to represent column values. Perl 6 also extends with something like this: :100[54,3,65] = 540365 ... and Muldis D can't support that unless it gives up the aforementioned purity idea where the parts are in a different base. But the last format truly goes all the way, letting you use *any* base 2+. So I figure, practically speaking, Muldis D has 3 options, which are: 0. Don't change anything. 1. Just add a syntax analogous to :M[N,N,N] which can go all the way. 2a. Just drop the purity that I held onto and specify the radix in base 10. 2b. Do both 2a and 1. So what do you think or is there another option you care to mention. No matter what, I plan to keep the 5 N, O[bodx]N options. And 0N will never be supported to mean octal, even if it is well known, because its a bug magnet. -- Darren Duncan _______________________________________________ muldis-db-users mailing list muldis-db-users@mm.darrenduncan.net http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
