Floats Don't Agree with Themselves (opens in new tab)

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.

a tricolon crescens ^^ https://latinaadvitam.blogspot.com/2007/02/poetry-device-of-...

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.

Same. I now tend to simply abandon writing when I see those tell tale signs

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

I also got turned off after the very first paragraph. Too bad, because the content itself might be fine, but the AI language has become repulsive.

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

The C compiler also isn't allowed to do all of them. However some people use fast-math or compilers that default to fast-math to break the rules. Some older targets also may use the 80 bit fpu, which is its own mess and any sane compiler will default to properly sized SSE instructions instead.

On x86, LLVM does not follow strict IEEE 754 behavior all the time.

IIRC it also depends on the CPU's storage and capabilities.

Yeah, in general, this is a problem that people have spent a lot of time thinking about; while floating-point numbers can be finicky, they're what you have to work with if you have inputs at multiple scales.

(Meanwhile, I wonder why it's a fair bit harder to look up Ozaki et al.'s optimized version [0] compared to Shewchuk's original paper [1], unless perhaps later authors have found it to be no improvement at all.)

[0] https://www.tuhh.de/ti3/paper/rump/OzBueOgOiRu15.pdf

[1] https://people.eecs.berkeley.edu/~jrs/papers/robust-predicat...

his predicates paper opens with "Computational geometers despise floating-point arithmetic" same trick as the CG title: write the sentence a frustrated reader would write, then aren it.. if you like those the Triangle paper is the third one in the same key

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.

On the other hand, if you store a small integer in a float it is generally reliable to compare to it. E.g., setting a float to zero and comparing whether the float is zero.

careful what you wish for, x87's extended precision is what wrote the original bug: 80 bits in registers,64 on a spill, so the value depended on register pressure

ARM and WASM dropped it for a reason, and more bits would not help anyway, a sign is one bit, any rounding step that disagrees at the last bit flips it