# truncatedTo: / roundTo: oddities with fractions

7 messages
Open this post in threaded view
|

## truncatedTo: / roundTo: oddities with fractions

 Hi everyone, a student recently encountered the following behavior: fraction := 5 / 9. (fraction* 100) truncateTo: 0.01. “55.550000000000004" fraction:= 1/18. (fraction * 100) roundTo: 0.01. “5.5600000000000005" This is not what I would expect from #truncateTo: or #roundTo: even when using Floats (especially roundTo:). Is this what we want or an open issue? I have not found any test covering the protocol. Bests Patrick
Open this post in threaded view
|

## Re: truncatedTo: / roundTo: oddities with fractions

 Hi, all.I think the issue can be reduced to:555 * 0.01 "5.55"5555 * 0.01 "55.550000000000004"... because #quo: on a Fraction seems to work as expected.((5/9) * 100 "(500/9)" / 0.01 "5555.555555555556") truncated "5555" * 0.01 "55.550000000000004"Best,Marcel Am 31.07.2019 13:53:49 schrieb Rein, Patrick <[hidden email]>:Hi everyone,a student recently encountered the following behavior:fraction := 5 / 9.(fraction* 100) truncateTo: 0.01. “55.550000000000004"fraction:= 1/18.(fraction * 100) roundTo: 0.01. “5.5600000000000005"This is not what I would expect from #truncateTo: or #roundTo: even when using Floats (especially roundTo:).Is this what we want or an open issue? I have not found any test covering the protocol.BestsPatrick
Open this post in threaded view
|

## Re: truncatedTo: / roundTo: oddities with fractions

 In reply to this post by Patrick R. On Wed, Jul 31, 2019 at 11:53:38AM +0000, Rein, Patrick wrote: > Hi everyone, > > a student recently encountered the following behavior: > > fraction := 5 / 9. > (fraction* 100) truncateTo: 0.01. ???55.550000000000004" > fraction:= 1/18. > (fraction * 100) roundTo: 0.01. ???5.5600000000000005" > > This is not what I would expect from #truncateTo: or #roundTo: even when using Floats (especially roundTo:). > > Is this what we want or an open issue? I have not found any test covering the protocol. > The results are unexpected, but not wrong. Why unexpected? When I look at the expression, I intuitively expect it to perform decimal arithmetic, and it does not do that. Why not wrong? 0.01 is a float, even though it may have been intended as an exact decimal number by the writer. Mixing float values in any arithmetic expression produces an inexact float result, as it should. To get a result that is both correct and intuitively right, the expression might better be written like this:   5 / 9 * 100 truncateTo: (1/100) ==> (1111/20) Dave
Open this post in threaded view
|

## Re: truncatedTo: / roundTo: oddities with fractions

 On Wed, 31 Jul 2019, David T. Lewis wrote: > On Wed, Jul 31, 2019 at 11:53:38AM +0000, Rein, Patrick wrote: >> Hi everyone, >> >> a student recently encountered the following behavior: >> >> fraction := 5 / 9. >> (fraction* 100) truncateTo: 0.01. ???55.550000000000004" >> fraction:= 1/18. >> (fraction * 100) roundTo: 0.01. ???5.5600000000000005" >> >> This is not what I would expect from #truncateTo: or #roundTo: even when using Floats (especially roundTo:). >> >> Is this what we want or an open issue? I have not found any test covering the protocol. >> > > The results are unexpected, but not wrong. > > Why unexpected? When I look at the expression, I intuitively expect > it to perform decimal arithmetic, and it does not do that. > > Why not wrong? 0.01 is a float, even though it may have been intended > as an exact decimal number by the writer. Mixing float values in any > arithmetic expression produces an inexact float result, as it should. > > To get a result that is both correct and intuitively right, the expression > might better be written like this: > >  5 / 9 * 100 truncateTo: (1/100) ==> (1111/20) I think ScaledDecimal is a better fit, as it gives a decimal result: 5 / 9 * 100 truncateTo: 0.01s "==> 55.55s2" Levente > > Dave
Open this post in threaded view
|

## Re: truncatedTo: / roundTo: oddities with fractions

 Thanks! That clarifies things. I agree that it makes sense (although still suprising). To make sure we do not have to discuss that again in the future I will add some test cases for that in the next few days. :) Bests Patrick ________________________________________ From: Squeak-dev <[hidden email]> on behalf of Levente Uzonyi <[hidden email]> Sent: Wednesday, July 31, 2019 3:06:05 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] truncatedTo: / roundTo: oddities with fractions On Wed, 31 Jul 2019, David T. Lewis wrote: > On Wed, Jul 31, 2019 at 11:53:38AM +0000, Rein, Patrick wrote: >> Hi everyone, >> >> a student recently encountered the following behavior: >> >> fraction := 5 / 9. >> (fraction* 100) truncateTo: 0.01. ???55.550000000000004" >> fraction:= 1/18. >> (fraction * 100) roundTo: 0.01. ???5.5600000000000005" >> >> This is not what I would expect from #truncateTo: or #roundTo: even when using Floats (especially roundTo:). >> >> Is this what we want or an open issue? I have not found any test covering the protocol. >> > > The results are unexpected, but not wrong. > > Why unexpected? When I look at the expression, I intuitively expect > it to perform decimal arithmetic, and it does not do that. > > Why not wrong? 0.01 is a float, even though it may have been intended > as an exact decimal number by the writer. Mixing float values in any > arithmetic expression produces an inexact float result, as it should. > > To get a result that is both correct and intuitively right, the expression > might better be written like this: > >  5 / 9 * 100 truncateTo: (1/100) ==> (1111/20) I think ScaledDecimal is a better fit, as it gives a decimal result: 5 / 9 * 100 truncateTo: 0.01s "==> 55.55s2" Levente > > Dave