Why not the opposite? The default behavior is 13/10 = 1.3 yields true and the new behavior (13/10) asFloat = 1.3 equals false. This kind of behavior is a real pain in languages like java, i are you bringing this to the smalltalk world?
2009/7/7 Hernan Wilkinson <hernan.wilkin...@gmail.com> > 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 < > nicolas.cellier.aka.n...@gmail.com> 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 <hernan.wilkin...@gmail.com>: >> > 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 >> > 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Hope is for sissies (Gregory House, M.D.)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
