[kolinko]

That's not what the post says if I understand correctly - the post explains why in certain situations the "noise" disappears, and in other cases it doesn't.

See comparison between f and g functions.

[098799]

I see! yes, the magic is you can cancel the noise by repeating it twice:

``` In [1]: math.exp(1e-15)-1 Out[1]: 1.1102230246251565e-15

In [2]: math.log(math.exp(1e-15)) Out[2]: 1.110223024625156e-15 ```

risky business though, I imagine it's implementation dependent

[DougBTX]

Agreed, this is risky business. The intermediate values still need to fit into floats and are still losing precision.

From the article:

    g(1e-9)  returns 1.0000000005,
    g(1e-12) returns 1.0000000000005,
    g(1e-15) returns 1.0000000000000004

but... g(1e-16) throws ZeroDivisionError: float division by zero.

[Sharlin]

It’s not (or shouldn’t be), it’s simply a result of math, as the article explains in length.

[lifthrasiir]

Many libm implementations don't have an accurate `log` or `exp` routine, so there does exist a risk. (Of course, it's also true that many of them also special-case `log(x) ~= x - 1` and `exp(x) ~= x + 1` for small enough `x`.)

[planede]

The math hinges on that there is the same error for exp(x) at both places. So as long as exp(x) is deterministic then this should be alright.

[adgjlsfhk1]

I don't know of any libm that have log or exp sufficiently inaccurate for this to break. Do you?

[lifthrasiir]

Indeed, any well-known enough libm wouldn't do that. But I can imagine some less-known libms with wild error bounds.