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

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

by Adrian Lienhard

The reason that ifNil: is not found is that it is inlined. If you view the bytecode representation of an ifNil: send, you see that this message is never sent. The search looks for symbols in the literal frame of compiled methods and hence does not find this special case. Cheers, Adrian On Jul 8, 2009, at 05:52 , Mariano Martinez Peck wrote: > 2009/7/7 Cameron Sanders <camsanders01(a)roadrunner.com> > >> On Jul 7, 2009, at 7:39 PM, Mariano Martinez Peck wrote (below my >> original >> text): >> >> can you give us a concrete example? >> >> In my opinion, if you have a symbol with that text, it must be >> found by >> "senders of it". In VAST it is like that. >> So, if you have #ifNil: for me it is correct to be found. >> >> best, >> >> Mariano >> >> >> What you say makes sense for performance reasons. I just picked >> through >> those 10 methods more carefully, and they each contain the symbol >> #ifNil:, >> so the one error I thought I was seeing (of a match for a pattern of >> xxxIfNil:) is not what is causing them to be found. So, I'm glad >> you asked, >> as that forced me to recheck that aspect. Should it be called >> "search->methods referencing symbol (n)" or something -- I don't >> care about >> pesky details like that. >> > > You are welcome. > > > >> >> What matters to me is the failure to find my references/sends: >> >> My broken method (FaTableAccessor>>columnAt:) is just one of *many* >> places >> I have used #ifNil:, and is NOT being found. >> >> The search is only finding 10 methods in the entire system (in the >> classes >> Decompiler, MessageNode, MethodFinder, OCompletionTable, PSUIManager, >> RBMessageNode, RBProgramNode) that reference the symbol #ifNil:. >> >> Previously, this feature has worked for me as expected (to the best >> of my >> knowledge). But I can't guarantee that I have ever searched for >> #ifNil:. >> >> I just searched for collect:, and that turned up a more reasonable >> 1092 >> methods, some of which are mine. I am surprised there are not more >> uses of >> it, but at least it is a more credible number than "10". So maybe >> it is just >> something weird for the symbol ifNil:, which I can live with; that >> would >> make this a low priority issue, assuming it is working for most other >> symbols pretty well. >> > > Perhaps a lot of people does isNil ifTrue: instead of ifNil: hahaha > > >> >> Recap: I am selecting "ifNil:" (without the quotes) in a workspace, >> and >> using "extended search"->"senders of it (n)"; this is failing to find >> methods of mine that include the symbol (as a selector). >> > > Can you give me an example of your code that containg ifNil: and > that's is > not being found ? just to test it here. > > cheers, > > Mariano > > >> Happy Hunting, >> Cam >> >> >> >> On Tue, Jul 7, 2009 at 6:32 PM, Cameron Sanders < >> camsanders01(a)roadrunner.com> wrote: >> >>> 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=sendeifNilrs&colspec=… >>> <http://code.google.com/p/pharo/issues/detail?id=261&q=senders&colspec=ID%20… >>> > >>> >>> Thanks in advance, >>> Cam >>> >>> _______________________________________________ >>> 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 8, 2009

Re: [Pharo-project] FFI problem

by Benoit St-Jean

