"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 <emaring...@gmail.com> wrote:
> Hi Sven,
>
> On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
> > > On 6 Sep 2020, at 22:21, Esteban Maringolo <emaring...@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
>
>
