Math issue, isn't it?

Mon May 11 16:27:19 EDT 2009

Le 11 mai 09 à 22:09, Colin Holgate a écrit :

>
> On May 11, 2009, at 3:40 PM, Jan Schenkel wrote:
>
>> Scott Raney - the original developer of Metacard, the underlying  
>> engine for Revolution - opted for the better speed of CPU-native  
>> numbers, instead of the byte arithmetic algorithm as implemented in  
>> HyperCard
>
> While that is interesting, HyperCard also has the same math issue.  
> So does Javascript (I know that's not like Java, but you might think  
> that its math was on the same lines):
>
> on mouseUp
> set the numberformat to "#.0000000000000000"
> answer 283.67-150.00-133.67
> end mouseUp
>
> shows an answer of .0000000000000284. This:
>
> <html><script type="text/javascript">alert(283.67-150.00-133.67)</ 
> script></html>
>
> alerts an answer of 2.842170943040401e-14. So it seems like everyone  
> gets it wrong!
>
> For completeness, I tried Java too:
>
> println((283.67-150.00)-133.67);
>
> shows as 1.5258789E-5, so Java is off on its own level of error.
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
my two cents:
if you want arbitrary precision, work with rational numbers (i.e.,  
fractions of integers). All operations only require a finite number of  
bytes to be exact. If you want to represent functions, try to use  
rational operations. For instance, a Lagrange interpolation over a set  
of rational knots (for instance, linear interpolation between two  
points with rational coordinates) are solved by a linear systems with  
rational coefficients, and yields a rational value at rational points;  
therefore, the computations yield exact results (in fractional form).  
If I remember well, this line of thought was followed by Wolfram in  
the implementations of Mathematica that I have come to see.
On the other hand, "numerical packages" like Matlab rely on floating  
point arithmetic; the advantage is that the number of bytes required  
to represent a number is fixed once for all (it does not grow  
dynamically). It is well suited to multiplication, but fails miserably  
on summation when the numbers do not have a "similar" magnitude.

"Infinity is long, especially towards the end"
	Woody Allen (?)