Re: Really strange problem, for very bright people

--- In [email protected], "Stephen Wood" 
<swood@i...> wrote:
> I understand that clearly, but what I'm failing to understand is 
how the
> following occurs...
> 
> 1.035 * 4.32765 * 1.673
> 
> gives different answers to
> 
> 1.673 * 1.035 * 4.32765 and 4.32765 * 1.673 * 1.035
> 
> They are the same numbers, just in a different sequence....

Whether what I am about to write will make things any clearer, I 
don't know.  It won't really say anything new, but it is an attempt 
to put a different emphasis thatn others have done.

*******
*******

Suppose you are using a calculator that works in decimal to 2 
significant figures, and you work out 5.5 * 0.6 * 0.3, in that order.

5.5 * 0.6 gives 3.3, which has only 2 significant figures, so no 
rounding takes place.  Then 3.3 * 0.3 gives 0.99, which is the 
correct answer.

********

Now suppose you do the calculation in the order 5.5 * 0.3 * 0.6.

5.5 * 0.3 gives 1.65, and multiplying this by 0.6 would still give 
0.99, but you don't actually do this, because 1.65 gets rounded to 2 
significant figures, either 1.6 or 1.7. Let's suppose you round up 
(which seems to be the usual method taught in schools these days, at 
least in Britain).  Then you actually work out 1.7 * 0.6 = 1.02, NOT 
the correct answer of 0.99.

*********
*********

Thus you see that the order of working can make a difference to the 
result.  The point is that the number of figures reached at 
INTERMEDIATE points in the working out can vary depending on the 
order of cacluations, even though the FINAL result would be the same 
if worked out exactly.

****************************

In a previous post the question was raised 'how is a developer 
supposed to understand in what order to write the calculations, 
unless the bug actually manifests itself?'

Two points here:
(1) There is a surprisingly large literature on the subject of how to 
arrange the order of calculations to minimise problems.  It mostly 
dates back to the very early days of computers.  On the whole though, 
the effort is usually not worth it.  Really the best thing is to 
realise that floating point arithmetic is by its nature inexact, and 
not to expect theoretically zero answers to be exactly zero.  99.99% 
of the time this is adequate.  If you really do have calculations 
where this is not acceptable, don't use floating point.  This is the 
reason for the existence of the 'currency' type.  However, this has a 
small and fixed number of decimal places.  There are other methods of 
doing exact arithmetic, but you would have to consult textbooks on 
numerical methods. 

(2) This is NOT a bug: it is how floating point arithmetic is 
supposed to work.

Michael Davis


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Low on Ink? Get 80% off inkjet cartridges & Free Shipping at 77Colors.com.
We have your brand: HP, Epson, Lexmark, Canon, Compaq and more!
http://www.c1tracking.com/l.asp?cid=5981
http://us.click.yahoo.com/DmnqpB/IyhGAA/ySSFAA/i7folB/TM
---------------------------------------------------------------------~->

CodeCoffer - new Delphi code protection Tool!
http://www.delphicollection.com/public/CodeCoffer.htm
---------------------------------------------------------------
Unsubscribe:[email protected]
List owner:[email protected]
--------------------------------------------------------------- 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/