Retested the FFI stuff.. All tests are green and my ODBC stuff works again! Thanks to all! Un gros merci Ã tous! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Mariano Martinez Peck <marianopeck(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, July 7, 2009 6:52:22 PM Subject: Re: [Pharo-project] FFI problem Ok, now you can close http://code.google.com/p/pharo/issues/detail?id=908 in 10372 On Tue, Jul 7, 2009 at 6:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>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 > > >>_______________________________________________ >>Pharo-project mailing list >Pharo-project(a)lists.gforge.inria.fr >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com.

July 8, 2009

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

by Mariano Martinez Peck

2009/7/7 Cameron Sanders <camsanders01(a)roadrunner.com> > On Jul 7, 2009, at 7:39 PM, Mariano Martinez Peck wrote (below my original > text): > > can you give us a concrete example? > > In my opinion, if you have a symbol with that text, it must be found by > "senders of it". In VAST it is like that. > So, if you have #ifNil: for me it is correct to be found. > > best, > > Mariano > > > What you say makes sense for performance reasons. I just picked through > those 10 methods more carefully, and they each contain the symbol #ifNil:, > so the one error I thought I was seeing (of a match for a pattern of > xxxIfNil:) is not what is causing them to be found. So, I'm glad you asked, > as that forced me to recheck that aspect. Should it be called > "search->methods referencing symbol (n)" or something -- I don't care about > pesky details like that. > You are welcome. > > What matters to me is the failure to find my references/sends: > > My broken method (FaTableAccessor>>columnAt:) is just one of *many* places > I have used #ifNil:, and is NOT being found. > > The search is only finding 10 methods in the entire system (in the classes > Decompiler, MessageNode, MethodFinder, OCompletionTable, PSUIManager, > RBMessageNode, RBProgramNode) that reference the symbol #ifNil:. > > Previously, this feature has worked for me as expected (to the best of my > knowledge). But I can't guarantee that I have ever searched for #ifNil:. > > I just searched for collect:, and that turned up a more reasonable 1092 > methods, some of which are mine. I am surprised there are not more uses of > it, but at least it is a more credible number than "10". So maybe it is just > something weird for the symbol ifNil:, which I can live with; that would > make this a low priority issue, assuming it is working for most other > symbols pretty well. > Perhaps a lot of people does isNil ifTrue: instead of ifNil: hahaha > > Recap: I am selecting "ifNil:" (without the quotes) in a workspace, and > using "extended search"->"senders of it (n)"; this is failing to find > methods of mine that include the symbol (as a selector). > Can you give me an example of your code that containg ifNil: and that's is not being found ? just to test it here. cheers, Mariano > Happy Hunting, > Cam > > > > On Tue, Jul 7, 2009 at 6:32 PM, Cameron Sanders < > camsanders01(a)roadrunner.com> wrote: > >> 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=sendeifNilrs&colspec=…<http://code.google.com/p/pharo/issues/detail?id=261&q=senders&colspec=ID%20…> >> >> Thanks in advance, >> Cam >> >> _______________________________________________ >> 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 8, 2009

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

by Andres Valloud

In the end, perhaps the issue is: * When users see 1.3, they think decimal floating point. * When programmers see 1.3, they should think binary floating point, but would like to assume decimal floating point. At the end of the day, insisting on seeing 1.3 as decimal floating point runs contrary to what the hardware is doing (I don't know what Groovy's implementation is). This should not be an issue of liking or not liking because we don't get to rewrite or reinterpret the IEEE-754 standard to match our preferences. Ignacio Vivona wrote: > I like Groovy: > 1.3 == 13/10 -> true > 1.3*1.3 == 169/100 -> true > 0.1 == 1/10 -> true > 9.9999731e20 < 9.9999730e20 -> false > 0.5 == 1/2 -> true > > > 2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com > <mailto:hernan.wilkinson@gmail.com>> > > ok, let me start again. > 1) I created the issue because 13/10 = 1.3 works different in the > new pharo image that in vw, va, dolphin, squeak and the previous > pharo version, so I thought it was a bug > 2) I understand that comparing floats is not good and I also > understand the representation problems of floats > 3) I'm in favor of making changes. Changes are needed to make > progress although not all changes make progress > > But, Nicolas when you say > > Anyone depending on (13/10) = 1.3 is plain wrong... > I do not completely agree. You say that because you are thinking > like a programmer and you know that 1.3 is a float, but if you ask > the same question to an accountant, engineering, etc. they will > say that 13/10 is equal to 1.3. So, outside computers, 13/10 is > equal to 1.3, the same as 1/2 equals to 0.5 and so on. > Dan Ingalls followed a good design principle: to hide as much as > possible implementation details from the user and that is why > Smalltalk has such a great Number model that I did not see in > another language. > From my point of view, the implementation you are providing is not > quite following this principle or at least is making the float > representation problem more evident. If the last is the intention, > I think it should be consistent (i.e. 1/2 = 0.5 should return > false also) and provide specific messages to handle that decision too. > Or maybe the change has to be more profound, maybe changes like > the one suggested by Michael van der Gulik > are necessary, maybe we have to print ScaledDecimals as float are > printed now and print floats with a special representation to make > evident that is not a "normal" number... > > Anyway, as I said before, I'm not sure this change is a good > decision, time will tell I guess, those are my two cents. > Bye, > Hernan > > > > > On Tue, Jul 7, 2009 at 7:37 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com > <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: > > 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > <mailto:stephane.ducasse@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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto: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.)

July 8, 2009

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

by Nicolas Cellier

2009/7/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > ok, let me start again. > 1) I created the issue because 13/10 = 1.3 works different in the new pharo > image that in vw, va, dolphin, squeak and the previous pharo version, so I > thought it was a bug > 2) I understand that comparing floats is not good and I also understand the > representation problems of floats > 3) I'm in favor of making changes. Changes are needed to make progress > although not all changes make progress > But, Nicolas when you say >> Anyone depending on (13/10) = 1.3 is plain wrong... > I do not completely agree. You say that because you are thinking like a > programmer and you know that 1.3 is a float, but if you ask the same > question to an accountant, engineering, etc. they will say that 13/10 is > equal to 1.3. So, outside computers, 13/10 is equal to 1.3, the same as 1/2 > equals to 0.5 and so on. Well, I happen to program, but my base job is engineer. And I want my engineers to be aware of such problem and not rely on (cos(pi/2)==0). > Dan Ingalls followed a good design principle: to hide as much as possible > implementation details from the user and that is why Smalltalk has such a > great Number model that I did not see in another language. On the other hand, it confuses users and then abuse them. This is because the implementation is not neutral but strongly influence the behavior. Every one expects (13/10)=1.3, but the fact is that is not true, these are two different numbers. Try (1.3) fractionPart = (13/10) fractionPart asFloat in Pharo VW Squeak etc... Pretending they are the same is fragile. The model cracks quite fast. > From my point of view, the implementation you are providing is not quite > following this principle or at least is making the float representation > problem more evident. If the last is the intention, I think it should be > consistent (i.e. 1/2 = 0.5 should return false also) and provide specific > messages to handle that decision too. Yes but you then have (0.5,1/2) unordered and probably break more code. Current implementation is a compromise that reflects that these numbers can casually have equal representation. We'd better not lie about what the hardware really does. > Or maybe the change has to be more profound, maybe changes like the one > suggested byÂ Michael van der Gulik > are necessary, maybe we have to print ScaledDecimals as float are printed > now and print floats with a special representation to make evident that is > not a "normal" number... Well, Newspeak wanted to follow that route and use ScaledDecimal in first place. But then there are speed tradeoffs... Unfortunately, the stream of money has vanished before we get experimental results... > Anyway, as I said before, I'm not sure this change is a good decision, time > will tell I guess, those are my two cents. > Bye, > Hernan > That's true that this is an important change of the semantic of equality. It's reasonnable to doubt, and I thank you for raising the subject, this was necessary. Your opinion is as valuable as mine: inexact equality leads to a simpler model for the user, least surprising because hiding gorry details. I prefer a better mathematical model (= transitive etc...) and to advertise soon about dangers of Float. I say other communities have this behaviour for long (lisp scheme) and it's worth a try . It is also very easy to revert anyway, just replace adaptToXXX:andCompare: with adaptToXXX:andSend:. I have given enough arguments and should let other people express their opinion without fearing an agressive response :) Nicolas

