Float and integer arithmetic follow two different paradigms

https://blog.pkh.me/p/49-float-and-integer-arithmetic-follow-two-different-paradigms.html (blog.pkh.me)

60 points | 3d ago | Discuss on Hacker News | Back to Radar

Comments

weinzierl 6h ago on HN

The "integer arithmetic paradigm" would mean either checking after (almost) every operation or living with potentially incorrect results.

The first is terribly inefficient, the second is just wrong (even if insanely common).

This is sad because there is no reason at all why integers couldn’t follow what OP calls the "float paradigm". It doesn’t even have to be slow. Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.

There is also something to be said about the special treatment division by zero gets.

dnautics 5h ago on HN

Pretty sure zig has safe integer operations: integers aren't allowed to overflow with the standard operators, there are overflowing and saturating operators if that's what you want.

kibwen 4h ago on HN

> Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.

I'd say the reason that programming languages don't have built-in support for checking the CPU's sticky status flags is precisely because of a lack of x86 support. Plenty of languages do have support for checking overflow on each individual operation, e.g. Rust's `overflowing_foo` methods, which return a tuple whose second member is a boolean indicating overflow: https://doc.rust-lang.org/std/primitive.i32.html#method.over...

jcranmer 4h ago on HN

Sticky flags tend to be really annoying for a compiler to support for various reasons, but principally it makes every operation have a hidden dependency to shared global state that is almost never read. Note that IEEE 754 standardized support for sticky flags 40 years ago, but support for these sticky bits is still poor to nonexistent in most programming languages, and sticky bit stuff for floating-point operations is less problematic than integer operations because FP math is already far more black box in practice.

newpavlov 1h ago on HN

I mostly agree, but not with the flags part. From my past comment (https://news.ycombinator.com/item?id=45174074):

>I sometimes wish that signed integers were symmetrical. i8 would represent the range of [-127 to 127] with 0xFF representing NaN. Any operation which can not be computed (division by zero, overflows, operation with another NaN, etc.) would result in NaN. For further symmetry we could do the same for signed integers as well.

dooglius 5h ago on HN

FWIW one can configure floating point exceptions at runtime at no overhead, see `man 3 fenv`

westurner 4h ago on HN

fenv: https://manpages.debian.org/testing/manpages-dev/fenv.3.en.h... :

> These eleven functions were defined in C99, and describe the handling of floating-point rounding and exceptions (overflow, zero-divide, etc.).

dzaima 4h ago on HN

Except gcc doesn't actually support it to any sane extent (it ignores and warns on "#pragma STDC FENV_ACCESS ON", which C requires for fenv.h to actually function; and as such gcc makes a bunch invalid optimizations); clang supports it, but only as of somewhat-recently.

jcranmer 4h ago on HN

It's no overhead in the same sense that zero-cost exception-handling is zero-cost: turning them on properly (e.g., #pragma STDC FENV_ACCESS ON or equivalent command-line flags) disables a fair amount of optimizations which incurs an overhead in and of itself.

dooglius 1h ago on HN

Oh interesting I thought it was more or less a wrapper around MXCSR (or equivalent for other architectures)

a_e_k 3h ago on HN

For the float stuff, beware of `-ffinite-math-only`. If enabled, `isfinite()` and may compile out as assumed true (with similar assumptions around `isnan()` and `isinf()`).

And `-ffinite-math-only` is enabled by `-ffast-math` which in turn is enabled by `-Ofast`.

toolslive 2h ago on HN

Not only that: `-ffast-math` might change the result of flops when the arguments are regular floats too. (It abandons IEEE754 compliance)

Comments are loaded live from Hacker News and are not stored by Mid or Real.