2009/7/8 danil osipchuk <danil.osipchuk@gmail.com>:
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.
+1 me too Code like '(13/10) = 1.3' just jumps at you if you have been bitten by this before. In languages of APL Â branch (which are traditionally used for intensive calculations) the comparison of real numbers is 'tolerant': that is two numbers are considered equal if their relative difference is less than some predefined small value: Â a = b isTrue if: Â |a-b|/max(a,b) < Epsilon
Sorry, I can't help talking :) Of course, this model does not preserve good properties like = being transitive. a := 1.0 - (0.5*Epsilon). b := 1.0. c := 1.0 + (0.5*Epsilon). self assert: (a = b) & (b = c) ==> (a = c). So I'd rather stick to a keyword selector like fuzzyEqual: Again, this definition corresponds more to an Interval arithmetic model. RealInterval >> fuzzyEqual: b ^(self intersectionWith: b) notEmpty Smalltalk has both exact (Integer/Fraction/ScaledDecimals) and inexact (Float) arithmetic, and the semantic of = will vary from exactEqual: to fuzzyEqual:. RealInterval >> exactEqual: b "always false, if a or b are inexact" ^a isExact and: [b isExact and: [a bounds exactEqual: b bounds]] RealInterval >> isExact "self is exact if Card(self) = 1" ^a bounds min exactEqual: a bounds max Don't confuse with = that could simply mean that they represent the same interval RealInterval >> = b ^a bounds exactEqual: b bounds I did not care much of polymorphism (coercion, double dispatching or whatever), but you get the idea. You can also use probability distributions if it better fits your model, but mathematical background might be a bit short... Nicolas
http://www.jsoftware.com/help/primer/tolerance.htm http://jsoftware.com/help/dictionary/d000.htm
Creators of these languages put a lot of considiration into this and it I think they got it right. It may be too radical to redefine comparison of real values in Smalltalk (although it still makes sense to do so in practical terms) but the discussed test is just a blind shot into a sky. The user should be discouraged to rely on a such comparison.
regards, Â Danil
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project