-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with process = (1.0 + ma.EPSILON/2.0) > 1.0 #962
Comments
It is clear why -single/-double makes a difference in this case, To be honest, I never really understood the purpose of ma.EPSILON.
is it DBL_MIN? Or DBL_TRUE_MIN? Nevermind. In any case I'd say it should be used with care.
OK, lets suppose that "0" is correct in this case. Now consider
compiled in double, it outputs
Doesn't look consistent but what can we do? and do we really care? Oleg. |
|
On Sun, 29 Oct 2023 at 22:47, oleg-nesterov ***@***.***> wrote:
It is clear why -single/-double makes a difference in this case,
but...
To be honest, I never really understood the purpose of ma.EPSILON.
And what is it? Say,
doubleprecision EPSILON = 2.2204460492503131e-016;
is it DBL_MIN? Or DBL_TRUE_MIN?
I think that it is defined as the smallest quantity, let's call it EPS, for
which (1.0 + EPS) > 1.0 returns true.
I'm sure that you know issues related to float comparison and numerical
errors better than, so what I think it's useful for is comparisons: you
can't do (.1 + .2) == .3, it will return false, so you'd normally do
abs((.1 + .2) - .3) < EPS.
Nevermind. In any case I'd say it should be used with care.
process = (1.0 + ma.EPSILON/2.0) > 1.0 correctly returns 0 when
compiled in -double
OK, lets suppose that "0" is correct in this case. Now consider
import("stdfaust.lib");
process =
(0.0 + ma.EPSILON/2.0) > 0.0,
(0.5 + ma.EPSILON/2.0) > 0.5,
(1.0 + ma.EPSILON/2.0) > 1.0;
compiled in double, it outputs
1, 1, 0
Doesn't look consistent but what can we do? and do we really care?
I think that a common way to make EPS more useful for comparisons is to
scale it down by the max abs of the two terms, but it's still not the most
precise way of comparing floats. If you did that, you'd get 0, 1, 1, which
is still not perfect but a but better.
I don't think that this bug is a big deal at all; I only noticed it because
I was working in double and I could still hear artefacts that made me think
of noise from numerical errors. So I tested that to make sure that
FaustLive was taking the -double flag correctly.
Dario
Oleg.
…
—
Reply to this email directly, view it on GitHub
<#962 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHG3I2BKQBSTITZHJAJWQH3YB26ENAVCNFSM6AAAAAA6U5OUUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGIZTGOBYGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Ah. Yes, yes, I know. And I too wrote the similar program to verify. Sorry for confusion. When I said "Doesn't look consistent" I meant "Doesn't look consistent but in fact correct". My only point was, again, in any case ma.EPSILON should be used with care.
and do not output the same result. And I think we do not really care. But I agree that the fact it depends on -single/-double make the things worse. |
OK, quite possible, then ma.EPSILON == nextafter(1.0,2.0) - 1.0 And this means that even a more simple example can surprise the user:
compiled with -double outputs
Again, this is correct in that this is how the FP math works. But again, this means that ma.EPSILON should be used with care. |
I guess we want |
Improved documentation: https://faustlibraries.grame.fr/libs/maths/#maepsilon |
The code
process = (1.0 + ma.EPSILON/2.0) > 1.0
correctly returns 0 when compiled in-double
but incorrectly returns 1 when compiled in-single
.Even if
ma.EPSILON
definition is dependant of-single/-double/-quad
(see https://github.com/grame-cncm/faustlibraries/blob/master/maths.lib#L157), the internal computation is actually usingdouble
and has to be fixed.The text was updated successfully, but these errors were encountered: