Rounding in Floats

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Rounding in Floats

Esteban A. Maringolo
Hi,

Continuing with my issues with decimals, I'm having one issue that is
not clear to me why it happens.

If I do:
(9.1 + (-2.0)) roundTo: 0.1.
"7.1000000000000005"

I expect to get a single decimal Float (rounded with whatever
precision, but a single decimal).

Even if I do something like this:
7.1 roundTo: 0.1

It gives the wrong result.

In VW and VAST it provides the right result.
(9.1 + (-2.0)) roundTo: 0.1 "7.1"

In Dolphin it also returns the wrong result, it seems to use the same
algorithm to round it.

Is this a bug?

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Sven Van Caekenberghe-2


> On 6 Sep 2020, at 16:06, Esteban Maringolo <[hidden email]> wrote:
>
> Hi,
>
> Continuing with my issues with decimals, I'm having one issue that is
> not clear to me why it happens.
>
> If I do:
> (9.1 + (-2.0)) roundTo: 0.1.
> "7.1000000000000005"
>
> I expect to get a single decimal Float (rounded with whatever
> precision, but a single decimal).
>
> Even if I do something like this:
> 7.1 roundTo: 0.1
>
> It gives the wrong result.
>
> In VW and VAST it provides the right result.
> (9.1 + (-2.0)) roundTo: 0.1 "7.1"
>
> In Dolphin it also returns the wrong result, it seems to use the same
> algorithm to round it.
>
> Is this a bug?

Maybe.

But I would not approach the problem of rounding like that.
You probably want to control how numbers are printed.
I would keep the numbers themselves at maximum internal precision and only do something when printing them.

1 / 3 asFloat printShowingDecimalPlaces: 1.

Since you like Seaside, the following is even much more powerful (has *many* options):

GRNumberPrinter new precision: 1; print: 1/3 asFloat.

Check it out.

>
> Esteban A. Maringolo
>


Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
Hi Sven,

On Sun, Sep 6, 2020 at 11:57 AM Sven Van Caekenberghe <[hidden email]> wrote:
> > On 6 Sep 2020, at 16:06, Esteban Maringolo <[hidden email]> wrote:

> > (9.1 + (-2.0)) roundTo: 0.1.
> > "7.1000000000000005"

> > Is this a bug?
>
> Maybe.
>
> But I would not approach the problem of rounding like that.
> You probably want to control how numbers are printed.

It is not for printing but for testing. I want to assert that a
certain calculation gives the expected result.
And then it fails because of the difference above when it is
"semantically" correct.

> I would keep the numbers themselves at maximum internal precision and only do something when printing them.

I do. I'm implementing the full WHS specification [1], and it mentions
that most calculations should preserve the maximum internal precision
and even introduces some weird situation where you have an "index"
that is rounded and another one that is called the same way but must
not be rounded because is going to used to compute some other value.

For most calculations it specifies it must round to 1 decimal or even
to no decimal, based on a round up if the decimal is greater or equal
than zero (e.g. 1.5 becomes 2), except for negative numbers, in which
case it rounds "down" (-1.5 becomes 1).

> 1 / 3 asFloat printShowingDecimalPlaces: 1.
>
> Since you like Seaside, the following is even much more powerful (has *many* options):
> GRNumberPrinter new precision: 1; print: 1/3 asFloat.

I'm already using the GRNumberPrinter and also the Date printer to
print these values.

Regards!

[1] https://en.wikipedia.org/wiki/Handicap_(golf)#World_Handicap_System

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

khinsen
Hi Esteban,

> It is not for printing but for testing. I want to assert that a
> certain calculation gives the expected result.
> And then it fails because of the difference above when it is
> "semantically" correct.

If you want reliable precision tests with IEEE floats, you should use
rounding to powers of 2, not 10. Round to 1/8 or 1/16, but not to 1/10.

The fundamental issue is that 1/10 does not have an exact finite
representation in base 2. No matter how I/O libraries handle the
conversion between base 2 (in the binary representation of IEEE floats)
and base 10 (in the text representation), there will always be bad
surprises because the expectations we have from working in base 10
cannot all be met with an internal representation in base 2.

So if your goal is not fundamentally related to I/O, forget about I/O
and design your code to work the binary level, in particular for
testing.

However, if your problem specification explicitly requires precision
guarantees in base 10 (which seems to be your case, from a quick glance
at the Wikipedia page you cite), then it's best to avoid binary floats
completely. Rationals (fractions) are one option, scaled integers
another one.

