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
|> 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.
More information about the Python-list