>> >> 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 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 >> [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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