Konrad.

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Sven Van Caekenberghe-2
In reply to this post by Esteban A. Maringolo


> On 6 Sep 2020, at 22:21, Esteban Maringolo <[hidden email]> wrote:
>
> It is not for printing but for testing. I want to assert that a
> certain calculation gives the expected result.

Then you should use #assert:closeTo: and friends.

(9.1 + (-2.0)) closeTo: 7.1 precision: 0.00001.

Floats should always be compared using an epsilon (precision) value in tests, not using equality.


Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

SergeStinckwich
BTW why closeTo: is initialized by default with a value of 0.0001 ?
https://github.com/pharo-project/pharo/issues/3067

Sent from my iPhone

On 7 Sep 2020, at 20:10, Sven Van Caekenberghe <[hidden email]> wrote:



On 6 Sep 2020, at 22:21, Esteban Maringolo <[hidden email]> wrote:

It is not for printing but for testing. I want to assert that a
certain calculation gives the expected result.

Then you should use #assert:closeTo: and friends.

(9.1 + (-2.0)) closeTo: 7.1 precision: 0.00001.

Floats should always be compared using an epsilon (precision) value in tests, not using equality.


Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
In reply to this post by Sven Van Caekenberghe-2
Hi Sven,

On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <[hidden email]> wrote:

> > On 6 Sep 2020, at 22:21, Esteban Maringolo <[hidden email]> wrote:
> >
> > It is not for printing but for testing. I want to assert that a
> > certain calculation gives the expected result.
>
> Then you should use #assert:closeTo: and friends.
> (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1.

I remembered about it, and implemented my own
#assertDifferential:equals: which I first did convert to
ScaledDecimals and then compares with #roundedByScale.

> Floats should always be compared using an epsilon (precision) value in tests, not using equality.

Sure, but 7.1 roundTo: 0.1 should return 7.1.  Shouldn't it?

Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

tomo
Esteban,

You can instead use `7.1 round: 1` to get 7.1.
It's not the problem of the rounding algorithm.
It's because IEEE float can't express the exact value of 0.1.
---
tomo

2020年9月7日(月) 21:28 Esteban Maringolo <[hidden email]>:

>
> Hi Sven,
>
> On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <[hidden email]> wrote:
>
> > > On 6 Sep 2020, at 22:21, Esteban Maringolo <[hidden email]> wrote:
> > >
> > > It is not for printing but for testing. I want to assert that a
> > > certain calculation gives the expected result.
> >
> > Then you should use #assert:closeTo: and friends.
> > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1.
>
> I remembered about it, and implemented my own
> #assertDifferential:equals: which I first did convert to
> ScaledDecimals and then compares with #roundedByScale.
>
> > Floats should always be compared using an epsilon (precision) value in tests, not using equality.
>
> Sure, but 7.1 roundTo: 0.1 should return 7.1.  Shouldn't it?
>
> Regards!
>
> Esteban A. Maringolo
>

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
Hi Tomohiro,

Thanks, that certainly is the simplest solution that does exactly what I need.

Maybe roundTo: should be considered harmful when using Floats.
(and it is very unlikely anybody is going to round to something other
than a power of 10)

Best regards!


Esteban A. Maringolo

On Mon, Sep 7, 2020 at 9:51 AM Tomohiro Oda <[hidden email]> wrote:

>
> Esteban,
>
> You can instead use `7.1 round: 1` to get 7.1.
> It's not the problem of the rounding algorithm.
> It's because IEEE float can't express the exact value of 0.1.
> ---
> tomo
>
> 2020年9月7日(月) 21:28 Esteban Maringolo <[hidden email]>:
> >
> > Hi Sven,
> >
> > On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <[hidden email]> wrote:
> >
> > > > On 6 Sep 2020, at 22:21, Esteban Maringolo <[hidden email]> wrote:
> > > >
> > > > It is not for printing but for testing. I want to assert that a
> > > > certain calculation gives the expected result.
> > >
> > > Then you should use #assert:closeTo: and friends.
> > > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1.
> >
> > I remembered about it, and implemented my own
> > #assertDifferential:equals: which I first did convert to
> > ScaledDecimals and then compares with #roundedByScale.
> >
> > > Floats should always be compared using an epsilon (precision) value in tests, not using equality.
> >
> > Sure, but 7.1 roundTo: 0.1 should return 7.1.  Shouldn't it?
> >
> > Regards!
> >
> > Esteban A. Maringolo
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Richard O'Keefe
In reply to this post by Esteban A. Maringolo
"7.1 roundTo: 0.1 should return 7.1"
You're still not getting it.
7.1 IS NOT 71/10.
0.1 IS NOT 1/10.
Binary floating point CANNOT represent either of those numbers.
You seem to be assuming that Pharo is making some mistake.
It isn't.  All it is doing is refusing to lie to you.

#include <math.h>
#include <stdio.h>

int main(void) {
    printf("%.18f\n", 7.1);
    printf("%.18f\n", round(7.1 / 0.1) * 0.1);
    return 0;
}

% a.out
7.099999999999999645
7.100000000000000533

Does this help?  "7.1" is a bit LESS than 7.1.
"7.1 roundTo: 0.1" is a bit MORE than 7.1.
This is the best that the computer's hardware can do.
The systems that print 7.1 are LYING to you,
and Pharo is not.




On Tue, 8 Sep 2020 at 00:28, Esteban Maringolo <[hidden email]> wrote:
Hi Sven,

On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <[hidden email]> wrote:

> > On 6 Sep 2020, at 22:21, Esteban Maringolo <[hidden email]> wrote:
> >
> > It is not for printing but for testing. I want to assert that a
> > certain calculation gives the expected result.
>
> Then you should use #assert:closeTo: and friends.
> (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1.

I remembered about it, and implemented my own
#assertDifferential:equals: which I first did convert to
ScaledDecimals and then compares with #roundedByScale.

> Floats should always be compared using an epsilon (precision) value in tests, not using equality.

Sure, but 7.1 roundTo: 0.1 should return 7.1.  Shouldn't it?

Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
>
> "7.1 roundTo: 0.1 should return 7.1"
> You're still not getting it.

I was until Konrad explained it.

> Binary floating point CANNOT represent either of those numbers.
> You seem to be assuming that Pharo is making some mistake.
> It isn't.  All it is doing is refusing to lie to you.
<snip>
> The systems that print 7.1 are LYING to you,
> and Pharo is not.

I'm not assuming a mistake from Pharo, I had a wrong expectation what
to get if I round to that precision.
I don't know whether other systems lie or simply fulfill user
expectations, if you send the #roundTo: to a float, I did expect to
get a number with the same precision.
That is my expectation as a user. As in the other thread I expected
two scaled decimals that are printed equal to also be compared as
equal  (which they don't).

Whether there is a good reason for those behaviors is beyond my
current comprehension, but it certainly doesn't follow the "principle
of least surprise".

In any case, the method proposed by Tomohiro solved my issues.

Regards,

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Richard O'Keefe
If you are going to use floating point numbers in any programming
language, Pharo included, you need to understand something about
them.  Things like
 - the relevant precision is *fixed*; a Float in Pharo is *always*
   a 64-bit IEEE floating-point number, which amongst other things
   means (to a first approximation) 54 binary digits of precision.
   It doesn't make the slightest amount of difference how many
   decimal digits you use when writing the number, the precision
   is *always* 54 binary digits.  So you *did* get the precision
   out of rounding that you put in, it's just that the precision
   you put in was not what you thought it was.
 - almost all modern architectures offer BINARY arithmetic, not
   decimal.  (The main exceptions are IBM z/series and IBM POWER,
   which offer binary *and* decimal.)  Rounding a number to n
   decimals is ALWAYS problematic using binary floats.  This has
   little or nothing to do with Smalltalk: it's the hardware.
   (This is why you are advised to keep money in cents, not dollars.)
 - Again, this is NOT a language issue, it is a hardware issue.
   IF you understand how binary floating point arithmetic works,
   then the arithmetic you get in C or R or Smalltalk or Matlab
   does not surprise you at all.
   If you DON'T understand how binary floating point arithmetic works,
   the hardware will *get* you sooner or later.
 - ScaledDecimal in Pharo didn't have to violate the principle of
   least surprise, but it does, big time.
 - It would be really nice if Pharo offered true decimal arithmetic
   as an option.  There may already be a package for this.



On Tue, 8 Sep 2020 at 15:46, Esteban Maringolo <[hidden email]> wrote:
On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
>
> "7.1 roundTo: 0.1 should return 7.1"
> You're still not getting it.

I was until Konrad explained it.

> Binary floating point CANNOT represent either of those numbers.
> You seem to be assuming that Pharo is making some mistake.
> It isn't.  All it is doing is refusing to lie to you.
<snip>
> The systems that print 7.1 are LYING to you,
> and Pharo is not.

I'm not assuming a mistake from Pharo, I had a wrong expectation what
to get if I round to that precision.
I don't know whether other systems lie or simply fulfill user
expectations, if you send the #roundTo: to a float, I did expect to
get a number with the same precision.
That is my expectation as a user. As in the other thread I expected
two scaled decimals that are printed equal to also be compared as
equal  (which they don't).

Whether there is a good reason for those behaviors is beyond my
current comprehension, but it certainly doesn't follow the "principle
of least surprise".

In any case, the method proposed by Tomohiro solved my issues.

Regards,

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
In reply to this post by Esteban A. Maringolo
I'm coming back to this because I've been bitten by these floating
points things again.

If in Pharo [1] you do:
a := 6.7 + (32.8 - 35)

It will produce:
4.499999999999997

Which, when rounded, will produce 4.

In other places [2] I do the same simple addition and subtraction it
produces 4.5, that when rounded will produce 5.

I know now that Pharo doesn't lie to me while other systems do, and
all that Richard pointed to before.

The issue here is that I'm following some calculation formula that was
defined in some of the "other" systems, and so when I follow such a
formula I get these edgy cases where my system produces a different
output.

In this case the formula is for golf handicap calculations, and it
caused my system to give 4 instead of 5 to a player, resulting in
giving the first place to a player other than the one deserved.
It was no big deal (it's not The Masters), but these cases appear from
time to time.

Is there any way to "configure" the floating point calculation to
behave as the "other systems"?

What is the best way to anticipate these situations, am I the only one
being bitten by these issues?

Thanks in advance for any hints about these problems.


Best regards,

[1] Dolphin Smalltalk, JS, Python, Ruby, Dart produces the same output as Pharo.
[2] VisualWorks, VAST, Excel, VB and all calculators I tried



Esteban A. Maringolo

On Tue, Sep 8, 2020 at 12:45 AM Esteban Maringolo <[hidden email]> wrote:

>
> On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
> >
> > "7.1 roundTo: 0.1 should return 7.1"
> > You're still not getting it.
>
> I was until Konrad explained it.
>
> > Binary floating point CANNOT represent either of those numbers.
> > You seem to be assuming that Pharo is making some mistake.
> > It isn't.  All it is doing is refusing to lie to you.
> <snip>
> > The systems that print 7.1 are LYING to you,
> > and Pharo is not.
>
> I'm not assuming a mistake from Pharo, I had a wrong expectation what
> to get if I round to that precision.
> I don't know whether other systems lie or simply fulfill user
> expectations, if you send the #roundTo: to a float, I did expect to
> get a number with the same precision.
> That is my expectation as a user. As in the other thread I expected
> two scaled decimals that are printed equal to also be compared as
> equal  (which they don't).
>
> Whether there is a good reason for those behaviors is beyond my
> current comprehension, but it certainly doesn't follow the "principle
> of least surprise".
>
> In any case, the method proposed by Tomohiro solved my issues.
>
> Regards,
>
> Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Sven Van Caekenberghe-2


> On 14 Jun 2021, at 22:44, Esteban Maringolo <[hidden email]> wrote:
>
> I'm coming back to this because I've been bitten by these floating
> points things again.
>
> If in Pharo [1] you do:
> a := 6.7 + (32.8 - 35)
>
> It will produce:
> 4.499999999999997
>
> Which, when rounded, will produce 4.

But,

a roundTo: 0.1 "=> 4.5"

> In other places [2] I do the same simple addition and subtraction it
> produces 4.5, that when rounded will produce 5.
>
> I know now that Pharo doesn't lie to me while other systems do, and
> all that Richard pointed to before.
>
> The issue here is that I'm following some calculation formula that was
> defined in some of the "other" systems, and so when I follow such a
> formula I get these edgy cases where my system produces a different
> output.
>
> In this case the formula is for golf handicap calculations, and it
> caused my system to give 4 instead of 5 to a player, resulting in
> giving the first place to a player other than the one deserved.
> It was no big deal (it's not The Masters), but these cases appear from
> time to time.
>
> Is there any way to "configure" the floating point calculation to
> behave as the "other systems"?
>
> What is the best way to anticipate these situations, am I the only one
> being bitten by these issues?
>
> Thanks in advance for any hints about these problems.
>
>
> Best regards,
>
> [1] Dolphin Smalltalk, JS, Python, Ruby, Dart produces the same output as Pharo.
> [2] VisualWorks, VAST, Excel, VB and all calculators I tried
>
>
>
> Esteban A. Maringolo
>
> On Tue, Sep 8, 2020 at 12:45 AM Esteban Maringolo <[hidden email]> wrote:
>>
>> On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
>>>
>>> "7.1 roundTo: 0.1 should return 7.1"
>>> You're still not getting it.
>>
>> I was until Konrad explained it.
>>
>>> Binary floating point CANNOT represent either of those numbers.
>>> You seem to be assuming that Pharo is making some mistake.
>>> It isn't.  All it is doing is refusing to lie to you.
>> <snip>
>>> The systems that print 7.1 are LYING to you,
>>> and Pharo is not.
>>
>> I'm not assuming a mistake from Pharo, I had a wrong expectation what
>> to get if I round to that precision.
>> I don't know whether other systems lie or simply fulfill user
>> expectations, if you send the #roundTo: to a float, I did expect to
>> get a number with the same precision.
>> That is my expectation as a user. As in the other thread I expected
>> two scaled decimals that are printed equal to also be compared as
>> equal  (which they don't).
>>
>> Whether there is a good reason for those behaviors is beyond my
>> current comprehension, but it certainly doesn't follow the "principle
>> of least surprise".
>>
>> In any case, the method proposed by Tomohiro solved my issues.
>>
>> Regards,
>>
>> Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Sven Van Caekenberghe-2
BTW, I recently wrote my own float printer, as an experiment.

NeoJSONFloatPrinter lowPrecision print: a.

=> 4.5

What I wanted was a human friendly, compact float printer, that tries to go for the shortest, simplest number. It prefers integers and goes to scientific notation when needed, while limiting the precision. Maybe it is interesting to look at the code.

But I am far from an expert.

> On 14 Jun 2021, at 23:23, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>
>> On 14 Jun 2021, at 22:44, Esteban Maringolo <[hidden email]> wrote:
>>
>> I'm coming back to this because I've been bitten by these floating
>> points things again.
>>
>> If in Pharo [1] you do:
>> a := 6.7 + (32.8 - 35)
>>
>> It will produce:
>> 4.499999999999997
>>
>> Which, when rounded, will produce 4.
>
> But,
>
> a roundTo: 0.1 "=> 4.5"
>
>> In other places [2] I do the same simple addition and subtraction it
>> produces 4.5, that when rounded will produce 5.
>>
>> I know now that Pharo doesn't lie to me while other systems do, and
>> all that Richard pointed to before.
>>
>> The issue here is that I'm following some calculation formula that was
>> defined in some of the "other" systems, and so when I follow such a
>> formula I get these edgy cases where my system produces a different
>> output.
>>
>> In this case the formula is for golf handicap calculations, and it
>> caused my system to give 4 instead of 5 to a player, resulting in
>> giving the first place to a player other than the one deserved.
>> It was no big deal (it's not The Masters), but these cases appear from
>> time to time.
>>
>> Is there any way to "configure" the floating point calculation to
>> behave as the "other systems"?
>>
>> What is the best way to anticipate these situations, am I the only one
>> being bitten by these issues?
>>
>> Thanks in advance for any hints about these problems.
>>
>>
>> Best regards,
>>
>> [1] Dolphin Smalltalk, JS, Python, Ruby, Dart produces the same output as Pharo.
>> [2] VisualWorks, VAST, Excel, VB and all calculators I tried
>>
>>
>>
>> Esteban A. Maringolo
>>
>> On Tue, Sep 8, 2020 at 12:45 AM Esteban Maringolo <[hidden email]> wrote:
>>>
>>> On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
>>>>
>>>> "7.1 roundTo: 0.1 should return 7.1"
>>>> You're still not getting it.
>>>
>>> I was until Konrad explained it.
>>>
>>>> Binary floating point CANNOT represent either of those numbers.
>>>> You seem to be assuming that Pharo is making some mistake.
>>>> It isn't.  All it is doing is refusing to lie to you.
>>> <snip>
>>>> The systems that print 7.1 are LYING to you,
>>>> and Pharo is not.
>>>
>>> I'm not assuming a mistake from Pharo, I had a wrong expectation what
>>> to get if I round to that precision.
>>> I don't know whether other systems lie or simply fulfill user
>>> expectations, if you send the #roundTo: to a float, I did expect to
>>> get a number with the same precision.
>>> That is my expectation as a user. As in the other thread I expected
>>> two scaled decimals that are printed equal to also be compared as
>>> equal  (which they don't).
>>>
>>> Whether there is a good reason for those behaviors is beyond my
>>> current comprehension, but it certainly doesn't follow the "principle
>>> of least surprise".
>>>
>>> In any case, the method proposed by Tomohiro solved my issues.
>>>
>>> Regards,
>>>
>>> Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
In reply to this post by Sven Van Caekenberghe-2
Hi Sven,

> > If in Pharo [1] you do:
> > a := 6.7 + (32.8 - 35)
> > It will produce:
> > 4.499999999999997
> > Which, when rounded, will produce 4.

> But,
> a roundTo: 0.1 "=> 4.5"

Sure, but what initiated this thread was a reference to roundTo: 0.1
which produced a "wrong" output.

(9.1 + (-2.0)) roundTo: 0.1 "=> 7.1000000000000005"
7.1 roundTo: 0.1 "=> 7.1000000000000005"

However, at this point I know that Pharo "does the right, raw, thing"
(at least compared to other mainstream languages), but it still
produces a surprise effect.

In particular when people go to Excel to "check that your system does
the right thing", uses the same formula and it gives a different
result to them. Then open a calculator (or a physical one) and it
gives the same number as Excel. So an hour after the fact you're
arguing about floating point implementations to non-technical people
:-)

Regards!

Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Richard O'Keefe
In reply to this post by Esteban A. Maringolo
It's not quite clear what is happening in the other systems.
Here is R
> 6.7 + (32.8 - 35)
[1] 4.5
> round(6.7 + (32.8 - 35))
[1] 4
The result *is* 4.499999.... but is *printed* as 4.5.

Here is Gambit Scheme
> (+ 6.7 (- 32.8 35))
4.499999999999997
 > (round (+ 6.7 (- 32.8 35)))
 4.

Here is astc Smalltalk
6.7 + (32.8 - 35) printOn: Transcript
Transcript tab.
(6.7 + (32.8 - 35)) rounded printOn: Transcript.
Transcript cr.
4.499999999999997       4

And here is Python
>>> x = 6.7 + (32.8 - 35)
>>> x
4.499999999999997
>>> round(x)
4

For what it's worth, I expected ScaledDecimal to act like fixed point
arithmetic, and implemented it that way in my own Smalltalk library, where
two ScaledDecimals *do* print the same if and only if they are numerically
exactly the same.  What Squeak and Pharo do is exceedingly odd: a ScaledDecimal
is an exact rational number (Integer or Fraction) combined with a precision that
is used for printing, not for calculation.

There really isn't any principle of least surprise when it comes to floating-
point arithmetic.  It's full of surprises and edge cases.  Excel in particular
is notorious for messing up due to trying to pretend all is well.

In this particular case, the exact result is 4.5
There are at least three rules for rounding such numbers: rounding out (5),
rounding in (4), and rounding in [banker'salgorithm] (4 here, but 5.5 -> 6).
So you are pushing up against an edge case for exact hand calculation!

I think you need to re-express your entire calculation to use exact arithmetic.
That or get agreement on "de minimis non curat lex".


On Tue, 15 Jun 2021 at 08:45, Esteban Maringolo <[hidden email]> wrote:

>
> I'm coming back to this because I've been bitten by these floating
> points things again.
>
> If in Pharo [1] you do:
> a := 6.7 + (32.8 - 35)
>
> It will produce:
> 4.499999999999997
>
> Which, when rounded, will produce 4.
>
> In other places [2] I do the same simple addition and subtraction it
> produces 4.5, that when rounded will produce 5.
>
> I know now that Pharo doesn't lie to me while other systems do, and
> all that Richard pointed to before.
>
> The issue here is that I'm following some calculation formula that was
> defined in some of the "other" systems, and so when I follow such a
> formula I get these edgy cases where my system produces a different
> output.
>
> In this case the formula is for golf handicap calculations, and it
> caused my system to give 4 instead of 5 to a player, resulting in
> giving the first place to a player other than the one deserved.
> It was no big deal (it's not The Masters), but these cases appear from
> time to time.
>
> Is there any way to "configure" the floating point calculation to
> behave as the "other systems"?
>
> What is the best way to anticipate these situations, am I the only one
> being bitten by these issues?
>
> Thanks in advance for any hints about these problems.
>
>
> Best regards,
>
> [1] Dolphin Smalltalk, JS, Python, Ruby, Dart produces the same output as Pharo.
> [2] VisualWorks, VAST, Excel, VB and all calculators I tried
>
>
>
> Esteban A. Maringolo
>
> On Tue, Sep 8, 2020 at 12:45 AM Esteban Maringolo <[hidden email]> wrote:
> >
> > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
> > >
> > > "7.1 roundTo: 0.1 should return 7.1"
> > > You're still not getting it.
> >
> > I was until Konrad explained it.
> >
> > > Binary floating point CANNOT represent either of those numbers.
> > > You seem to be assuming that Pharo is making some mistake.
> > > It isn't.  All it is doing is refusing to lie to you.
> > <snip>
> > > The systems that print 7.1 are LYING to you,
> > > and Pharo is not.
> >
> > I'm not assuming a mistake from Pharo, I had a wrong expectation what
> > to get if I round to that precision.
> > I don't know whether other systems lie or simply fulfill user
> > expectations, if you send the #roundTo: to a float, I did expect to
> > get a number with the same precision.
> > That is my expectation as a user. As in the other thread I expected
> > two scaled decimals that are printed equal to also be compared as
> > equal  (which they don't).
> >
> > Whether there is a good reason for those behaviors is beyond my
> > current comprehension, but it certainly doesn't follow the "principle
> > of least surprise".
> >
> > In any case, the method proposed by Tomohiro solved my issues.
> >
> > Regards,
> >
> > Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Esteban A. Maringolo
On Mon, Jun 14, 2021 at 10:37 PM Richard O'Keefe <[hidden email]> wrote:

> For what it's worth, I expected ScaledDecimal to act like fixed point
> arithmetic, and implemented it that way in my own Smalltalk library, where
> two ScaledDecimals *do* print the same if and only if they are numerically
> exactly the same.
> What Squeak and Pharo do is exceedingly odd: a ScaledDecimal
> is an exact rational number (Integer or Fraction) combined with a precision that
> is used for printing, not for calculation.

I pointed out before the weird behavior of ScaledDecimals in Pharo,
two ScaledDecimal that print the same are not equal. Giving some weird
comparison issues as result.

> There really isn't any principle of least surprise when it comes to floating-
> point arithmetic.  It's full of surprises and edge cases.  Excel in particular
> is notorious for messing up due to trying to pretend all is well.
> In this particular case, the exact result is 4.5

Well... for the end user, it produces what they'd expect. So it might
mess up, but in a spreadsheet 6.7 - 2.2 should give 4.5.

> There are at least three rules for rounding such numbers: rounding out (5),
> rounding in (4), and rounding in [banker'salgorithm] (4 here, but 5.5 -> 6).
> So you are pushing up against an edge case for exact hand calculation!

I implemented a Float>>#roundedHandicap method that does something
like the banking algorithm, but rounds positive numbers towards the
next integer and negative numbers towards zero.
E.g.
0.49 -> 0
0.5 -> 1
-0.5 -> 0
-0.51 -> -1

Nothing uses more than one decimal, so a ScaledDecimal would work but
the specification says that it should use all possible precision in
intermediate calculations, so I cannot use it.

> I think you need to re-express your entire calculation to use exact arithmetic.

I really don't know how to do this, any pointers?

Nothing is more straightforward than addition and subtraction to me,
6.7 - 2.2 is the simplest it can get.

The common formula here is: h * s / 113 + (r - p), but in this
particular case s was 113 so it removed the "troubling" part.

> That or get agreement on "de minimis non curat lex".

I had to search for that expression. Now I know, I agree.

Regards,

Esteban A. Maringolo



>
>
> On Tue, 15 Jun 2021 at 08:45, Esteban Maringolo <[hidden email]> wrote:
> >
> > I'm coming back to this because I've been bitten by these floating
> > points things again.
> >
> > If in Pharo [1] you do:
> > a := 6.7 + (32.8 - 35)
> >
> > It will produce:
> > 4.499999999999997
> >
> > Which, when rounded, will produce 4.
> >
> > In other places [2] I do the same simple addition and subtraction it
> > produces 4.5, that when rounded will produce 5.
> >
> > I know now that Pharo doesn't lie to me while other systems do, and
> > all that Richard pointed to before.
> >
> > The issue here is that I'm following some calculation formula that was
> > defined in some of the "other" systems, and so when I follow such a
> > formula I get these edgy cases where my system produces a different
> > output.
> >
> > In this case the formula is for golf handicap calculations, and it
> > caused my system to give 4 instead of 5 to a player, resulting in
> > giving the first place to a player other than the one deserved.
> > It was no big deal (it's not The Masters), but these cases appear from
> > time to time.
> >
> > Is there any way to "configure" the floating point calculation to
> > behave as the "other systems"?
> >
> > What is the best way to anticipate these situations, am I the only one
> > being bitten by these issues?
> >
> > Thanks in advance for any hints about these problems.
> >
> >
> > Best regards,
> >
> > [1] Dolphin Smalltalk, JS, Python, Ruby, Dart produces the same output as Pharo.
> > [2] VisualWorks, VAST, Excel, VB and all calculators I tried
> >
> >
> >
> > Esteban A. Maringolo
> >
> > On Tue, Sep 8, 2020 at 12:45 AM Esteban Maringolo <[hidden email]> wrote:
> > >
> > > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <[hidden email]> wrote:
> > > >
> > > > "7.1 roundTo: 0.1 should return 7.1"
> > > > You're still not getting it.
> > >
> > > I was until Konrad explained it.
> > >
> > > > Binary floating point CANNOT represent either of those numbers.
> > > > You seem to be assuming that Pharo is making some mistake.
> > > > It isn't.  All it is doing is refusing to lie to you.
> > > <snip>
> > > > The systems that print 7.1 are LYING to you,
> > > > and Pharo is not.
> > >
> > > I'm not assuming a mistake from Pharo, I had a wrong expectation what
> > > to get if I round to that precision.
> > > I don't know whether other systems lie or simply fulfill user
> > > expectations, if you send the #roundTo: to a float, I did expect to
> > > get a number with the same precision.
> > > That is my expectation as a user. As in the other thread I expected
> > > two scaled decimals that are printed equal to also be compared as
> > > equal  (which they don't).
> > >
> > > Whether there is a good reason for those behaviors is beyond my
> > > current comprehension, but it certainly doesn't follow the "principle
> > > of least surprise".
> > >
> > > In any case, the method proposed by Tomohiro solved my issues.
> > >
> > > Regards,
> > >
> > > Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

khinsen
In reply to this post by Esteban A. Maringolo
On 15/06/2021 01:03, Esteban Maringolo wrote:
> Sure, but what initiated this thread was a reference to roundTo: 0.1
> which produced a "wrong" output.
>
> (9.1 + (-2.0)) roundTo: 0.1 "=> 7.1000000000000005"
> 7.1 roundTo: 0.1 "=> 7.1000000000000005"
>
> However, at this point I know that Pharo "does the right, raw, thing"
> (at least compared to other mainstream languages), but it still
> produces a surprise effect.

That's the "floating point surprise" that everyone has at some point, no
matter the language and runtime system. If that surprise is a problem
for you, are you sure that floating-point arithmetic is what you really
want? Maybe your needs are better served with integers and fractions.


Konrad.

Reply | Threaded
Open this post in threaded view
|

Re: Rounding in Floats

Steffen Märcker
Have you considered using fixed-point arithmetic? For example:
7.1s2 roundTo: 0.1s2

The rule of thumb I stick to is to use FP only if I know the inaccuracies
won't bite me. Funny enough, both 7.1 and 0.1 are already not accurately
representable as floats. (And by coincidence, I prepared exam questions
about floats for my students yesterday. )

Kind regards,
Steffen


Konrad Hinsen schrieb am Dienstag, 15. Juni 2021 07:02:30 (+02:00):

 > On 15/06/2021 01:03, Esteban Maringolo wrote:
 > > Sure, but what initiated this thread was a reference to roundTo: 0.1
 > > which produced a "wrong" output.
 > >
 > > (9.1 + (-2.0)) roundTo: 0.1 "=> 7.1000000000000005"
 > > 7.1 roundTo: 0.1 "=> 7.1000000000000005"
 > >
 > > However, at this point I know that Pharo "does the right, raw, thing"
 > > (at least compared to other mainstream languages), but it still
 > > produces a surprise effect.
 >
 > That's the "floating point surprise" that everyone has at some point, no
matter the language and runtime system. If that surprise is a problem for
you, are you sure that floating-point arithmetic is what you really want?
Maybe your needs are better served with integers and fractions.
 >
 >
 > Konrad.
 >
 >
--
Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com
herunter.
12