July 8, 2009

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

by Ignacio Vivona

I like Groovy: 1.3 == 13/10 -> true 1.3*1.3 == 169/100 -> true 0.1 == 1/10 -> true 9.9999731e20 < 9.9999730e20 -> false 0.5 == 1/2 -> true 2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > ok, let me start again.1) I created the issue because 13/10 = 1.3 works > different in the new pharo image that in vw, va, dolphin, squeak and the > previous pharo version, so I thought it was a bug > 2) I understand that comparing floats is not good and I also understand the > representation problems of floats > 3) I'm in favor of making changes. Changes are needed to make progress > although not all changes make progress > > But, Nicolas when you say > > Anyone depending on (13/10) = 1.3 is plain wrong... > I do not completely agree. You say that because you are thinking like a > programmer and you know that 1.3 is a float, but if you ask the same > question to an accountant, engineering, etc. they will say that 13/10 is > equal to 1.3. So, outside computers, 13/10 is equal to 1.3, the same as 1/2 > equals to 0.5 and so on. > Dan Ingalls followed a good design principle: to hide as much as possible > implementation details from the user and that is why Smalltalk has such a > great Number model that I did not see in another language. > From my point of view, the implementation you are providing is not quite > following this principle or at least is making the float representation > problem more evident. If the last is the intention, I think it should be > consistent (i.e. 1/2 = 0.5 should return false also) and provide specific > messages to handle that decision too. > Or maybe the change has to be more profound, maybe changes like the one > suggested by Michael van der Gulik > are necessary, maybe we have to print ScaledDecimals as float are printed > now and print floats with a special representation to make evident that is > not a "normal" number... > > Anyway, as I said before, I'm not sure this change is a good decision, time > will tell I guess, those are my two cents. > Bye, > Hernan > > > > > On Tue, Jul 7, 2009 at 7:37 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> 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 >> >> _______________________________________________ >> 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 8, 2009

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

by Cameron Sanders

