Re: [Pharo-project] scaled decimal question
On 17 September 2011 14:06, Peter Hugosson-Miller oldmanl...@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. 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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
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.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
2011/9/18 Stéphane Ducasse stephane.duca...@inria.fr: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
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.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
And in Squeak 3.7, I just verified that (Number classreadFrom:) 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 oldmanl...@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.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
thank I will digest that slowly :) On Sep 18, 2011, at 6:16 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@inria.fr: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
On Sep 18, 2011, at 6:25 PM, Nicolas Cellier wrote: And in Squeak 3.7, I just verified that (Number classreadFrom:) 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 oldmanl...@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.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
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.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
2011/9/18 Stéphane Ducasse stephane.duca...@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.1 + 0.1 ~= 0.2 ;) Nicolas -- Cheers, Peter. On 18 sep 2011, at 17:59, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
Re: [Pharo-project] scaled decimal question
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.duca...@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.1 + 0.1 ~= 0.2 ;) Nicolas -- Cheers, Peter. On 18 sep 2011, at 17:59, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@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 oldmanl...@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.duca...@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 ?
[Pharo-project] scaled decimal question
Why (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) returns false while 0.1s2 + 0.2s2 = 0.3s2 returns true ?
Re: [Pharo-project] scaled decimal question
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. -- Cheers, Peter. On 17 sep 2011, at 15:01, Stéphane Ducasse stephane.duca...@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 ?
