### Re: Phix, numbers, printf, log10

RobertS said...

but, 9.989e16 is integer, too, but 9.98e16 is not an integer

I expect that's just the luck of the draw, 9.98 is out by the tiniest amount, as is 9.989, but after multiplication by 1e16 one of said tiniest amounts ends up being zero (see below)...

RobertS said...

But, round() correctly rounds 2.85 up â€” printf(1, "%0.1f\n", round(2.85, 10)) says 2.9.

From what I've seen so far, round() (however it does it) may indeed solve this unsolveable issue, or haven't I tested enough and am too optimistic?

Your guess is as good as mine.. (2.75 can be represented exactly, as can 28.5, which is why I used them here):

```?(2.85-2.75)*10-1   -- 8.881784197e-16 (on 32-bit, -8.67361738e-19 on 64-bit)
?(2.85*10)-28.5     -- 0 (on both)
```

Probably pretty much impossible to say precisely why, without studying the FPU core transistor-by-transistor...
Presumably some very clever minds found some weird ways to make the FPU more accurate than simple logic might suggest.
You probably are being a smidge optimistic if you think that sort of thing is always going to work out in your favour (but o/c use it if >=51%).
Disclaimer: round() is based on Euphoria code, RobC quite likely tried out several approaches and picked the best he could find.
Note that for obvious reasons printf() works digit-by-digit then rounds, so always matching round() is simply not an option.