2009/7/8 Nicolas Cellier <[email protected]>: > 2009/7/7 John M McIntosh <[email protected]>: >> Let me step back and say, ok you are possibly breaking existing code, >> and causing all sorts of confusion for an >> optimization change? So where is the justification from the >> optimization viewpoint? Does it make browser >> windows open in 1/2 the time? >> >> If it takes more time milliseconds? to produce an answer that is what >> people expect, then t I think it's worth it. >> Yes I understand that floats are inexact but people think they know >> how they work thus expect to be able to say >> (13/10) = 1.3 without having to give clues with asFloat to indicate >> their intent. >> >> Let me see >> squeak 3.10.x (13/10) = 1.3 true >> Pharo 1037 (13/10) = 1.3 false >> VisualWorks (13/10) = 1.3 true >> >> I would classify this as a bug >> >> > > I repeat here my arguments: > Anyone depending on (13/10) = 1.3 is plain wrong... > +1. I dealt with 3D rendering/linear algebra using floats in the past , and i can say just one: - never write the code which compares the floats to be equal to some exact value. It makes no sense in practice, because of inexact nature of floats. For instance, i remember the code i wrote, to test whether two vectors perpendicular: float := n1 * n2 (where n1 , n2 - is line normals, and * - is dot product).
As we know, if two vectors is perpendicular, then their dot product is zero. But it is almost always non-zero on hardware, especially when you transform vectors or compute them using data, which already contains a degree of precision error! So, i learned that comparing dot product with zero makes no sense, instead you'd better test it with something like: abs(float) < epsilon where epsilon is very small number. So, i don't understand, why its so important for such kind of equality tests to work right at all - because you hardly will use such tests in practice. > Either you want fast and inexact floating point operation and should > not rely on exact equality (use #closeTo:). > Or you want (13/10) = 1.3 EXACTLY, and then should better use ScaledDecimal. > That's the deal, and it's quite independant from the language. > > The false assertions that people are trying to push does not matter: > it's high time to educate. > My proposition has at least the merit to put a light on these > dangerous floating point strict equality tests > (I saw so many bugs like testing cos(pi/2) == 0). > > And I'm still waiting for the hypothetical application that would > break because of this change. > That's the main point of interest. > In this case, we'll see if patching is necessary and easy. > > Nicolas > > P.S. concerning behaviour of conversion binary<->decimal > representation, I'm rather the one trying to unify Smalltalk. > Dolphin, gst and Pharo adopted some of my changes to behave as exactly > as we can, and thus behave the same. > Try this in your prefered dialect, I guess you will have some surprise. > 123.4567890123d3 = (1234567890123/10000000). > 123.4567890123d3 = (1234567890123/10000000) asFloat. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