> On Jul 7, 2009, at 7:39 PM, Mariano Martinez Peck wrote (below my > original text): > can you give us a concrete example? > > In my opinion, if you have a symbol with that text, it must be found > by "senders of it". In VAST it is like that. > So, if you have #ifNil: for me it is correct to be found. > > best, > > Mariano What you say makes sense for performance reasons. I just picked through those 10 methods more carefully, and they each contain the symbol #ifNil:, so the one error I thought I was seeing (of a match for a pattern of xxxIfNil:) is not what is causing them to be found. So, I'm glad you asked, as that forced me to recheck that aspect. Should it be called "search->methods referencing symbol (n)" or something -- I don't care about pesky details like that. What matters to me is the failure to find my references/sends: My broken method (FaTableAccessor>>columnAt:) is just one of *many* places I have used #ifNil:, and is NOT being found. The search is only finding 10 methods in the entire system (in the classes Decompiler, MessageNode, MethodFinder, OCompletionTable, PSUIManager, RBMessageNode, RBProgramNode) that reference the symbol #ifNil:. Previously, this feature has worked for me as expected (to the best of my knowledge). But I can't guarantee that I have ever searched for #ifNil:. I just searched for collect:, and that turned up a more reasonable 1092 methods, some of which are mine. I am surprised there are not more uses of it, but at least it is a more credible number than "10". So maybe it is just something weird for the symbol ifNil:, which I can live with; that would make this a low priority issue, assuming it is working for most other symbols pretty well. Recap: I am selecting "ifNil:" (without the quotes) in a workspace, and using "extended search"->"senders of it (n)"; this is failing to find methods of mine that include the symbol (as a selector). Happy Hunting, Cam > > > On Tue, Jul 7, 2009 at 6:32 PM, Cameron Sanders <camsanders01(a)roadrunner.com > > wrote: > 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=sendeifNilrs&colspec=… > > Thanks in advance, > Cam > > _______________________________________________ > 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 8, 2009

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

by Hernan Wilkinson

ok, let me start again.1) I created the issue because 13/10 = 1.3 works different in the new pharo image that in vw, va, dolphin, squeak and the previous pharo version, so I thought it was a bug 2) I understand that comparing floats is not good and I also understand the representation problems of floats 3) I'm in favor of making changes. Changes are needed to make progress although not all changes make progress But, Nicolas when you say > Anyone depending on (13/10) = 1.3 is plain wrong... I do not completely agree. You say that because you are thinking like a programmer and you know that 1.3 is a float, but if you ask the same question to an accountant, engineering, etc. they will say that 13/10 is equal to 1.3. So, outside computers, 13/10 is equal to 1.3, the same as 1/2 equals to 0.5 and so on. Dan Ingalls followed a good design principle: to hide as much as possible implementation details from the user and that is why Smalltalk has such a great Number model that I did not see in another language. >From my point of view, the implementation you are providing is not quite following this principle or at least is making the float representation problem more evident. If the last is the intention, I think it should be consistent (i.e. 1/2 = 0.5 should return false also) and provide specific messages to handle that decision too. Or maybe the change has to be more profound, maybe changes like the one suggested by Michael van der Gulik are necessary, maybe we have to print ScaledDecimals as float are printed now and print floats with a special representation to make evident that is not a "normal" number... Anyway, as I said before, I'm not sure this change is a good decision, time will tell I guess, those are my two cents. Bye, Hernan On Tue, Jul 7, 2009 at 7:37 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009

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

by John M McIntosh

On 7-Jul-09, at 4:09 PM, John M McIntosh wrote: > self should: [self storedEntry = 0.1]. > > because > (1/10) = 0.1 => false I should note the test is slightly wrong because storedEntry is a fraction and I should be testing for 1/10 and somewhere in the 100 or so other tests I'm check for issues with float to fraction conversions. Where as mentioned in a later note I use asApproximateFraction in the proper places to avoid conversion errors. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 8, 2009

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

by John M McIntosh

On 7-Jul-09, at 6:40 PM, Nicolas Cellier wrote: > I'm waiting the answer why 1.3*1.3 is different from 169/100. When > you'll have discovered this, we'll talk about 13/10 = 1.3 on more > serious bases. > > Nicolas Well for Fraction I do (1.3*1.3 ) asApproximateFraction (169/100) because people have expectations about (1.3*1.3) = 169/100 the same expectations they likely had for (1/10) = 0.1 noting that (1/10) = 0.1 false (1/10) = (0.1 asApproximateFraction) true Personally I think here the issue is more what the different smalltalk think and do for various float to faction conversions not perhaps what is correct. Unless of course you want to drop any numerical compatibility? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 8, 2009