On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote: > 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 :-)
:-) yes I understand that point too :) So please continue to discuss that we understand the deep pros and cons. I think this is extremely healthy Stef > > > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
