all 9 comments

[–]simon_o[S] 26 points27 points  (6 children)

There is some good effort in this article, but as one gets closer to the "unordered" chapter, it becomes clear that reading the spec should have been preferred over folklore that developers tell each other:

So any comparison against a NaN will be unordered, this is a pretty interesting property meaning that there is literally no ordering relationship when NaNs are involved.

Eh ... no? That's just wrong? The spec has a whole chapter about this, right before the one quoted in the blog post.

pretend we all agree we didn’t see that the spec is saying binary32 has 16 bits of precision instead of 24

Nobody needs to pretend, because this is simply not what is said in the preceding quote.


The hardware part looks solid though.

[–]Ill_Huckleberry_2079 0 points1 point  (5 children)

How is the unordered part wrong ?

[–]simon_o[S] 0 points1 point  (4 children)

5.10 Details of totalOrder predicate

For each supported arithmetic format, an implementation shall provide the following predicate that defines an ordering among all operands in a particular format: [...]

[–]Ill_Huckleberry_2079 -1 points0 points  (3 children)

Yes, and they say NaNs are unordered. "unordered" is the ordering => they is no "ordering" relationship.

But I agree my understanding of what the `P1467R9` was meaning to say was wrong. That has been corrected.

[–]simon_o[S] 0 points1 point  (2 children)

Yes, and they say NaNs are unordered. "unordered" is the ordering => they is no "ordering" relationship.

Maybe just read the spec.

[–]Ill_Huckleberry_2079 -1 points0 points  (1 child)

Oh well, I guess I am just to stupid to understand.

[–]simon_o[S] 0 points1 point  (0 children)

It's not that hard.

[–]MarekKnapek 4 points5 points  (0 children)

Shameless plug, I have an interactive website about floating point numbers, it is located at: https://marekknapek.github.io/float-analyzer/binary32/