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 <emaringolo@gmail.com> wrote:
On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz@gmail.com> 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