September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] scaled decimal question

by Peter Hugosson-Miller

Yeah, but the *big* difference is that "asScaledDecimal: 2" is a message sent to a Float, whereas the "s2" is just part of the literal representation of a ScaledDecimal, and *not* a message sent to anything. -- Cheers, Peter. On 18 sep 2011, at 17:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > >> 2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> For me the problem is that if >>> >>> "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. >>> >>> a number is a scaled decimal or not. >>> >> >> There is a difference between these two: >> >> (1/10) asScaledDecimal: 2. >> (1/10) asFloat asScaledDecimal: 2. > > That I can understand Float is inexact. No problem with that. > > Now I do not understand how 0.1s2 relates to the above expressions. > > >> asFloat introduces a rounding error. >> Though the result prints 0.1, it is different from (1/10), asFrank >> said, just convert it back asTrueFraction, and you'll see. >> asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. >> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > > > > >> >> Nicolas >> >>> >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >>> >>>> On 17 September 2011 14:06, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>>> Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >>> >>> Sure I guessed that too but I hate this behavior. >>> >>> >>>> Indeed. In particular, the Floats turn themselves into "exact >>>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>>> patterns duplicate the float representation. That means that the >>>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>>> fraction instvars. >>>> >>>> frank >>>> >>>>> -- >>>>> Cheers, >>>>> Peter. >>>>> >>>>> On 17 sep 2011, at 15:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> >>>>>> Why >>>>>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) >>>>>> returns false >>>>>> >>>>>> while >>>>>> >>>>>> 0.1s2 + 0.2s2 = 0.3s2 >>>>>> returns true >>>>>> >>>>>> ? >>>>> >>>>> >>>> >>> >>> >>> >> > >

Sept. 18, 2011

Re: [Pharo-project] scaled decimal question

by Nicolas Cellier

2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > >> 2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> For me the problem is that if >>> >>> Â Â Â Â "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. >>> >>> a number is a scaled decimal or not. >>> >> >> There is a difference between these two: >> >> (1/10) asScaledDecimal: 2. >> (1/10) asFloat asScaledDecimal: 2. > > That I can understand Float is inexact. No problem with that. > > Now I do not understand how 0.1s2 relates to the above expressions. > Ah, because the NumberParser knows you want a ScaledDecimal with the s2 specification, so it just doesn't use an intermediate Float, but directly convert (1/10) asScaledDecimal: 2. You can also try ScaledDecimal readFrom: '0.1', it avoids a an intermediate conversion to Float too. Nicolas > >> asFloat introduces a rounding error. >> Though the result prints 0.1, it is different from (1/10), asFrank >> said, just convert it back asTrueFraction, and you'll see. >> asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. >> If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > > > > >> >> Nicolas >> >>> >>> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >>> >>>> On 17 September 2011 14:06, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>>> Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >>> >>> Sure I guessed that too but I hate this behavior. >>> >>> >>>> Indeed. In particular, the Floats turn themselves into "exact >>>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>>> patterns duplicate the float representation. That means that the >>>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>>> fraction instvars. >>>> >>>> frank >>>> >>>>> -- >>>>> Cheers, >>>>> Peter. >>>>> >>>>> On 17 sep 2011, at 15:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> >>>>>> Why >>>>>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) >>>>>> returns false >>>>>> >>>>>> while >>>>>> >>>>>> 0.1s2 + 0.2s2 = 0.3s2 >>>>>> returns true >>>>>> >>>>>> ? >>>>> >>>>> >>>> >>> >>> >>> >> > > >

Sept. 18, 2011

Re: [Pharo-project] scaled decimal question

by StÃ©phane Ducasse

On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > 2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> For me the problem is that if >> >> "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. >> >> a number is a scaled decimal or not. >> > > There is a difference between these two: > > (1/10) asScaledDecimal: 2. > (1/10) asFloat asScaledDecimal: 2. That I can understand Float is inexact. No problem with that. Now I do not understand how 0.1s2 relates to the above expressions. > asFloat introduces a rounding error. > Though the result prints 0.1, it is different from (1/10), asFrank > said, just convert it back asTrueFraction, and you'll see. > asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. > If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > Nicolas > >> >> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >> >>> On 17 September 2011 14:06, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>> Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >> >> Sure I guessed that too but I hate this behavior. >> >> >>> Indeed. In particular, the Floats turn themselves into "exact >>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>> patterns duplicate the float representation. That means that the >>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>> fraction instvars. >>> >>> frank >>> >>>> -- >>>> Cheers, >>>> Peter. >>>> >>>> On 17 sep 2011, at 15:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>> Why >>>>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) >>>>> returns false >>>>> >>>>> while >>>>> >>>>> 0.1s2 + 0.2s2 = 0.3s2 >>>>> returns true >>>>> >>>>> ? >>>> >>>> >>> >> >> >> >

