Maths error

Nick Maclaren nmm1 at cus.cam.ac.uk
Sat Jan 13 11:13:09 CET 2007


In article <mailman.2685.1168670120.32031.python-list at python.org>,
"Hendrik van Rooyen" <mail at microcorp.co.za> writes:
|> 
|> *grin* - I was around at that time, and some of the inappropriate habits
|> almost forced by the lack of processing power still linger in my mind,
|> like - "Don't use division if you can possibly avoid it, - its EXPENSIVE!"
|> - it seems so silly nowadays.

Yes, indeed, but that one is actually still with us!  Integer division
is done by software on a few systems, and floating-point division is
often not vectorisable or pipelines poorly.  But, except for special
cases of little relevance to Python, it is not the poison that it was
back then.

|> As an old slide rule user - I can agree with this - if you know the order
|> of the answer, and maybe two points after the decimal, it will tell you
|> if the bridge will fall down or not. Having an additional fifty decimal
|> places of accuracy does not really add any real information in these
|> cases.  Its nice of course if its free, like it has almost become - but
|> I think people get mesmerized by the numbers, without giving any
|> thought to what they mean - which is probably why we often see
|> threads complaining about the "error" in the fifteenth decimal place..

Agreed.  But the issue is really error build-up, and algorithms that are
numerically 'unstable' - THEN, such subtle differences do matter.  You
still aren't interested in more than a few digits in the result, but you
may have to sweat blood to get them.

|> > [*] Assuming signed magnitude, calculate the answer truncated towards
|> > zero but keep track of whether it is exact.  If not, force the last
|> > bit to 1.  An old, cheap approximation to rounding.
|> >
|> This is not so cheap - its good solid reasoning in my book -
|> after all, "something" is a lot more than "nothing" and should
|> not be thrown away...

The "cheap" means "cheap in hardware" - it needs very little logic,
which is why it was used on the old, discrete-logic, machines.

I have been told by hardware people that implementing IEEE 754 rounding
and denormalised numbers needs a horrific amount of logic - which is
why only IBM do it all in hardware.  And the decimal formats are
significantly more complicated.

What I don't know is how much precision this approximation loses when
used in real applications, and I have never found anyone else who has
much of a clue, either.


Regards,
Nick Maclaren.



More information about the Python-list mailing list