On 6/18/06, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> It seems to me then, that language acceptable to Maxima must either be
> altered to be unambiguous, or we restrict ibase.
Well, I don't know about that. Maxima already has a mechanism to
force the interpretation of an input as a symbol rather than an integer
(namely a leading backslash). Floats can be distinguished by
putting an explicit decimal point. Dunno about bigfloats.
Even if disambiguation is imperfect, being able to input in bases > 10
can still be useful in some circumstances, and therefore we ought to allow it.
For example, keys, signatures, etc for encryption are large integers which
are often represented in base 16. Since Maxima is already a pleasant
environment for working with big integers, it would be very nice to allow
base 16 input.
For the record here is a reimplementation of ascii-numberp
and some examples. Note the use of the trailing decimal point
to indicate an integer in base 10; this is a useful Lisp-ism inherited
by Maxima.
(defun ascii-numberp (putative-digit)
(and
(characterp putative-digit)
(find
(char-downcase putative-digit)
(subseq "0123456789abcdefghijklmnopqrstuvwxyz" 0 *read-base*))))
(%i5) ibase : 16;
(%o5) 16
(%i6) 100;
(%o6) 256
(%i7) ddb36d4874312374824c36336a7aeaff;
(%o7) 294691024729178307052832132857585134335
(%i8) ff00;
(%o8) 65280
(%i9) \ff00;
(%o9) ff00
(%i10) symbolp (%);
(%o10) true
(%i11) obase : 16. ;
(%o11) 10
(%i12) %o7;
(%o12) DDB36D4874312374824C36336A7AEAFF
(%i13) integerp (%);
(%o13) true
(%i14) foo;
Incorrect syntax: oo is not an infix operator
foo;
^
(%i14) \foo;
(%o14) foo
(%i15) %o7 ^ 2;
(%o15) BFFF48711A961B6226778636F05D6A2BFE3E28E79B6A7BFDF7CF3B39FEC32A01
(%i16) ibase : 10. ;
(%o16) A
(%i17) %o15;
(%o17) BFFF48711A961B6226778636F05D6A2BFE3E28E79B6A7BFDF7CF3B39FEC32A01
(%i18) obase : 10. ;
(%o18) 10
(%i19) %o15;
(%o19)
86842800055933180499672050140245958196094653067807268462301167072379995892225
FWIW
Robert Dodier