2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/7/7 John M McIntosh <johnmci@smalltalkconsulting.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.