[squeak-dev] truncatedTo: / roundTo: oddities with fractions

Rein, Patrick Patrick.Rein at hpi.de
Wed Jul 31 14:23:15 UTC 2019


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 <squeak-dev-bounces at lists.squeakfoundation.org> on behalf of Levente Uzonyi <leves at caesar.elte.hu>
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



More information about the Squeak-dev mailing list