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

Floats Don't Agree with Themselves

docs.merca.earth

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Floats Don't Agree with Themselves

#21

Post by TomMasz »

antiquark wrote: post #16

That's why they always teach: "never compare floats for equality." Or maybe they don't teach that anymore, I dunno. See link for the Fundamental Axiom of Floating Point Arithmetic: All floating point arithmetic operations are exact up to a relative error of epsilon_machine. https://www.johnbcoughlin.com/posts/floating-point-axiom/

I certainly teach that. When we work problems involving money, I always recommend students use integers for cents and only convert to dollars and cents when they have to print them.

Re: Floats Don't Agree with Themselves

#22

Post by moi2388 »

weberer wrote: post #19
stuaxo wrote: post #7

Not sure if this was written with AI assistance of not, but I've become allergic to linguistic triples as LLMs use them so much, reading "Same code. Same input. Different answer" makes me not want to read the rest.

Its weird that almost every AI generated blurb tends to have that. Usually followed by "Its not just X, its Y". I wonder where they picked that up from.

My guess is LinkedIn posts and YouTube transcriptions. I notice the pattern almost exclusively being used there.

Re: Floats Don't Agree with Themselves

#23

Post by LegionMammal978 »

sampo wrote: post #10

I wish the blog would reveal the values of the 3 floats that make their cross_sign(A, B, C) to give different results in different platforms.

At least the Rust compiler (TFA's project is written in Rust) tries to configure LLVM specifically to avoid these discrepancies, and to treat all basic floating-point operations exactly as written with round-to-nearest behavior [0]. It does not have any of the -ffast-math options that the author('s LLM) is panicking about.

The main caveat is that on x86 targets without SSE2, LLVM is deeply wired to use the x87 instructions without attempting to emulate the IEEE overflow/underflow behavior [1]. So perhaps it could be possible to exhibit a discrepancy, but only by compiling for i586 and an ancient target-cpu. It's very doubtful that this was the cause of the original client vs. server issue in TFA's introduction.

[0] https://rust-lang.github.io/rfcs/3514-float-semantics.html

[1] https://github.com/rust-lang/rust/issues/114479

Re: Floats Don't Agree with Themselves

#25

Post by mcdonje »

stuaxo wrote: post #7

Not sure if this was written with AI assistance of not, but I've become allergic to linguistic triples as LLMs use them so much, reading "Same code. Same input. Different answer" makes me not want to read the rest.

Yeah, they often call this to mind: "Better ingredients. Better pizza. Papa John's."

Re: Floats Don't Agree with Themselves

#26

Post by xnorswap »

stuaxo wrote: post #7

Not sure if this was written with AI assistance of not, but I've become allergic to linguistic triples as LLMs use them so much, reading "Same code. Same input. Different answer" makes me not want to read the rest.

It's clearly AI written as are quite a few of the posts on the front-page now.

We seem to have lost the war for people to find their own voice, the AI articles are getting widely upvoted, and people pointing out they are AI are no longer getting traction, people don't seem to care.

Re: Floats Don't Agree with Themselves

#28

Post by happytoexplain »

> It was IEEE 754 working as advertised. The standard pins down the storage format. It does not pin down behavior.

Huh? This is just false, isn't it? AFAIK, it pins down behavior, and the differences come from things like changing the order of operations (i.e. accumulating rounding error in a different order). I'm not an expert, though.

Re: Floats Don't Agree with Themselves

#30

Post by LegionMammal978 »

IshKebab wrote: post #29

This seems to be AI bullshit. You can easily get deterministic floats that give the same results everywhere. Just don't use -ffast-math.

Alas, compilers have historically fudged the behavior on some 32-bit targets, e.g., x86 targets without SSE2 [0], so you'd have to go all the way to soft-float implementations if you really want guarantees. But these targets are rare, and very unlikely to be the cause of the original issue.

(And NaN payloads in general are a mess across platforms and ABIs, but that can be solved by treating all NaNs as identical.)

[0] https://github.com/rust-lang/rust/issues/114479

Post reply on HN