Not a solution.
6E1 is 60.0
If ibase is (decimal) 15 or more, then 6E1 is also an
integer.
Also many variable names are ambiguously either names or numbers.
For example, e^f could be 14^15 in decimal.
It seems to me then, that language acceptable to Maxima must either be
altered to be unambiguous, or we restrict ibase.
Commercial Macsyma says this about ibase:
"
The base for inputting numbers. The value assigned to this variable
must be an integer between 2 and 36 inclusive. If IBASE is assigned a
value greater than 10, Macsyma provides no way to specify digits above
9. This does not affect floating-point numbers or bigfloats.
"
-----Original Message-----
From: maxima-admin at math.utexas.edu [mailto:maxima-admin at math.utexas.edu] On
Behalf Of Robert Dodier
Sent: Sunday, June 18, 2006 3:46 PM
To: van Nek
Cc: Maxima at math.utexas.edu
Subject: Re: [Maxima] ibase and obase
On 6/18/06, van Nek <van.nek at arcor.de> wrote:
> (%i6) 6F;Incorrect syntax: F is not an infix operator
> 6F;
> ^
> (%i6) 6E;
> Incomplete number. Missing exponent?
> This tells me that 6F and 6E should work, or do I misunderstand the
> documentation?
It should work. The observed behavior is a bug.
Maxima's parser calls common-lisp:read-from-string to convert strings
like "1234" into integers. read-from-string is happy enough with
stuff like 6e but the Maxima parser barfs before it gets to
read-from-string.
A solution is to make the Maxima parser happy with 6e, etc.
I don't think any revision of stuff downstream of that is needed.
Probably there would need to be some special notation to help
the parser distinguish integers from floats and symbols.
I can't think of anything at the moment.
Robert Dodier
_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima