[Maxima] changing floating point number input.. (was realroots...)
Sun Aug 27 12:21:59 CDT 2006
I agree with you about the possibility of this auto-annoyance; I would tend
to put down an extra decimal digit or two to benefit accurate
decimal-to-binary conversion of constants.
For example, using an exponent marker that INSISTS on making a double-float,
even if there are too many explicit digits? For example, allow 1.234.....d0
to mean something different from 1.234.....E0?
I'm not sure how important it is for most people to know that they have a
Programs that require the input to be a double-float should, if handed a
bigfloat, convert it to a double-float.
So the test could be "convert to bigfloat if it is out of range, or
(there are too many explicit digits and the exponent marker is not "d" or
This activity on input does not address the situation where floating
computation overflows to infinity instead of to a bigfloat. That's asking
for trouble in compiled/declared code, and pretty much unsupportable in most
> -----Original Message-----
> From: Raymond Toy [mailto:raymond.toy at ericsson.com]
> Sent: Sunday, August 27, 2006 10:01 AM
> To: Richard Fateman
> Cc: 'maxima'
> Subject: Re: [Maxima] changing floating point number input..
> (was realroots...)
> >>>>> "Richard" == Richard Fateman <fateman at cs.berkeley.edu> writes:
> Richard> Effects: if you put too many digits in a number like
> Richard> 1.234567890123456789012345e0, then you will get
> a bigfloat. If your program
> I think I'd be annoyed with this because sometimes I WANT a
> float, not a bigfloat, and having to count digits to make
> sure it's not auto-annoyingly converted to bigfloat is not
> nice. Yes, I could type float(<lot 'o digits>), but that's
> annoying too.
> Richard> doesn't work with bigfloats, this might be a problem.
> Richard> if you put too large an exponent, e.g.
> 1.234e600, instead of getting an
> Richard> error, you get a bigfloat.
> This is less annoying, and I could live with this.
More information about the Maxima