←back to thread

288 points Twirrim | 2 comments | | HN request time: 0.502s | source
Show context
favorited ◴[] No.41875023[source]
Previously, in JF's "Can we acknowledge that every real computer works this way?" series: "Signed Integers are Two’s Complement" <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...>
replies(1): >>41875200 #
jsheard ◴[] No.41875200[source]
Maybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not.

https://github.com/torvalds/linux/blob/master/include/math-e...

replies(9): >>41875213 #>>41875351 #>>41875749 #>>41875859 #>>41876173 #>>41876461 #>>41876831 #>>41877394 #>>41877730 #
FooBarBizBazz ◴[] No.41875749[source]
Whether double floats can silently have 80 bit accumulators is a controversial thing. Numerical analysis people like it. Computer science types seem not to because it's unpredictable. I lean towards, "we should have it, but it should be explicit", but this is not the most considered opinion. I think there's a legitimate reason why Intel included it in x87, and why DSPs include it.
replies(2): >>41875950 #>>41876023 #
stephencanon ◴[] No.41876023[source]
Numerical analysis people do not like it. Having _explicitly controlled_ wider accumulation available is great. Having compilers deciding to do it for you or not in unpredictable ways is anathema.
replies(2): >>41876108 #>>41879704 #
bee_rider ◴[] No.41876108[source]
It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.
replies(4): >>41876218 #>>41876269 #>>41876272 #>>41878039 #
stephencanon ◴[] No.41878039[source]
It’s absolutely harmful. It turns computations that would be guaranteed to be exact (e.g. head-tail arithmetic primitives used in computational geometry) into “maybe it’s exact and maybe it’s not, it’s at the compiler’s whim” and suddenly your tests for triangle orientation do not work correctly and your mesh-generation produces inadmissible meshes, so your PDE solver fails.
replies(1): >>41879828 #
1. FooBarBizBazz ◴[] No.41879828[source]
Thank you, I found this hint very interesting. Is there a source you wouldn't mind pointing me to for those "head, tail" methods?

I am assuming it relates to the kinds of "variable precision floating point with bounds" methods used in CGAL and the like; Googling turns up this survey paper:

https://inria.hal.science/inria-00344355/PDF/p.pdf

Any additional references welcome!

replies(1): >>41882842 #
2. stephencanon ◴[] No.41882842[source]
Note here is a good starting point for the issue itself: http://www.cs.cmu.edu/~quake/triangle.exact.html

References for the actual methods used in Triangle: http://www.cs.cmu.edu/~quake/robust.html