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

Re: [Pharo-project] Issue 941: adding class methods fails

by Johan Brichau

that's issue 941 (not 942) sorry On 08 Jul 2009, at 00:46, Johan Brichau wrote: > Hi, > > Adding (new) class methods fails in latest image. > I described the problem and proposed a fix attached to issue 942 > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

July 7, 2009

[Pharo-project] Issue 941: adding class methods fails

by Johan Brichau

Hi, Adding (new) class methods fails in latest image. I described the problem and proposed a fix attached to issue 942 ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

July 7, 2009

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

by Nicolas Cellier

On the other hand, asRational and asFraction are quite synonym to me. asFraction might as well be implementation dependent... And asRational can be interpreted this way only for historical reasons (st80). I want either a short approximated fraction like (13/10), or an exact fraction. Nicolas 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > On the other hand, VW already has asRational, and it doesn't do what > asFraction does. Â To some extent, I think #asExactFraction and selectors > like that are misleading. Â Why would anyone want #asImpreciseFraction, > or #asRationalMoreOrLess... > > Nicolas Cellier wrote: >> 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 >>> >>> >> . >> >> > > _______________________________________________ > 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

2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > 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 > Except the polymorphism argument, this is more a principle of inertia. "Why did you change the browser, I want it back..." IMO, Smalltalk had not so many problems because it is not used for number crunching. Financial apps use ScaledDecimal where due and avoid the problem. I used it for crunching numbers, but I feel a bit alone :) Concerning polymorphism, I hope I demonstrated this is a false polymorphism because you get non transitive equality and numbers not well ordered. Anyway: | a b | a = 13/10. b= a asFloat. self assert: (a = b) ==> (a squared = b squared). self assert: (a = b) ==> (a fractionPart = b fractionPart). etc... They behave differently, really. Concerning (0.5) ~= (1/2) that might be a good idea. What stopped me was the implications it would have on inequality tests... 0.5 < (1/2). -> false 0.5 = (1/2). -> false 0.5 > (1/2). -> false So they are unordered... I prefer 0.5 = (1/2). -> true strategy mainly for this reason. Nicolas

July 7, 2009

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

by Nicolas Cellier

2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > 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 :-) > > Well, we are going to lack of arguments and just repeat ourselves :) It is for the better because it makes comparison a full order relation ship and equality transitive. | a b c | a := 13/10. b := a asFloat. c := b asTrueFraction. a < c self asssert: (a = b) & (b = c) ==> (a == c). self asssert: (a < c) & (b = c) ==> (a < b). It is also better because your learn sooner to not be surpised by 1.3*1.3 ~= 1.69. You should know that lispers (lots of grey bearded) were better behaved than us, long before us. See http://www.lispworks.com/documentation/lcl50/aug/aug-170.html That's not a definitive argument, but a good clue. Concerning (1/2) ~= 0.5, Andres suggested that once, why not. This is explicitely possible to implement Scheme with this rule. I gave you some examples that are not hypothetical: I've been caught 15 years ago with this kind of bad behaviour. I now would like to see real examples rather than just expectations based on bad habits. Nicolas

July 7, 2009

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

by Andres Valloud

On the other hand, VW already has asRational, and it doesn't do what asFraction does. To some extent, I think #asExactFraction and selectors like that are misleading. Why would anyone want #asImpreciseFraction, or #asRationalMoreOrLess... Nicolas Cellier wrote: > 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] SUnit assert:equals:

by Michael Roberts

No you understand certainly, I wasn't clear. If we provide a nice api for comparing things are equal it would be a shame to not provide the convenience for doubles. Newcomers to the environment would not necessarily understand the pitfalls of testing equality on doubles. Thus providing convenience in one area could look very attractive in the general case if there are no other methods hinting their appropriate use. I'm sure such a method has already been written in a repository somewhere . I just thought it would be good to put them in together. That make sense? Mike On Tuesday, July 7, 2009, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > Hi Mike, > > I don't understand. Â assert:equals: should only be used for exact > equality tests, not for comparing doubles. > > Doubles should never go through this method. > > Existing tests won't know about assert:equals: > > Did I misunderstand you? > > - on > > On 7 Jul 2009, at 19:24, Michael Roberts wrote: > >> If you are adding this it would be good to either add or review >> existing implementation that checks the comparison is within a >> tolerance. This would be for asserting double values are close but not >> necessarily exact. I would rather we didn't get double comparison >> going through this method you describe which would be easy to do. >> >> Thanks >> mike > > > _______________________________________________ > 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 Andres Valloud

The answer is true on 7.6, and I don't think anything changed that for 7.7. Historical background aside, I think it's wrong anyway... in the hash book, exercise 7.20 asks to find two different fractions that are equal to the same float. In other words, if f is a float, and r1 and r2 are fractions, then r1 ~= r2 but r1 = f and r2 = f. And those do exist... Andres. StÃ©phane Ducasse wrote: > 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] 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