4 ms·

What does computer architecture have to do with this? What is your explanation for why this happens?

by Kranar 4y ago

Koshkin 4y ago
If you care about efficiency, you have to take computer architecture into account. (One important example is that floating-point numbers are not reals we tend to think of them as.)
- Kranar 4y ago
  The example provided has nothing to do with computer architecture or efficiency. In fact if anything it's less efficient than what most computer architectures provide natively. I'm questioning OP because I have strong doubts that he actually understands C's integer promotion rules that he can claim that it's basic stuff. They are very subtle and even C and C++ experts get bitten by them.
  - Koshkin 4y ago
    The usual computer architecture includes the representation of floating-point numbers that is a very efficient (albeit imprecise) model of the reals.
    - Kranar 4y ago
      The example has nothing to do with floating points not to mention most computer architectures do not have floating point units.
edflsafoiewq 4y ago
The underlying assumption is the architecture provides instructions that operate as numtype x numtype -> numtype, with int being the smallest possible numtype. To execute a + b it must be mapped onto one of these instructions. For example, char + short would get mapped onto the int x int -> int instruction. The usual arithmetic conversions formalize the algorithm for doing this. If you ignore signedness, the rule is extremely simple and natural: numtype = max(type(a), type(b), int), where char < short < int < long < long long < float < double < long double. Signedness throws a wrench into the works though.
- Kranar 4y ago
  That assumption would be incorrect then.
tines 4y ago
The underlying architecture of the machine defines the representations of the integer multiplicands (two's complement in the case the author is referring), so the bit pattern that results from doing the multiplication is interpreted as the negative number given, according to the architecture. That's all I meant.
- Kranar 4y ago
  Ah okay, well what you said is simply untrue. It's the C++ standard that requires two's complement (S 6.8.1.3 mandates this) regardless of architecture. The reason for the negative result has nothing to do with computer architecture and has to do with C++'s integer promotion rules which promote an unsigned 16-bit integer to a signed int. There is a reason that the author explicitly states that MSVC is the compiler that produces this output, because clang and GCC do not do so, even if they run on the same computer architecture. This is due to the fact that both those compilers can recognize that signed integer overflow is undefined behavior and leverage this fact. As others have said, to consider these details just basic things is absurd. Almost no one knows this stuff, including you.
  - tines 4y ago
    > It's the C++ standard that requires two's complement I looked into this and you're totally right! But it actually didn't until relatively recently. Other representations were explicitly permitted by the standard at least until C++14 or so, what I said should be interpreted in that context. (And in fact, the standard requires it _because_ architecture was already universally designed that way, which I know you already know.) Thanks for the information though, this is good to know. > The reason for the negative result has nothing to do with computer architecture An existing conforming implementation will produce the bit patterns given in the article because of the architecture of the machine it's running on, so that's why I mentioned architecture. > and has to do with C++'s integer promotion rules which promote an unsigned 16-bit integer to a signed int. For sure, it also has to do with that, it just wasn't relevant to the "architecture" part of my comment which I was explaining, so I omitted it. I think we're saying the same thing from different points of view. > As others have said, to consider these details just basic things is absurd. I guess I'm inured to it, having worked at this level of abstraction for a long time haha. This is why progress is made one funeral at a time I suppose D: > Almost no one knows this stuff, including you. There are a lot of things I don't know, and this may be one of them! Thanks for your responses.

What does computer architecture have to do with this? What is your explanation for why this happens?

by Kranar 4y ago

What does computer architecture have to do with this? What is your explanation for why this happens?

If you care about efficiency, you have to take computer architecture into account. (One important example is that floating-point numbers are not reals we tend to think of them as.)

Kranar 4y ago
The example provided has nothing to do with computer architecture or efficiency. In fact if anything it's less efficient than what most computer architectures provide natively. I'm questioning OP because I have strong doubts that he actually understands C's integer promotion rules that he can claim that it's basic stuff. They are very subtle and even C and C++ experts get bitten by them.
- Koshkin 4y ago
  The usual computer architecture includes the representation of floating-point numbers that is a very efficient (albeit imprecise) model of the reals.
  - Kranar 4y ago
    The example has nothing to do with floating points not to mention most computer architectures do not have floating point units.

edflsafoiewq 4y ago

The underlying assumption is the architecture provides instructions that operate as numtype x numtype -> numtype, with int being the smallest possible numtype. To execute a + b it must be mapped onto one of these instructions. For example, char + short would get mapped onto the int x int -> int instruction. The usual arithmetic conversions formalize the algorithm for doing this. If you ignore signedness, the rule is extremely simple and natural: numtype = max(type(a), type(b), int), where char < short < int < long < long long < float < double < long double. Signedness throws a wrench into the works though.

Kranar 4y ago
That assumption would be incorrect then.

tines 4y ago

The underlying architecture of the machine defines the representations of the integer multiplicands (two's complement in the case the author is referring), so the bit pattern that results from doing the multiplication is interpreted as the negative number given, according to the architecture. That's all I meant.

Kranar 4y ago
Ah okay, well what you said is simply untrue. It's the C++ standard that requires two's complement (S 6.8.1.3 mandates this) regardless of architecture. The reason for the negative result has nothing to do with computer architecture and has to do with C++'s integer promotion rules which promote an unsigned 16-bit integer to a signed int. There is a reason that the author explicitly states that MSVC is the compiler that produces this output, because clang and GCC do not do so, even if they run on the same computer architecture. This is due to the fact that both those compilers can recognize that signed integer overflow is undefined behavior and leverage this fact. As others have said, to consider these details just basic things is absurd. Almost no one knows this stuff, including you.
- tines 4y ago
  > It's the C++ standard that requires two's complement I looked into this and you're totally right! But it actually didn't until relatively recently. Other representations were explicitly permitted by the standard at least until C++14 or so, what I said should be interpreted in that context. (And in fact, the standard requires it _because_ architecture was already universally designed that way, which I know you already know.) Thanks for the information though, this is good to know. > The reason for the negative result has nothing to do with computer architecture An existing conforming implementation will produce the bit patterns given in the article because of the architecture of the machine it's running on, so that's why I mentioned architecture. > and has to do with C++'s integer promotion rules which promote an unsigned 16-bit integer to a signed int. For sure, it also has to do with that, it just wasn't relevant to the "architecture" part of my comment which I was explaining, so I omitted it. I think we're saying the same thing from different points of view. > As others have said, to consider these details just basic things is absurd. I guess I'm inured to it, having worked at this level of abstraction for a long time haha. This is why progress is made one funeral at a time I suppose D: > Almost no one knows this stuff, including you. There are a lot of things I don't know, and this may be one of them! Thanks for your responses.