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 
> 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 > 
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 
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. 
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. 
BTW why closeTo: is initialized by default with a value of 0.0001 ?
https://github.com/pharoproject/pharo/issues/3067
Sent from my iPhone On 7 Sep 2020, at 20:10, Sven Van Caekenberghe <[hidden email]> wrote:

In reply to this post by Sven Van Caekenberghe2
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 
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 > 
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 > > > 
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 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 
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 64bit IEEE floatingpoint 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: 
Free forum by Nabble  Edit this page 