3 ms·

Computers are implemented in hardware, not maths proofs. The Java generation is infatuated with magic numerics without realizing their performance cost.

nine_k 3y ago
Floating-point numbers are also directly supported by hardware, but they carved a few values for NaN, negative and positive infinity, and negative and positive zero. I don't see why integers should not have something similar, especially large enough integers, like i64 or even i32. Historically they don't though.
- GrumpySloth 3y ago
  Floating point numbers also don’t obey normal algebra laws and are notoriously tricky to get right. Two’s complement on the other hand form an honest-to-god commutative ring, their implementation is dead simple and it’s very rare that they lead to bugs in and out of themselves. They’re one of the most beautiful solutions in computer science IMO. I’d give up floating point much more readily than two's complement.
lxgr 3y ago
What’s the “Java generation”, and why is premature optimization strictly preferred over sacrificing performance over correctness? x86 offers hardware traps for integer division by zero while PowerPC returns zero – does that make x86 more wasteful/a “Java generation CPU”? What about CPUs that support native wrap trapping?
- AdamH12113 3y ago
  I think the GP's point is that this would need hardware support. Without that, it's not something you could implement efficiently as a programming language feature -- you'd have to "trap" by checking the result of every arithmetic operation in software.
  - lxgr 3y ago
    Python does just that for integers (since it automatically casts up to bigints instead of overflowing), as does Swift, and that's arguably fairly low-level/"compiled"! It doesn't strike me as an absurd idea. Compilers could optimize for common cases where overflows are guaranteed to not happen, or perform the "isn't b100..000" check at the entrance to an inner loop and defer to the hardware's native overflow detection capabilities (if any).
    - trealira 3y ago
      Lisp has converted fixnums (hardware integers) to bignums on overflow since the 1970s, too, so it's not just the "Java generation." Their words: > Computers are implemented in hardware, not maths proofs. The _ generation is infatuated with _ without realizing their performance cost. This sounds just like the assembly programmers arguing against high level languages, who were against the overhead of unlimited named variables and recursive function activation records. We should optimize for writing a lot of correct but slightly inefficient software. By keeping high-level language compilers (rather than assembly language programmers) in mind for the design of newer ISAs, we already have, to some extent. That said, I still don't know about making the lowest signed number a trap representation in hardware. We already usually have a flag to detect signed overflow; why not just check that?
      - lxgr 3y ago
        > That said, I still don't know about making the lowest signed number a trap representation in hardware. We already usually have a flag to detect signed overflow; why not just check that? TFA mentions efficient representation of optional/nilable integers in parameters or return values as another benefit, which I do have some sympathy for (supplying MIN_INT or MAX_INT as an effective "nil" value has always felt wrong to me). I'm not sure if a hardware trap is the right mechanism to handle that, though.
usrusr 3y ago
I'd say the only "generational" part is that in this example the question has made it to the web. Who wouldn't wonder, when first leaning about two's complement, if unsigned plus sign (one's complement) might be preferable? I'd rather question the mind of people who never went through that phase. And the people who, in the early days, opted for one's complement for the hardware they designed certainly did not do so because of being too far from the metal. Both representations coexisted for a while, sometimes within the same system.
- sham1 3y ago
  For slight pedantry, "unsigned plus sign" is the sign-and-magnitude representation, while one's complement negation is taking the bitwise NOT of the number in question.
saagarjha 3y ago
Why do you think the author of this is unaware of the performance cost?

nine_k 3y ago

Floating-point numbers are also directly supported by hardware, but they carved a few values for NaN, negative and positive infinity, and negative and positive zero. I don't see why integers should not have something similar, especially large enough integers, like i64 or even i32. Historically they don't though.

GrumpySloth 3y ago
Floating point numbers also don’t obey normal algebra laws and are notoriously tricky to get right. Two’s complement on the other hand form an honest-to-god commutative ring, their implementation is dead simple and it’s very rare that they lead to bugs in and out of themselves. They’re one of the most beautiful solutions in computer science IMO. I’d give up floating point much more readily than two's complement.

lxgr 3y ago

What’s the “Java generation”, and why is premature optimization strictly preferred over sacrificing performance over correctness? x86 offers hardware traps for integer division by zero while PowerPC returns zero – does that make x86 more wasteful/a “Java generation CPU”? What about CPUs that support native wrap trapping?

AdamH12113 3y ago
I think the GP's point is that this would need hardware support. Without that, it's not something you could implement efficiently as a programming language feature -- you'd have to "trap" by checking the result of every arithmetic operation in software.
- lxgr 3y ago
  Python does just that for integers (since it automatically casts up to bigints instead of overflowing), as does Swift, and that's arguably fairly low-level/"compiled"! It doesn't strike me as an absurd idea. Compilers could optimize for common cases where overflows are guaranteed to not happen, or perform the "isn't b100..000" check at the entrance to an inner loop and defer to the hardware's native overflow detection capabilities (if any).
  - trealira 3y ago
    Lisp has converted fixnums (hardware integers) to bignums on overflow since the 1970s, too, so it's not just the "Java generation." Their words: > Computers are implemented in hardware, not maths proofs. The _ generation is infatuated with _ without realizing their performance cost. This sounds just like the assembly programmers arguing against high level languages, who were against the overhead of unlimited named variables and recursive function activation records. We should optimize for writing a lot of correct but slightly inefficient software. By keeping high-level language compilers (rather than assembly language programmers) in mind for the design of newer ISAs, we already have, to some extent. That said, I still don't know about making the lowest signed number a trap representation in hardware. We already usually have a flag to detect signed overflow; why not just check that?
    - lxgr 3y ago
      > That said, I still don't know about making the lowest signed number a trap representation in hardware. We already usually have a flag to detect signed overflow; why not just check that? TFA mentions efficient representation of optional/nilable integers in parameters or return values as another benefit, which I do have some sympathy for (supplying MIN_INT or MAX_INT as an effective "nil" value has always felt wrong to me). I'm not sure if a hardware trap is the right mechanism to handle that, though.

usrusr 3y ago

I'd say the only "generational" part is that in this example the question has made it to the web. Who wouldn't wonder, when first leaning about two's complement, if unsigned plus sign (one's complement) might be preferable? I'd rather question the mind of people who never went through that phase. And the people who, in the early days, opted for one's complement for the hardware they designed certainly did not do so because of being too far from the metal. Both representations coexisted for a while, sometimes within the same system.

sham1 3y ago
For slight pedantry, "unsigned plus sign" is the sign-and-magnitude representation, while one's complement negation is taking the bitwise NOT of the number in question.

saagarjha 3y ago

Why do you think the author of this is unaware of the performance cost?