Sept. 18, 2011

Re: [Pharo-project] scaled decimal question

by StÃ©phane Ducasse

Hi nicolas I'm sure that I understand. In fact I'm totally confused by the name used. >>>>> 0.1s2 is this expression supposed to return a scaled decimal? >>>>> (0.1 asScaledDecimal: 2) what this expression supposed to return? I thought it was a scaled decimal too. So for me as a stupid guy, if both return scaled decimal then I do not get with we get different results. Or the expressions returns soemthing different and in such a case one should be renamed. Or I'm do not understand at all this world. Stef On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: > 2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> For me the problem is that if >> >> "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. >> >> a number is a scaled decimal or not. >> > > There is a difference between these two: > > (1/10) asScaledDecimal: 2. > (1/10) asFloat asScaledDecimal: 2. > > asFloat introduces a rounding error. > Though the result prints 0.1, it is different from (1/10), asFrank > said, just convert it back asTrueFraction, and you'll see. > asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. > If you want to undo the error, you may try (0.1 roundTo: 0.01s2). > > Nicolas > >> >> On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: >> >>> On 17 September 2011 14:06, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>> Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. >> >> Sure I guessed that too but I hate this behavior. >> >> >>> Indeed. In particular, the Floats turn themselves into "exact >>> representations" (Float >> #asTrueFraction) - Fractions whose bit >>> patterns duplicate the float representation. That means that the >>> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >>> fraction instvars. >>> >>> frank >>> >>>> -- >>>> Cheers, >>>> Peter. >>>> >>>> On 17 sep 2011, at 15:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>> Why >>>>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) >>>>> returns false >>>>> >>>>> while >>>>> >>>>> 0.1s2 + 0.2s2 = 0.3s2 >>>>> returns true >>>>> >>>>> ? >>>> >>>> >>> >> >> >> >

Sept. 18, 2011

Re: [Pharo-project] scaled decimal question

by Nicolas Cellier

2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > For me the problem is that if > > Â Â Â Â "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. > > a number is a scaled decimal or not. > There is a difference between these two: (1/10) asScaledDecimal: 2. (1/10) asFloat asScaledDecimal: 2. asFloat introduces a rounding error. Though the result prints 0.1, it is different from (1/10), asFrank said, just convert it back asTrueFraction, and you'll see. asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. If you want to undo the error, you may try (0.1 roundTo: 0.01s2). Nicolas > > On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > >> On 17 September 2011 14:06, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>> Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. > > Sure I guessed that too but I hate this behavior. > > >> Indeed. In particular, the Floats turn themselves into "exact >> representations" (Float >> #asTrueFraction) - Fractions whose bit >> patterns duplicate the float representation. That means that the >> resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing >> fraction instvars. >> >> frank >> >>> -- >>> Cheers, >>> Peter. >>> >>> On 17 sep 2011, at 15:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> Why >>>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) >>>> returns false >>>> >>>> while >>>> >>>> 0.1s2 + 0.2s2 = 0.3s2 >>>> returns true >>>> >>>> ? >>> >>> >> > > >

Sept. 18, 2011

[Pharo-project] Fwd: scaled decimal question

by StÃ©phane Ducasse

Begin forwarded message: > From: Werner Kassens <wkassens(a)libello.com> > Date: September 18, 2011 5:11:59 PM GMT+02:00 > To: StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> > Subject: scaled decimal question > > Hi Stephane, > occasionally i look at the the Pharo-project mailing list and i saw your question re ScaledDecimals. they are Fractions and you can can look at their internal representation by using asFraction. things like 0.1s2 are fractions built from scratch , hence 0.1s2 asFraction returns 1/10 while (0.1 asScaledDecimal: 2) asFraction returns the same thing as 0.1 asFraction. > aFloat asFraction is constructed in such a way that > aFloat asFraction asFloat= aFloat > for every aFloat. At least with a probability of (100 - epsilon)% with epsilon going to 0. while epsilon is not equal to 0 according to the author of asFraction (see the last comment at the end of Float>>asTrueFraction),obviously nobody has as yet found a counterexample, hence i would forget that. > iow (0.1 asScaledDecimal: 2)represents exactly the same number as the float 0.1. > since 0.1 + 0.2=0.3 returns false you would of course expect your first example to return false. and you would expect the error in the equality to be similar to the error in 0.1 + 0.2=0.3. although not necessarily equal. if this last statement does not immediately make sense, you might want to think a second or two about the results of these things: > ((0.1 asFraction ) + (0.2 asFraction))asFloat = (0.1 +0.2) . > ((0.1 asFraction ) + (0.2 asFraction)) = (0.1 +0.2) asFraction . > > werner

Sept. 18, 2011

Re: [Pharo-project] MethodDictionary fast #rehash

by Nicolas Cellier

I'm not quite sure it is correct. The problem is if another Process want to use this MethodDictionary while it is in an inconsistent state... Or if you are rehashing on of the MethodDictionary which contains one of the methods used by the rehashing itself. See recent changes from Levente in trunk. Nicolas 2011/9/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sat, Sep 17, 2011 at 10:26 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2011/9/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi guys. I was checking MethodDictionary >> rehash and this is terribly >> > slow >> > because of the #become. Then I saw #rehashWithoutBecomeÂ but it answers >> > a >> > different instance. I need a #rehash that does the rehash in the real >> > object >> > and answers self. So...I need the regular #rehash but I want to avoid >> > the >> > #become. Is that possible somehow? >> > >> > This is the current implementation: >> > >> > rehashWithoutBecome >> > >> > Â Â Â | newInstance | >> > Â Â Â newInstance := self species new: self basicSize - 1. "Make sure it >> > has >> > the same capacity" >> > Â Â Â 1 to: self basicSize do: [ :index | >> > Â Â Â Â Â Â (self basicAt: index) ifNotNil: [ :key | >> > Â Â Â Â Â Â Â Â Â newInstance at: key put: (array at: index) ] ]. >> > Â Â Â ^newInstance >> > >> > I am terrible bad with Collection and friends, but cannot we do >> > soemthing >> > like this: >> > >> > rehashWithoutBecome >> > >> > Â Â Â | newInstance | >> > Â Â Â newInstance := self species new: self basicSize - 1. "Make sure it >> > has >> > the same capacity" >> > >> > Â Â Â 1 to: self basicSize do: [ :index | >> > Â Â Â Â Â Â (self basicAt: index) ifNotNil: [ :key | >> > Â Â Â Â Â Â Â Â Â newInstance at: key put: (array at: index) ] ]. >> > >> > Â Â Â 1 to: newInstance basicSize do: [ :index | >> > Â Â Â Â Â Â (newInstance basicAt: index) ifNotNil: [ :key | >> > Â Â Â Â Â Â Â Â Â self at: key put: (newInstance array at: index) ] ]. >> > >> > Â Â Â ^ self >> > >> >> I guess you should at least also copy the nil entries... >> Maybe something like >> >> 1 to: newInstance basicSize do: [ :index | >> Â Â Â Â self basicAt: index put: (newInstance basicAt: index). >> Â Â Â Â array at: index put: (newInstance array at: index)]. >> > > > Good point. So....I was not that mistaken ;) > I have just replaced CompiledMethod >> hashÂ with this new method and at > least all the tests in MethodDictionaryTest are green. > Do you think this implementation is correct or there can be problems? > because it is really MUCH faster than the original one. > > Thanks in advance > >> >> > >> > Thanks for any help. >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Sept. 18, 2011

[Pharo-project] do not forget to sign and send us the license agreement

by StÃ©phane Ducasse

Hi guys this is important that you sign the license agreement for your code. http://code.google.com/p/pharo/wiki/HowToContribute Stef

Sept. 18, 2011

Re: [Pharo-project] scaled decimal question

by StÃ©phane Ducasse

For me the problem is that if "s2" means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. a number is a scaled decimal or not. On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: > On 17 September 2011 14:06, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >> Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. Sure I guessed that too but I hate this behavior. > Indeed. In particular, the Floats turn themselves into "exact > representations" (Float >> #asTrueFraction) - Fractions whose bit > patterns duplicate the float representation. That means that the > resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing > fraction instvars. > > frank > >> -- >> Cheers, >> Peter. >> >> On 17 sep 2011, at 15:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> Why >>> (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) >>> returns false >>> >>> while >>> >>> 0.1s2 + 0.2s2 = 0.3s2 >>> returns true >>> >>> ? >> >> >

Sept. 18, 2011

[Pharo-project] Tablet choice (was: New CogDroid alpha: with intent filter).

by Dimitry Golubovsky

Stephane, StÃ©phane Ducasse wrote: > I would like to buy a tablet for our team to try pharo on it. > What do you suggest? While I would not recommend any particular brand (first of all I don't know what is available in Europe and at what price), take a look at the tinyBenchmarks page: http://code.google.com/p/squeakvm-tablet/wiki/TinyBenchmark and this might help you make decision. After all, there are not so more chipsets (SOCs) out there, so you can see that 1Ghz performs almost twice faster than 800MHz (I asked this on the ARM forum, and they suggested that cheaper SOCs may come with cheaper and slower memory, smaller cache, etc.). NVidia Tegra seems to be much better than Samsung. The rest of your choice will be likely affected by screen size, number of external ports (USB, HDMI, Ethernet), price, and known reliability record of a particular vendor ;) I'd recommend resistive touch screen (cheaper and works with any non-conductive stylus) but this might be just me. Thanks. -- Dimitry Golubovsky Anywhere on the Web

Sept. 18, 2011