4 ms·

> Do you know that in MSVC uint16_t(50000) + uin16_t(50000) == -1794967296? This is pretty basic C++/computer architecture stuff. > They just don’t give you a

by tines 4y ago

> Do you know that in MSVC uint16_t(50000) + uin16_t(50000) == -1794967296? This is pretty basic C++/computer architecture stuff. > They just don’t give you a competitive advantage over C++. Or, for that matter, even over each other. Most of them, for instance, Rust, Julia, and Cland even share the same backend. You can’t win a car race if you all share the same car. But it's the same backend that C++ uses...? > Because if you can write in Python and have the performance of C++, why would you want to write in C++? I'm no rust fanboy, but isn't this the argument he used against Rust in the first place?

otabdeveloper4 4y ago
Python in 2023 is like Perl in 1996. Given the choice I'd rather program in anything else.
- eggy 4y ago
  Exactly! I liked using it to program Blender3D scripts in 2004/5, but then lost any love for Python.
- drewcoo 4y ago
  And actually, the best Perl golfers[1] I knew wrote the cleanest, most maintainable code. I wish "clever but bad" programming games were more common in every language. It takes care of the learner's need to push limits, but is a pleasantly humorous reminder why we don't do that in production. [1] https://perlgolf.sourceforge.net https://perlgolf.sourceforge.net
Kranar 4y ago
What does computer architecture have to do with this? What is your explanation for why this happens?
- 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.
naniwaduni 4y ago
> This is pretty basic C++/computer architecture stuff. Well, it would be if they'd written it correctly—that should be a multiplication, not an addition. As written, it would certainly be very mysterious, but mostly just because it isn't true.
- layer8 4y ago
  Thank you, I was starting to question my sanity.
grogers 4y ago
> This is pretty basic C++/computer architecture stuff. The C rules for integer type promotions are incredibly hard to reason about. They should have just banned implicit conversions from the beginning. This is not super basic stuff.

by tines 4y ago

otabdeveloper4 4y ago

Python in 2023 is like Perl in 1996. Given the choice I'd rather program in anything else.

eggy 4y ago
Exactly! I liked using it to program Blender3D scripts in 2004/5, but then lost any love for Python.
drewcoo 4y ago
And actually, the best Perl golfers[1] I knew wrote the cleanest, most maintainable code. I wish "clever but bad" programming games were more common in every language. It takes care of the learner's need to push limits, but is a pleasantly humorous reminder why we don't do that in production. [1] https://perlgolf.sourceforge.net https://perlgolf.sourceforge.net

Kranar 4y ago

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

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.

naniwaduni 4y ago

> This is pretty basic C++/computer architecture stuff. Well, it would be if they'd written it correctly—that should be a multiplication, not an addition. As written, it would certainly be very mysterious, but mostly just because it isn't true.

layer8 4y ago
Thank you, I was starting to question my sanity.

grogers 4y ago

> This is pretty basic C++/computer architecture stuff. The C rules for integer type promotions are incredibly hard to reason about. They should have just banned implicit conversions from the beginning. This is not super basic stuff.