- Pharo-dev - lists.pharo.org

Re: [Pharo-project] VM & Exupery

by Bryce Kampjes

On Mon, 2009-07-06 at 17:38 -0400, Cameron Sanders wrote: > What are the best places (documentation sources) to get started > exploring and learning the VM code (the generated C) and Exupery? > > I am running on an iMac and would be willing to try to get Exupery > working on it. This conversation has moved to the Exupery list which is more suitable. http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery Bryce

July 7, 2009

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

by Nicolas Cellier

2009/7/7 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > 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 > > I repeat here my arguments: Anyone depending on (13/10) = 1.3 is plain wrong... 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.

July 7, 2009

[Pharo-project] [ANN] 10372 and 10373

by StÃ©phane Ducasse

10372 ScriptLoader loadFFI should work please check better comment on ScriptLoader http://code.google.com/p/pharo/issues/detail?id=637 cleans out Undeclared 10373 Issue 943: fix polymorph cursor Polymorph Fix for colouring of submenu markers. W2K Improvements. Fix for drop-list button label in W2K theme. Support for adjustment of label inset for buttons when pressed. Added #setColor: to ColorPresenterMorph to enable use without a model. Quit gets back its normal behavior Issue 944: SUnit assert:equals SUnit assert equals + better feedback message Strange the cursor for submenu does not work... Next probably MouseOverHandler refactoring.... Stef

July 7, 2009

[Pharo-project] extended search -> senders of it (n) - defect?

by Cameron Sanders

Having made some bozo statements lately, I am hesitant to even inquire (because I am probably doing something dumb), but... I noted an error in my code that read xxx isNumber ifNil: [...] and figured that when I imported in from VisualWorks, I must have "fixed" things too hastily. Wondering where else I may have made this error I did the following on an iMac using the 10371web image recently posted: In a workspace I typed and highlighted "ifNil:" --without the quotes of course-- and selected "extended search...". Then I selected "senders of it (n)", and to my surprise, not my erroneous method was not displayed in the results. Ten (10) methods turn up in the results, and some of them are not actually senders of it; the non-senders may include the pattern in an array, or as a substring of some symbol. Is this a known defect? Previously (from images two months ago and less) this searching worked as expected. A search of the defect db, using only the word "senders", gave me this (semi-related) issue: http://code.google.com/p/pharo/issues/detail?id=261&q=senders&colspec=ID%20… Thanks in advance, Cam

July 7, 2009

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

by Nicolas Cellier

Hi Andres, That's great to see this addition, but it would have been even greater to call this method #asExactFraction or #asTrueFraction to get some minimal core API with other dialects... Anyway, you see the kind of arguments you'll have to provide if you ever want to follow the path you once proposed... Cheers Nicolas 2009/7/7 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > VisualWorks introduced LimitedPrecisionReal>>asFraction. Â That message > returns the actual floating point value represented by the receiver. Â Of > course, I messed up and forgot * self sign... but that's the idea (and > it's fixed for 7.7). Â So, in reality, you should compare > > 13/10 = 1.3 asFraction > > which will answer false, like it should. > > Andres. > > > John M McIntosh wrote: >> 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 >> = >> = >> = >> ======================================================================== >> >> >> >> >> >> _______________________________________________ >> 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] Issue 940: (13/10) = 1.3 returns false

by StÃ©phane Ducasse

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 <nicolas.cellier.aka.nice(a)gmail.com > > 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 <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 > > > > _______________________________________________ > 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] FFI problem

by StÃ©phane Ducasse

On Jul 7, 2009, at 11:20 PM, Mariano Martinez Peck wrote: > Stef: Yes, it works. But, I have some questions: > > 1) Is it ok to have > > self new installer monticello http: > 'source.squeakfoundation.org'; ??? > > or it is just temp ? In addition, why was #squeakfundation removed ? > this is because now all is here: source.squeakfoundation.org??? If > so, we can create a method for this new repository... It is temporary. First I would say that FFI should have a loader doing the initialization properly. Second we will probably have a new loader in the near future. > 2) I don't know what Smalltalk recreateSpecialObjectsArray. specialObjectsArray is an array known by the VM > But older version of FFI worked ok and also this version works ok in > Linux...I don't understand why. I do not know :) > Is there a logic here I cannot see ? > Is there a drawback in evaluating Smalltalk > recreateSpecialObjectsArray. ? > > Cheers, > > Mariano > > On Tue, Jul 7, 2009 at 8:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > 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 > > > _______________________________________________ > 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] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

Hi John, There is some misunderstanding here. It just happens that I proposed an optimized implementation, but optimizing was not my goal. My goal was to be able to compare number exactly, that's all. See http://bugs.squeak.org/view.php?id=3374 for funny examples of what happens when comparison is based on inexact conversions. Nicolas 2009/7/7 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > 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 > = > = > = > ======================================================================== > > > > > > _______________________________________________ > 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 StÃ©phane Ducasse

so andres what will be the value of >> (13/10) = 1.3 in VW7.7 On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote: > VisualWorks introduced LimitedPrecisionReal>>asFraction. That message > returns the actual floating point value represented by the > receiver. Of > course, I messed up and forgot * self sign... but that's the idea (and > it's fixed for 7.7). So, in reality, you should compare > > 13/10 = 1.3 asFraction > > which will answer false, like it should. > > Andres. > > > John M McIntosh wrote: >> 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 >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> _______________________________________________ >> 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] Issue 940: (13/10) = 1.3 returns false

by Hernan Wilkinson

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 < nicolas.cellier.aka.nice(a)gmail.com> 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 <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 > > > > _______________________________________________ > 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