3 ms·

> that's the local optimum for a hardware implementation and it will remain so even once we have decimal fp numbers of the same speed as integers This doesn't

> that's the local optimum for a hardware implementation and it will remain so even once we have decimal fp numbers of the same speed as integers This doesn't preclude the use of twos complement, and twos complement isn't enforced (or mentioned) in C's standard. It doesn't need to be expensive, either - as said in the article, "These should be simple ALU hacks." I don't see any reason why these operations on processors would be slower than the ones we have already. I wouldn't be surprised if they used a few more transistors, but on the scale of today's processors it won't cost anything at all compared to all of the silicon required for instruction pipelining, branch prediction and out-of-order execution. > a lot of other and older languages have the same behavior This isn't true either. If you'd take the time to read the other posts on the site (and probably the LLVM guide to undefined behaviour[1]) you'll find that the C and C++ standards place quite different restrictions on the behaviour of integers than, say, Java (which is by comparison rather strict). The loop that you say "would never end"? It would end. When `x` overflows it'll be set to `iNaN`, and the loop will exit. Your "order of operations" complaint? He's talking about simple, unobvious errors with a real-life example. He then proposes semantics for a new language that would solve this problem. What's your complaint here? On the whole I thought John came up with a bunch of ideas, most of them good, almost all of them better than the status quo. I thought your post was the exactly the sort of knee-jerk response I've come to expect from Reddit. [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

acqq 15y ago
"The loop that you say "would never end"? It would end. When `x` overflows it'll be set to `iNaN`, and the loop will exit." I see you don't have experience with NaN semantics: http://en.wikipedia.org/wiki/NaN http://en.wikipedia.org/wiki/NaN "A comparison with a NaN always returns an unordered result even when comparing with itself." If you say "but iNaNs would be different" you already missed the point.
- repsilat 15y ago
  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.
Locke1689 15y ago
People also seem to be ignorant of the fact that this is from John Regehr, author of CSmith. He probably knows the C standard and C compiler behavior as well as the primary C compiler developers. He's well aware of the issues of backwards compatibility but is ignoring them for the purposes of this post.

acqq 15y ago

"The loop that you say "would never end"? It would end. When `x` overflows it'll be set to `iNaN`, and the loop will exit." I see you don't have experience with NaN semantics: http://en.wikipedia.org/wiki/NaN http://en.wikipedia.org/wiki/NaN "A comparison with a NaN always returns an unordered result even when comparing with itself." If you say "but iNaNs would be different" you already missed the point.

repsilat 15y ago
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.

Locke1689 15y ago

People also seem to be ignorant of the fact that this is from John Regehr, author of CSmith. He probably knows the C standard and C compiler behavior as well as the primary C compiler developers. He's well aware of the issues of backwards compatibility but is ignoring them for the purposes of this post.