←back to thread

211 points Twirrim | 1 comments | | HN request time: 1.109s | 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(8): >>41875213 #>>41875351 #>>41875749 #>>41875859 #>>41876173 #>>41876461 #>>41876831 #>>41877394 #
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(1): >>41876108 #
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(3): >>41876218 #>>41876269 #>>41876272 #
1. lf37300 ◴[] No.41876272[source]
If not done properly, double rounding (round to extended precision then rounding to working precision) can actually introduce larger approximation error than round to nearest working precision directly. So it can actually make some numerical algorithms perform worse.