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

Re: [Pharo-project] How can I get smart characters in Pharo 1.4?

by Camillo Bruni

so that's an issue with the keyboard input not pharo directly see http://code.google.com/p/pharo/issues/detail?id=3748 and try to figure out what keyboard events you get in for meta + " meta + shift + " ctrl + " ctrl + shift + " alt + " alt + shift + " cause I am sure that they are rather randomly distributed around some sane average... On 2011-09-16, at 12:54, Alexis Parseghian wrote: > On Fri, Sep 16, 2011 at 11:02 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> It does *not* work for me either. My setup is Pharo #14140, on Ubuntu >> Linux 32bits with a US International keyboard layout. > > Not working here either. Image updated to #14140 as well, debian > testing 64-bit, canadian-french keyboard. > > CogVM -version > 3.9-7 #1 Wed Aug 31 14:50:51 CEST 2011 gcc 4.1.2 > Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123] > > Works fine in Pharo 1.3 #13295, everything else being identical. >

Sept. 18, 2011

Re: [Pharo-project] scaled decimal question

by StÃ©phane Ducasse

Ok I will read finally all the remarks so that I really understand. :) (or not ;)) Stef On Sep 18, 2011, at 7:21 PM, Nicolas Cellier wrote: > 2011/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Sep 18, 2011, at 6:21 PM, Peter Hugosson-Miller wrote: >> >>> 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. >> >> sure you are explaining to me why I get a different behavior at the implementation level but my question is at the conceptual level :) >> >> At the end we (the language designer) could make that they are the same because >> 0 is a character >> . too >> and 1 too. >> >> So I have no problem that we decide that >> >> 0.1 asScaledDecimal: 2 >> is not the same as 0.1s2 but in that case we call it >> >> 0.1 asSomethingElseThanScaledDecimal: 2 >> >> and this is perfect for me. >> >> This is all my point. else 2 could be different from 1+1 too :) >> >> Stef >> > > Oh, but they are: > > (1 to: 1000) detect: [:i | > | s1 s2 | > s1 := Number readFrom: '0.' , (String new: i withAll: $0) , '1'. > s2 := Number readFrom: '0.' , (String new: i withAll: $0) , '2'. > s1+s1~=s2] > -> 308 > > Thus 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 > + 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 > ~= 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 > > ;) > > Nicolas >> >>> >>> -- >>> 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] slices does not work anymore in Pharo1.4

by StÃ©phane Ducasse

strange. BTW normally scriptLoader should not be added to slice since this a private and strange package. Stef On Sep 18, 2011, at 8:17 PM, Mariano Martinez Peck wrote: > Hi guys. Someting really weird is happening in Pharo. I have 3 dirty packages: Kernel, KernelTests and ScriptLoader14. I have created an issue and select those 3 packages. But when the slice is created, it the MonticelloBrowser, it shows only one dependency: ScriptLoader14. So..it misses Kernel and KernelTests. What is worst, is that if I then commit such slice and I see the commits details, it says: "Dependencies: Kernel-MarianoMartinezPeck.940, ScriptLoader14-MarianoMartinezPeck.175" WTF? now it shows 2 instead of 3 ? > > Can someone reprouce this problem? I think it may be related to the selection focus in the UI. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 18, 2011

[Pharo-project] slices does not work anymore in Pharo1.4

by Mariano Martinez Peck

Hi guys. Someting really weird is happening in Pharo. I have 3 dirty packages: Kernel, KernelTests and ScriptLoader14. I have created an issue and select those 3 packages. But when the slice is created, it the MonticelloBrowser, it shows only one dependency: ScriptLoader14. So..it misses Kernel and KernelTests. What is worst, is that if I then commit such slice and I see the commits details, it says: "Dependencies: Kernel-MarianoMartinezPeck.940, ScriptLoader14-MarianoMartinezPeck.175" WTF? now it shows 2 instead of 3 ? Can someone reprouce this problem? I think it may be related to the selection focus in the UI. Cheers -- Mariano http://marianopeck.wordpress.com

Sept. 18, 2011

Re: [Pharo-project] MethodDictionary fast #rehash

by Mariano Martinez Peck

On Sun, Sep 18, 2011 at 5:40 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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. > Interesting. Thanks Nicolas for the pointer. > See recent changes from Levente in trunk. > > heheheheh it seems Levente is still reading the Pharo mailing list. So...I took his commits of today, and I have made a Pharo change set. I have put all the information here: http://code.google.com/p/pharo/issues/detail?id=4826 Basically, he used #copyFrom: which is primitive and hence it avoids the inconsistent state. If someone can check the changeset and give the OK, we can integrate it. Thanks a lot > 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 > > > > > > -- Mariano http://marianopeck.wordpress.com

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 6:21 PM, Peter Hugosson-Miller wrote: > >> 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. > > sure you are explaining to me why I get a different behavior at the implementation level but my question is at the conceptual level :) > > At the end we (the language designer) could make that they are the same because > 0 is a character > . too > and 1 too. > > So I have no problem that we decide that > > Â Â Â Â 0.1 asScaledDecimal: 2 > Â Â Â Â is not the same as 0.1s2 but in that case we call it > > Â Â Â Â 0.1 asSomethingElseThanScaledDecimal: 2 > > and this is perfect for me. > > This is all my point. else 2 could be different from 1+1 too :) > > Stef > Oh, but they are: (1 to: 1000) detect: [:i | | s1 s2 | s1 := Number readFrom: '0.' , (String new: i withAll: $0) , '1'. s2 := Number readFrom: '0.' , (String new: i withAll: $0) , '2'. s1+s1~=s2] -> 308 Thus 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 + 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 ~= 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 ;) Nicolas > >> >> -- >> 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 StÃ©phane Ducasse

On Sep 18, 2011, at 6:21 PM, Peter Hugosson-Miller wrote: > 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. sure you are explaining to me why I get a different behavior at the implementation level but my question is at the conceptual level :) At the end we (the language designer) could make that they are the same because 0 is a character . too and 1 too. So I have no problem that we decide that 0.1 asScaledDecimal: 2 is not the same as 0.1s2 but in that case we call it 0.1 asSomethingElseThanScaledDecimal: 2 and this is perfect for me. This is all my point. else 2 could be different from 1+1 too :) Stef > > -- > 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 StÃ©phane Ducasse

On Sep 18, 2011, at 6:25 PM, Nicolas Cellier wrote: > And in Squeak 3.7, I just verified that (Number class>>readFrom:) did > use an intermediate Float... > > 0.1s2 asFraction -> (3602879701896397/36028797018963968) > > This was corrected in 3.8, so maybe not integrated by you Stef ? you confused me :) Should we integrate something in pharo? Stef > > Nicolas > > 2011/9/18 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: >> 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 StÃ©phane Ducasse

thank I will digest that slowly :) On Sep 18, 2011, at 6:16 PM, Nicolas Cellier wrote: > 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 Nicolas Cellier

And in Squeak 3.7, I just verified that (Number class>>readFrom:) did use an intermediate Float... 0.1s2 asFraction -> (3602879701896397/36028797018963968) This was corrected in 3.8, so maybe not integrated by you Stef ? Nicolas 2011/9/18 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > 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