alt Hacker NewsI do not agree that IEEE 754 is unclear or complicated. I think that it is one of the simplest standards that I have ever seen.
It is certainly orders of magnitude simpler than specifications for things like HTML, CSS, C++ or Vulkan.
The source of the problem is elsewhere. Unlike in the first 2 or 3 decades after the invention of automatic computers, nowadays there are much more than a half of the programmers who never encounter in their jobs the need to solve problems where complicated numeric computations are important and where the knowledge of mathematics branches like arithmetic and algebra is important.
Moreover, the programmers that happen to work on compilers or standard libraries for programming languages are even more likely to belong to the class of programmers who are not interested in computational applications.
This has led to the current situation, when almost all programming languages, especially the most popular of them, have bad defaults for the IEEE 754 options and they provide very awkward means to access all the facilities specified by the standard.
A decent programming language should have 2 distinct types for floating-point numbers, one for those that cannot be NaNs (to be used only in a program that enables and handles invalid operation exceptions) and one for floating-point numbers that may be NaNs (to be used in programs that disable the invalid operation exception, like most programming languages wrongly do by default).
Moreover, a decent programming language should have 14 relational operators, to enable the correct use of partially-ordered sets, e.g. also for user-defined data types, not only for floating-point numbers.
With a standard programming language, which has only 6 relational operators, if one insists on keeping disabled the invalid operation exception, then every floating-point comparison must be preceded by testing the operands for being a NaN, which is tedious.
Replies
> A decent programming language should have 2 distinct types for floating-point numbers, one for those that cannot be NaNs (to be used only in a program that enables and handles invalid operation exceptions) and one for floating-point numbers that may be NaNs (to be used in programs that disable the invalid operation exception, like most programming languages wrongly do by default).
You've already explained why such a type separation is a bad idea - those types being only usable with specific setup; so, completely utterly breaking composability.
Never mind this making float ops impure & stateful (also forbidding autovectorizing anything with more than one potentially-NaN-producing op if you don't want to break semantics).
Perhaps if hardware supported embedding exception behavior in individual instructions this'd not be insane, but I haven't heard of any architecture having such, making it a complete non-option for sane languages designed to be used.
(there is the option of making compilers insert the necessary fp state transitions, though then you'll have the desire to embed it into calling conventions & function types to avoid transitions when a certain state is expected to stay for a prolonged period of time, which, while certainly possible and would be quite neat to have (also for rounding modes, FTZ/DAZ, etc), is very much in the territory of something almost noone will bother doing, and as such things would just quietly be slower)
While partially-ordered types are neat, what can you really sanely do with a comparison over such? Seems like a rather pointless thing to have.
> Moreover, a decent programming language should have 14 relational operators, to enable the correct use of partially-ordered sets, e.g. also for user-defined data types, not only for floating-point numbers.
Is this a well-known set that I've never heard of? What are the other 8? Subset, superset, structural equality? Logical equivalence?