3 ms·

The author is proposing semantics for instruction sets and languages that don't exist. He could have said "`!(x is iNaN)`", or "`!isINAN(x)`" instead of "`x !=

The author is proposing semantics for instruction sets and languages that don't exist. He could have said "`!(x is iNaN)`", or "`!isINAN(x)`" instead of "`x != iNaN`", but he didn't. Maybe he should have, I'm sure he didn't give it much thought. Nowhere does he say that the semantics of his `iNaN` are exactly analogous to the those of existing floating-point NaNs, though. Implying that he did so that you have one more nit to pick damages the tone of conversation.

acqq 15y ago
"Nowhere does he say that the semantics of his `iNaN` are exactly analogous to the those of existing floating-point NaNs" Since current semantics is used everywhere today, using semantics that you imply for some new cases and keeping the current for existing would immensely add to confusion and it would be wrong. It's not nit to pick, it obviously shows that author (and you too) is not acquainted with something that should be a common knowledge in the profession since at least 1985, http://en.wikipedia.org/wiki/IEEE_754-1985 http://en.wikipedia.org/wiki/IEEE_754-1985 And that was exactly my point since my first post.
- esrauch 15y ago
  The chances that the author is not aware of what you are talking about is near 0, and what he is writing isn't an actual suggested specification it is musings about pain points in the current way that things work. You are complaining about a single line of code that demonstrates a concept that cannot possibly be executed and there isn't any actual effort to make this line into something that can be executed. You are arguing that it is a bad idea for a reason that is completely orthogonal to the spirit of the post. So sure, implicit in that loop is the idea that iNaN would be treated subtly different than existing NaNs, but you are just responding to the text of an example that is written to be as simple and clear as possible to readers rather than the actual content of his message, which is nit picking at best.

acqq 15y ago

"Nowhere does he say that the semantics of his `iNaN` are exactly analogous to the those of existing floating-point NaNs" Since current semantics is used everywhere today, using semantics that you imply for some new cases and keeping the current for existing would immensely add to confusion and it would be wrong. It's not nit to pick, it obviously shows that author (and you too) is not acquainted with something that should be a common knowledge in the profession since at least 1985, http://en.wikipedia.org/wiki/IEEE_754-1985 http://en.wikipedia.org/wiki/IEEE_754-1985 And that was exactly my point since my first post.

esrauch 15y ago
The chances that the author is not aware of what you are talking about is near 0, and what he is writing isn't an actual suggested specification it is musings about pain points in the current way that things work. You are complaining about a single line of code that demonstrates a concept that cannot possibly be executed and there isn't any actual effort to make this line into something that can be executed. You are arguing that it is a bad idea for a reason that is completely orthogonal to the spirit of the post. So sure, implicit in that loop is the idea that iNaN would be treated subtly different than existing NaNs, but you are just responding to the text of an example that is written to be as simple and clear as possible to readers rather than the actual content of his message, which is nit picking at best.