Well, I think we can agree that
(a) you can't please everyone
and
(b) people are unlikely to read ANY manual.
I believe that Maple, for a long time, used only decimal floating-point
arithmetic. They may still use decimal floating point for bigfloats. One way
of doing this is to take some clump of bits and use them for some clump of
digits.
E.g take 10 bits, which is good for 0 to 1024, and use it for 0 to 999. or
take 30 bits and use it for 0 to 999 999 999 .
This doesn't waste a lot of bits.
It however slows down computation unacceptably if you are worried about
getting hammered by (say) Mathematica on numerical efficiency.
So people use hardware floats in Maple when they say evalhf instead of evalf
[or some such distinguishing mark].
I think that Jay is suggesting, in the discussion here about decimal vs.
binary, that if everything is done in decimal, then nothing needs to be
explained about arithmetic, since it is just the same as "by hand". This is
perhaps true if you are doing infinite precision (that is, it grows as wide
as necessary on each operation)...
(a) addition
(b) multiplication
(c) raising to a positive integer power [i.e. multiplication]
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
decimal.
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?
Now I will concede that doing some things in decimal for a 5th grader would
possibly deflect the need for explanation, but not for one that knew about
(say) repeating decimals.
There is a literature on exact real arithmetic that might be viewed as an
alternative to decimal... See
J. Vuillemin, Exact Real Computer Arithmetic with Continued Fractions, IEEE
Transactions on Computers, v.39 n.8, p.1087-1105, August 1990
Or use google to find other stuff.
But it is not going to be fast.
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
Anecdote: a long time ago I encountered, in a "children's" science museum,
a computer demonstration device that was about the size of a modern ATM
machine. It challenged children to type into the keypad two numbers, and it
would multiply them and display the answer (maybe using NIXIE tubes? I
forget the details). I suppose the thoughtless designers figured that kids
would type in 4 x 3 and see 12. Of course the kids I saw typed large
more-or-less random numbers. The answers were, to me, obviously wrong
because there were not enough digits computed or displayed. And even worse,
it didn't even matter because the kids would not have any independent
confirmation that the product was right or wrong. So after banging on the
keypads some more they just wandered off to some other possibly brain-dead
"science" display.
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Jay Belanger
> Sent: Wednesday, April 11, 2007 11:34 AM
> To: maxima at math.utexas.edu
> Subject: Re: [Maxima] strange behaviour with simple decimals
>
>
> "Andrey G. Grozin" <A.G.Grozin at inp.nsk.su> writes:
> ...
> >> If Maxima adheres to standards which allow 3*1.4^2 to not quite be
> >> 5.88, in other words if Maxima can't quite correctly do fifth grade
> >> arithmetic, is that good enough?
> > I *strongly* disagree.
>
> To what? To a question?
>
> > If you use a floating-point number 1.4, it cannot be
> represented by a
> > finite-length binary,
>
> No, but it can be represented by a finite-length decimal, which is how
> it is entered, as a matter of fact.
>
> > and operations on it will produce approximate results due to
> > rounding errors.
>
> Which make things more efficient, but aren't necessary.
>
> > I think it would be *extremely* stupid (though possible, of
> course) to use
> > decimal arithmetics in a CAS. Why base 10?
>
> Is that a serious question? You must be joking.
>
> > Why not 12? Or 16? Or anything else?
>
> It's possible, if perhaps inefficient, to have a program deal with any
> base.
>
> > 10 does not stand out in any way (2 does).
>
> Base 10 most certainly does stand out.
> While other bases have their uses, I would guess most people enter
> data in base 10.
>
> It may well be the case that getting small errors when doing decimal
> arithmetic is an acceptable cost, but it was previously implied that
> it is a silly thing to talk about. I disagree. What's more, I think
> that if getting small errors when computing 1.4^2 is the cost of using
> Maxima, the manual should clearly state that.
>
> Jay
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>