[Maxima] strange behaviour with simple decimals
belanger at truman.edu
Wed Apr 11 15:18:23 CDT 2007
"Richard Fateman" <fateman at cs.berkeley.edu> writes:
> Well, I think we can agree that
> (a) you can't please everyone
> (b) people are unlikely to read ANY manual.
And (a) could perhaps be amended to contain "and you can't please
anyone all the time".
> It is not true if you allow division. The simplest example is that you would
> never be able to print out the result of computing 1.0/3.0 exactly in
> So you are reduced to printing some number like 0.33333 . Given that
> result, one might reasonably ask why 0.33333 -1/3 is not zero. Or if it IS
> zero, how could that be? Could the answer really be that you have too many
> or too few 3's in 0.333..33 ?
> Would this require explanation?
I wouldn't think so. But when you can print out things exactly at
every step, as in 3*1.4^2, some explanation (or at least
acknowledgement that you might not get what you expect) might be useful.
> So where does that leave us:
> 1. Maybe extract what is worthwhile in this stream and put it in an appendix
> to the maxima manual and leave the program alone?
> 2. Maybe implement (perhaps re-re-implement) or import some exact real
> arithmetic package and use it for 5th grade arithmetic? An implementation
> and a list of references is http://keithbriggs.info/xrc.html
> (I have not checked this particular system.)
> 3. Use interval arithmetic instead of floats.
> 4. Maybe hack the program to do something whose deficiencies are more
> subtle, like Mathematica's attempt to implement "significance" arithmetic, a
> system which nearly defies explanation because, among other things, 0. is
> used to mean "I don't know if this is non-zero.".
> My preference is choice 1, then choice 2, more remotely possible, choice 3,
> and never choice 4
I agree with all that (for what it's worth).
More information about the Maxima