"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 <emaringolo@gmail.com> wrote:
Hi Sven,

On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:

> > On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo@gmail.com> 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