ok, but can you be sure that your objects are not handling floats? maybe the same code handles floats when you want speed and fractions when you want precision, I remember we did that once but I don't remember if we had to compare the numbers... I understand your point and I agree with you that erratic behavior should be avoided as much as possible, new programmers always get confused when two floats print the same but return false when compared, but do you agree with me that this new behavior make floats "less polymorphic" with numbers? and code more odd?... you see, people will have the same question as me, why (13/10) = 1.3 returns false but (1/2) = 0.5 returns true? Maybe the solution has to be more drastic, and if we want to avoid people for comparing floats for equality, just not let them or return false always... or take the other road as Smalltalk had after now, that is: make the implementation detail as hide as possible, and if the programmer really cares about representation problems let him compare the numbers with a difference... Smalltalk has almost 30 years old and I have not seen any big problem related to comparing numbers, so why changing that? what do we gain with the change?... I'm still not sure that this change is for the better :-)
On Tue, Jul 7, 2009 at 5:18 PM, Nicolas Cellier < [email protected]> wrote: > IMO no one should rely on (13/10) = 1.3, not even on (13/10) asFloat = 1.3. > Once you introduced a Float, you'd better forget about exact equality. > > Do you expect 1.3*1.3 ~= 1.69 ? > I think it's better like this, because you learn to not overtrust > Float equality. > You learn quicker that you should not rely on it. > > However if you give me real examples where this behaviour matters, my > ears and eyes are wide open. > > cheers > > Nicolas > > > P.S. there is an even more extreme solution: (1/2) ~= 0.5 because an > exact and an inexact representation cannot be compared exactly. > > 2009/7/7 Hernan Wilkinson <[email protected]>: > > Hi Nicolas, > > thank you for your answer. I'm aware of the float representation > problems. > > But this new behavior sounds more confusing, at least to me... I mean, > 1.3 > > is not a number with representation problems so why do we have to make > this > > difference? I understand you are trying to avoid the problems sometimes > > floats generate, but I think that doing so we are loosing some > abstraction > > from the number representation type. > > Correct me if I wrong, but doesn't this new behavior means that always, > in > > any number comparison, we need to coerse the number to float? Because 1.3 > > asFraction = (13/10) returns false but 1.3 = (13/10) asFloat returns > true... > > I mean, if we have a = b and the values of those variables are calculated > by > > some process such that a is 1.3 and b is 13/10, the comparison will not > > work, so we need to explicitly write "a asFloat = b asFloat" just in case > > any of those variables reference a float, even though none of them will > ever > > do... but then "(1/2) = 0.5" returns true... I don't know, I don't like > it > > that much... > > > > On Tue, Jul 7, 2009 at 3:56 PM, Nicolas Cellier > > <[email protected]> wrote: > >> > >> Hi Hernan, > >> This is the new Behavior of Float comparison and it is desired. > >> > >> 1) 1.3 is represented in machine as > >> (1.3 significandAsInteger printStringRadix: 2) , '.0e' , (1.3 exponent > >> - Float precision + 1) printString. > >> -> '2r10100110011001100110011001100110011001100110011001101.0e-52' > >> > >> Or if you prefer: > >> (1.3 asTrueFraction numerator printStringBase: 2) , '/' , (1.3 > >> asTrueFraction denominator printStringBase: 2). > >> -> > >> > '10100110011001100110011001100110011001100110011001101/10000000000000000000000000000000000000000000000000000' > >> > >> As you can see, this is quite different from 13/10. > >> > >> However, you can test (13/10) asFloat = 1.3 and that happens to be > >> true, but that won't always be true. > >> > >> 2) comparing Float with strict equality is a dangerous game. Floating > >> point operation are inherently inexact and thus asserting an exact > >> equality is considered a bad practice. > >> > >> 3) basing comparisons and equality tests on inexact arithmetic rather > >> than on exact arithmetic leads to weird behaviours. See > >> http://bugs.squeak.org/view.php?id=3374 > >> > >> > >> So i do not consider this fragment of code alone as a bug but as a > >> feature. > >> There might be some code depending on the old behaviour that can > >> eventually break. > >> If you have such an example in true application, I'm interested. > >> I think we'd better fix such code to not rely on exact equality... > >> > >> Cheers. > >> > >> Nicolas > >> > >> > >> > >> 2009/7/7 Hernan Wilkinson <[email protected]>: > >> > I added this new issue that happens on the latest image. > >> > I'm posting it here because I think it is an important bug because it > >> > affects the number model. > >> > The problem is related with all fractions who's denominator is not > power > >> > of > >> > two. (130/100 = 1.3 or 1/5 = 0.2, etc) > >> > (See > >> > > >> > Float>>adaptToFraction: rcvr andCompare: selector where it does > >> > .... > >> > "Try to avoid asTrueFraction because it can cost" > >> > selector == #= ifTrue: [ > >> > rcvr denominator isPowerOfTwo ifFalse: [^false]]. > >> > > >> > ...) > >> > > >> > > >> > Hernan. > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ > > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
