Maths error

[Nick Maclaren]

In article <Xns98B3A00749D6tim111one at 216.196.97.136>,
Tim Peters <tim.one at comcast.net> writes:
|> 
|> Huh.  I don't read it that way.  If it said "numbers can be ..." I 
|> might, but reading that way seems to requires effort to overlook the 
|> "decimal" in "decimal numbers can be ...".

I wouldn't expect YOU to read it that way, but I can assure you from
experience that many people do.  What it MEANS is "Numbers with a
short representation in decimal can be represented exactly in decimal
arithmetic", which is tautologous.  What they READ it to mean is
"One advantage of representing numbers in decimal is that they can be
represented exactly", and they then assume that also applies to pi,
sqrt(2), 1/3 ....

The point is that the "decimal" could apply equally well to the external
or internal representation and, if you aren't fairly clued-up in this
area, it is easy to choose the wrong one.

|> >|>> and how is decimal no better than binary?
|>  
|> >|> Basically, they both lose info when rounding does occur.  For
|> >|> example, 
|> 
|> > Yes, but there are two ways in which binary is superior.  Let's skip
|> > the superior 'smoothness', as being too arcane an issue for this
|> > group,
|> 
|> With 28 decimal digits used by default, few apps would care about this 
|> anyway.

Were you in the computer arithmetic area during the "base wars" of the
1960s and 1970s that culminated with binary winning out?  A lot of very
well-respected numerical analysts said that larger bases led to a
faster build-up of error (independent of the precision).  My limited
investigations indicated that there was SOME truth in that, but it
wasn't a major matter; I never say the matter settled definitively.

|> > and deal with the other.  In binary, calculating the mid-point
|> > of two numbers (a very common operation) is guaranteed to be within
|> > the range defined by those numbers, or to over/under-flow.
|> >
|> > Neither (x+y)/2.0 nor (x/2.0+y/2.0) are necessarily within the range
|> > (x,y) in decimal, even for the most respectable values of x and y.
|> > This was a MAJOR "gotcha" in the days before binary became standard,
|> > and will clearly return with decimal.
|> 
|> I view this as being an instance of "lose info when rounding does 
|> occur".  For example,

No, absolutely NOT!   This is an orthogonal matter, and is about the
loss of an important invariant when using any base above 2.

Back in the days when there were multiple bases, virtually every
programmer who wrote large numerical code got caught by it at least
once, and many got caught several times (it has multiple guises).
For example, take the following algorithm for binary chop:

while 1 :
    c = (a+b)/2
    if f(x) < y :
        if c == b :
            break
        b = c
    else :
        if c == a :
            break
        a = c

That works in binary, but in no base above 2 (assuming that I haven't
made a stupid error writing it down).  In THAT case, it is easy to fix
for decimal, but there are ways that it can show up that can be quite
tricky to fix.


Regards,
Nick Maclaren.