Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's OK to compare floating-points for equality

lisyarus.github.io

Post reply on HN
Print view View original

71–80 of 150 posts

Re: It's OK to compare floating-points for equality

#71

Post by colechristensen »

tialaramex wrote: post #68
colechristensen wrote: post #60

Earlier quoted context omitted.

I think a key you may want is ε which scales with the actual local floating point increment. C++ implements this https://en.cppreference.com/cpp/numeric/math/nextafter Rust does not https://rust-lang.github.io/rfcs/3173-float-next-up-down.htm... but people have in various places.

Um, what? You've linked an RFC for Rust, but the CPP Reference article for C++ So yeah, the Rust RFC documents a proposed change, and the C++ reference documents an implemented feature, but you could equally link the C++ Proposal document and the Rust library docs to make the opposite point if you wanted. Rust's https://doc.rust-lang.org/std/primitive.f32.html#method.next... https://doc.rust-lang.org/std/primitive.f3…

Oh, my research was wrong and the line from the RFC doc...

>Currently it is not possible to answer the question ‘which floating point value comes after x’ in Rust without intimate knowledge of the IEEE 754 standard.

So nevermind on it not being present in Rust I guess I was finding old documentation

Re: It's OK to compare floating-points for equality

#72

Post by thayne »

jph wrote: post #7

I have this floating-point problem at scale and will donate $100 to the author, or to anyone here, who can improve my code the most. The Rust code in the assert_f64_eq macro is: if (a >= b && a - b I'm the author of the Rust assertables crate. It provides floating-point assert macros much as described in the article. https://github.com/SixArm/assertables-rust-crate/blob/main/s... If there's a way to make it more prec…

You should allow the user to supply the epsilon value, because the precision needed for the assertion will depend on the use case.

Re: It's OK to compare floating-points for equality

#73

Post by GuB-42 »

The thing with floating point numbers is they are meant to work with physical quantities: distances, durations, etc...

Physical quantities involve imprecision: measurement devices, tools, display devices, ADC/DACs etc... They all have some tolerances. And when you are using epsilons, the epsilon value should be chosen based on that physical value. For example, you set the epsilon to 1e-4 because that's 100 microns and you can't display 100 micron details.

That's also the reason why there is not one size fits all solution. If you are working with microscopic objects, 100 microns is huge, and if you are doing a space simulation, 1 km may be negligible. Some operations involve a huge loss of precision, some don't, and sometimes you really want exact numbers and therefore you have to know your fractional powers of 2.

Re: It's OK to compare floating-points for equality

#74

Post by vouwfietsman »

throwup238 wrote: post #34
vouwfietsman wrote: post #21

This explanation is relatively reductive when it comes to its criticism of computational geometry. The thing with computational geometry is, that its usually someone else's geometry , i.e you have no control over its quality or intention. In other words, whether two points or planes or lines actually align or align within 1e-4 is no longer really mathematically interesting because its all about the intention of the u…

> This is why most geometry kernels (see open cascade) sport things like "fuzzy boolean operations" [0]) that lean into epsilons. These epsilons mask the error-prone supply chain of these meshes that arrive in your program by allowing some tolerance. They don’t just lean into epsilons, the session context tolerance is used for almost every single point classification operation in geometric kernels and many primitives…

Nice thanks, gotta love knowing a bit about a niche and then encountering someone who knows a great deal more. That's the beauty of HN.

Could you point to any literature/freely available resource that comes close to the SOTA for these kinds of operations? I would be greatly helped.

Re: It's OK to compare floating-points for equality

#75

Post by vouwfietsman »

MarkusQ wrote: post #40
throwup238 wrote: post #34

Earlier quoted context omitted.

> This is why most geometry kernels (see open cascade) sport things like "fuzzy boolean operations" [0]) that lean into epsilons. These epsilons mask the error-prone supply chain of these meshes that arrive in your program by allowing some tolerance. They don’t just lean into epsilons, the session context tolerance is used for almost every single point classification operation in geometric kernels and many primitives…

> They don’t just lean into epsilons, the session context tolerance is used for almost every single point classification operation in geometric kernels and many primitives carry their own accumulating error component for downstream math. The GP wasn't wrong. To "lean in" means to fully commit to, go all in on, (or, equivalently, go all out on).

I think his point is: rather than "leaning into" it as in, masking through epsilons, he argues that tolerance is fundamental to the problem space, not a way to resolve edge cases.

Re: It's OK to compare floating-points for equality

#76

Post by meindnoch »

jph wrote: post #7

I have this floating-point problem at scale and will donate $100 to the author, or to anyone here, who can improve my code the most. The Rust code in the assert_f64_eq macro is: if (a >= b && a - b I'm the author of the Rust assertables crate. It provides floating-point assert macros much as described in the article. https://github.com/SixArm/assertables-rust-crate/blob/main/s... If there's a way to make it more prec…

Well, could you please describe a scenario where you think this assertion would be useful?

Re: It's OK to compare floating-points for equality

#77

Post by beyondCritics »

If your code may be compiled, to use the Intel x87 numerical coprocessor, an important issue is the so called "excess precision": Different values on chip can collapse after being rounded and stored to their memory locations, invalidating previous comparisons. Spilling can happen unexpectedly. Note that Intel calls the x87 "legacy"

Re: It's OK to compare floating-points for equality

#78

Post by pclmulqdq »

beyondCritics wrote: post #77

If your code may be compiled, to use the Intel x87 numerical coprocessor, an important issue is the so called "excess precision": Different values on chip can collapse after being rounded and stored to their memory locations, invalidating previous comparisons. Spilling can happen unexpectedly. Note that Intel calls the x87 "legacy"

Nobody's code will be compiled to use x87 any more.

Re: It's OK to compare floating-points for equality

#80

Post by waffletower »

GuB-42 wrote: post #73

The thing with floating point numbers is they are meant to work with physical quantities: distances, durations, etc... Physical quantities involve imprecision: measurement devices, tools, display devices, ADC/DACs etc... They all have some tolerances. And when you are using epsilons, the epsilon value should be chosen based on that physical value. For example, you set the epsilon to 1e-4 because that's 100 microns an…

This is highly reductive, "they are meant to work with physical quantities", but agree that the applicability of an epsilon is entirely situational.
Post reply on HN