2009/7/8 John M McIntosh <[email protected]>: > > On 7-Jul-09, at 6:40 PM, Nicolas Cellier wrote: > >> I'm waiting the answer why 1.3*1.3 is different from 169/100. When >> you'll have discovered this, we'll talk about 13/10 = 1.3 on more >> serious bases. >> >> Nicolas > > Well for Fraction I do (1.3*1.3 ) asApproximateFraction (169/100) > because people have expectations about (1.3*1.3) = 169/100 > the same expectations they likely had for (1/10) = 0.1 > > noting that > (1/10) = 0.1 false > (1/10) = (0.1 asApproximateFraction) true > > > Personally I think here the issue is more what the different smalltalk > think and do for various float to faction conversions > not perhaps what is correct. Unless of course you want to drop any > numerical compatibility? >
Hi John, I missed this one, Yes, numerical compatibility is an issue and I'm fighting to restore it. FYI, Smalltalks are just not compatible at very first step: converting literal decimals to Float... This is because conversion algorithms cumulate several rounding errors... ... all with a different algorithm... ... and because of ANSI laxism about implementation. I corrected Integer>>asFloat, Fraction>>asFloat, Number>>readFrom: and maybe a few others to obtain a uniform behaviour: round to the nearest Float (IEEE 754 default mode round to nearest even). I proposed patches to Squeak/Pharo, gst, Dolphin, ST/X and VW, AFAIK they are integrated in Pharo, gst, Dolphin; partially in Squeak. All is MIT, so other dialects just have to cherry pick. Concerning the exact vs inexact comparison, I raised the subject regularly on various mailing list, but yes it would be great to come to an agreement. Its on the pending bugfix list for Squeak 3.11 at least and Paolo has an opened issue for gst i think. Nicolas _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
