July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Andres Valloud

Hernan, floating point values are fractions of the form +/- m * 2^k for positive integers m of up to a certain number of bits. Your example requires 13/10 = m * 2^k which is not possible. In slow motion... 2^k = 13/10m To get rid of 13, m must be 13*n... 2^k = 1/10n Now, 1/10 = 1/5 * 1/2, so... 2^{k+1} = 1/5n and then we reach n 2^{k+1} = 1/5 which is absurd for integer n, k. Andres. Hernan Wilkinson wrote: > 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. > > >

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/7 Ignacio Vivona <altobarba(a)gmail.com>: > The float problem is an implementation problem that i really dont care, i > only want fast float operations when doing heavy calculation or 3D or > something like that ... 1.3 should gimme an object modeling a real number > OK concerning fast, that's not the main talent of Squeak, but yes, it could be worse with ScaledDecimals. OK, an object modelling a real number, inexactly, is what you get, so i do not see the problem. Float representation is independant of the language and most likely hardwired in your processor. Whether it is exactly equal to (13/10) or not is an implementation detail you should not bother with... ... until you try to attempt an exact equality test, but why would you? Because you know the tradeoff is fast but inexact, you will rather use something like (13/10) closeTo: 1.3, or better, provide your own tolerance. If you say you expect (13/10) = 1.3 exactly, then i say your expectations are different: you want an exact representation, at the price of longer computations, that's the deal. The fact that Smalltalk let you the choose is already a great thing. Last time I tried (13/10) == 1.3 in C, it was false :) Nicolas

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by John M McIntosh

Let me step back and say, ok you are possibly breaking existing code, and causing all sorts of confusion for an optimization change? So where is the justification from the optimization viewpoint? Does it make browser windows open in 1/2 the time? If it takes more time milliseconds? to produce an answer that is what people expect, then t I think it's worth it. Yes I understand that floats are inexact but people think they know how they work thus expect to be able to say (13/10) = 1.3 without having to give clues with asFloat to indicate their intent. Let me see squeak 3.10.x (13/10) = 1.3 true Pharo 1037 (13/10) = 1.3 false VisualWorks (13/10) = 1.3 true I would classify this as a bug On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote: > 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. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 7, 2009

Re: [Pharo-project] FFI problem

by StÃ©phane Ducasse

Mariano I just published in Pharo a new ScriptLoader which I hope fix the problem. Could you check it? Stef On Jul 5, 2009, at 9:05 PM, Mariano Martinez Peck wrote: > Andreas: can you see new comments here: http://code.google.com/p/pharo/issues/detail?id=908 > > What do you think? > > Thanks! > > Mariano > > On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > > wrote: > I crated the issue so that no to forget about it: > > http://code.google.com/p/pharo/issues/detail?id=908 > > Best, > > Mariano > > > On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <andreas.raab(a)gmx.de> > wrote: > Mariano Martinez Peck wrote: > Ok. Pharo people is in this mail. Let's wait if someone can help us. > > Please cc vm-dev on any responses. I'm not subscribed to the Pharo > list. > > > I don't know why in mi Windows machine the dump file is not > generated :( > > It looks like the crash has two different ways of showing. In the > first situation, it crashes with a recursive DNU. In the second, it > actually does generate a crash dump (attached). The latter seems to > happen when you try to step through the code. > > > Benoit St-Jean can you attach the complete dump file? > > I tried this in Linux and it doesn't crash my image. So, only > windows :( > > Difficult to say. There is a good possibility that the problem is > unrelated to the FFI since I have been completely unable to > reproduce the problem elsewhere. > > Cheers, > - Andreas > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Ignacio Vivona

The float problem is an implementation problem that i really dont care, i only want fast float operations when doing heavy calculation or 3D or something like that ... 1.3 should gimme an object modeling a real number On Tue, Jul 7, 2009 at 5:26 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2009/7/7 Ignacio Vivona <altobarba(a)gmail.com>: > > 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? > > > > Hi Ignacio. > If you'd provide a rationale for the behaviour you're proposing we could > argue. > Otherwise my answer would just be speculation. > > If 1.3 is 13/10 explain why 1.3*1.3 is not 169/100. > > As I told before, you should better use ScaledDecimals if you rely on > such assertions. > > Cheers > > Nicolas > > > 2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)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.nice(a)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.wilkinson(a)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(a)lists.gforge.inria.fr > >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Hope is for sissies (Gregory House, M.D.)

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/7 Ignacio Vivona <altobarba(a)gmail.com>: > 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? > Hi Ignacio. If you'd provide a rationale for the behaviour you're proposing we could argue. Otherwise my answer would just be speculation. If 1.3 is 13/10 explain why 1.3*1.3 is not 169/100. As I told before, you should better use ScaledDecimals if you rely on such assertions. Cheers Nicolas > 2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)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.nice(a)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.wilkinson(a)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(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

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 <hernan.wilkinson(a)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.nice(a)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.wilkinson(a)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(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009

Re: [Pharo-project] Just a little point

by StÃ©phane Ducasse

I will look at Testing when I have time and see how we can merge our extension. Some people know on this list that my life was extremely frantic (having one hour to relax over the week-end, or fixing my house until 11'oclock after my daily work for example). Stef >> Pharo continues with a not invented here policy, and has made no >> attempt >> to review the code based for projects that could be mutually >> maintained. >> This is a problem, and I shall continue to point it out until it is >> resolved. It's a mindset issue. >> >> > I would like to make my point in a different polite way. > > If you are the maintainer of a package and, in this multi-fork world, > you would like to maintain a single test suite for both squeak and > pharo, such that all tests run green, then the SUnit in > squeaksource.com/Testing may be for you. > > It was developed for a multi-fork world back in August/Sept 2006. It > allows you to categorise which tests you expect to work on which > platform and which image version. > > It is a multi-fork world out there, why not think it through? > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Ignacio Vivona

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.wilkinson(a)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.nice(a)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.wilkinson(a)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(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Hope is for sissies (Gregory House, M.D.)

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Hernan Wilkinson

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.nice(a)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.wilkinson(a)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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009