Of what, IEEE-754? Given how poorly most languages implement it (and how many shortcuts are taken in the same of speed), I'm not sure IEEE-754 is the problem.

▲

johnsonjo a day ago | parent | next [-]

Other than the IEE-754 he might mean the Wat talk [1] by Gary Bernhardt which is kind of famous for poking fun at JavaScript (and it's unpredictability with things like NaN. As a JS developer myself I find it hilarious.) Though I don't know why it would need to be remade he at least referenced the talk, it seems, with the word Wat, so it's worth mentioning at least I guess

[1]: https://www.destroyallsoftware.com/talks/wat

▲

t-3 a day ago | parent | prev [-]

I believe the other poster is correct, that OP is referencing the video "Wat" (https://www.destroyallsoftware.com/talks/wat), but I think that if most implementations of a standard are poor, the standard is probably the problem. It's likely to be either unclear or too complicated.

▲

aragilar 2 hours ago | parent | next [-]

I would say the complexity of IEEE-754 is warranted (given the history of the standard), but the issue is those writing languages are typically not aware of numerical computing (it's rarely a course at university), and so do not design their languages with it in mind (or predate IEEE-754). This leads to implementations and ecosystems which do not consider it, and we end up with systems where giving the required control to implement IEEE-754 conflict with other requirements (e.g. security, imagine if you could control rounding mode via the browser).

▲

adrian_b a day ago | parent | prev [-]

I 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.

	▲	t-3 a day ago \| parent \| next [-]
		> 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?
	▲	dzaima a day ago \| parent \| prev [-]
		> 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.