2 ms·

> If your needs are more sophisticated then you'd need to actually analyze the problem and come up with ways to handle unexpected data gracefully The case I've

by acqq 10y ago

> If your needs are more sophisticated then you'd need to actually analyze the problem and come up with ways to handle unexpected data gracefully The case I've linked to provided exactly that kind of example: "The correct solution there was to saturate, not wrap, which is almost always the case in DSP code." I have an impression you've written your whole answer without reading it. And if you don't know what that means: https://en.wikipedia.org/wiki/Saturation_arithmetic https://en.wikipedia.org/wiki/Saturation_arithmetic Note that something like that is necessary only for the very performance critical code using integers, as today's FPU are also very fast and allow the representation of much bigger range of values: more than the number of the atoms in the observable universe can be fit in the FP number. Also note "Saturation arithmetic operations are available on many modern platforms, and in particular was one of the extensions made by the Intel MMX platform, specifically for such signal processing applications. This functionality is also available in wider versions in the SSE2 and AVX2 integer instruction sets." Not to mention the DSP processors. https://www.arm.com/products/processors/technologies/dsp-simd.php https://www.arm.com/products/processors/technologies/dsp-sim... "Zero overhead saturation extension support" Moreover, "the IEEE floating-point standard, the most popular abstraction for dealing with approximate real numbers, uses a form of saturation." All of this is a common knowledge by the professionals, and it's completely different from "just make an exception" approach that is so popular here. I claim that there's much bigger possibility that the author of the article knows about that than the commenters here that are responding (and voting) with the "just fail fast" mantra (or even claim that those who don't agree with their (probably poorly founded, as far as I see that) understanding are "inflammatory."

mikeash 10y ago
I read it and understood it. I think we're talking past each other. You're saying, crashing is bad, it's better to figure out a correct response to overflow. I'm saying, choosing some default overflow behavior without any analysis is bad, it's better to crash. In some cases, you want to wrap. In others, you want to saturate. In others, you'll want to signal a failure. In still others, you'll want to fall back to bignums. There's no universal correct answer. But the discussion here is about what the language should do about overflow. The language has to pick some default behavior for the + operator, and it can only pick one. Some people are arguing that wrapping by default is the best choice, because it at least gives the program a chance of continuing to operate. I am arguing that the best default behavior is to crash, because continuing on when the programmer hasn't explicitly chosen the appropriate behavior is potentially disastrous. Of course the person who posted that comment didn't want their stuff to crash. But if the default behavior had been to crash (ignoring the likely impossibility of that in the context of an FPGA), their bug would have been a simple fix instead of something so nasty they still remember it. Sure, if the default had been to saturate then they would have avoided the bug, but only by coincidence, and this would just cause bugs elsewhere when people needed wrapping instead. The fourth word of your quote is key: "The correct solution there...." That was the correct solution in that spot, but it would not be the correct choice for default behavior for the + operator in a language.
- acqq 10y ago
  If you are discussing the semantic of the "integer + operator" then I have also completely another opinion: "it would not be the correct choice for default behavior for the + operator in a language." No. Except if you're doing crypto, the wrap alone is never the desired mode. The wrap with the accessibility to the carry flag can be (just in implementing arithmetic with more bits). What the HL languages should actually do is not even allow the "easy" expressions in the integer domain, exactly because of all that. Moreover, missing accessibility of the carry flag in the HLL is also a problem. The instruction sets of ASM instructions are much more reasonable than the poor implementations of all the HL languages I know. "Exception on carry" instead of enforcing the code to be precise is the way to the many more accidents waiting to happen. The current practice of the HL languages is more of the lazy repetition of some old decision than the proper safety-preserving approach.
  - mikeash 10y ago
    If you're arguing that there shouldn't be any default behavior, and the programmer should always be forced to choose, I could get behind that. I've also argued for degradation to bignums as the best default. This way the result is always correct. Of course, that means a performance hit on all arithmetic code unless you opt out of that, and you could make the case that this is also an unacceptable default. In any case, consider the "crashing is the best default choice" to be qualified with "if you're going to have some default choice for fixed-size integers."
    - acqq 10y ago
      > I've also argued for degradation to bignums as the best default. It has sense for Python and Perl code but not for the code produced by something that would be better C than the current C. If the performance is critical (as to have to effectively no slowdown compared to what the CPU can achieve), the CPU machine code instructions already do "the right thing" and it's the HL languages that abstract the carry or the saturation away to make the wrong plain "+". C with the CPU-specific extensions can "do the right thing." It's the "standard" "language lawyers" that are once again wrong.

by acqq 10y ago

mikeash 10y ago

I read it and understood it. I think we're talking past each other. You're saying, crashing is bad, it's better to figure out a correct response to overflow. I'm saying, choosing some default overflow behavior without any analysis is bad, it's better to crash. In some cases, you want to wrap. In others, you want to saturate. In others, you'll want to signal a failure. In still others, you'll want to fall back to bignums. There's no universal correct answer. But the discussion here is about what the language should do about overflow. The language has to pick some default behavior for the + operator, and it can only pick one. Some people are arguing that wrapping by default is the best choice, because it at least gives the program a chance of continuing to operate. I am arguing that the best default behavior is to crash, because continuing on when the programmer hasn't explicitly chosen the appropriate behavior is potentially disastrous. Of course the person who posted that comment didn't want their stuff to crash. But if the default behavior had been to crash (ignoring the likely impossibility of that in the context of an FPGA), their bug would have been a simple fix instead of something so nasty they still remember it. Sure, if the default had been to saturate then they would have avoided the bug, but only by coincidence, and this would just cause bugs elsewhere when people needed wrapping instead. The fourth word of your quote is key: "The correct solution there...." That was the correct solution in that spot, but it would not be the correct choice for default behavior for the + operator in a language.

acqq 10y ago
If you are discussing the semantic of the "integer + operator" then I have also completely another opinion: "it would not be the correct choice for default behavior for the + operator in a language." No. Except if you're doing crypto, the wrap alone is never the desired mode. The wrap with the accessibility to the carry flag can be (just in implementing arithmetic with more bits). What the HL languages should actually do is not even allow the "easy" expressions in the integer domain, exactly because of all that. Moreover, missing accessibility of the carry flag in the HLL is also a problem. The instruction sets of ASM instructions are much more reasonable than the poor implementations of all the HL languages I know. "Exception on carry" instead of enforcing the code to be precise is the way to the many more accidents waiting to happen. The current practice of the HL languages is more of the lazy repetition of some old decision than the proper safety-preserving approach.
- mikeash 10y ago
  If you're arguing that there shouldn't be any default behavior, and the programmer should always be forced to choose, I could get behind that. I've also argued for degradation to bignums as the best default. This way the result is always correct. Of course, that means a performance hit on all arithmetic code unless you opt out of that, and you could make the case that this is also an unacceptable default. In any case, consider the "crashing is the best default choice" to be qualified with "if you're going to have some default choice for fixed-size integers."
  - acqq 10y ago
    > I've also argued for degradation to bignums as the best default. It has sense for Python and Perl code but not for the code produced by something that would be better C than the current C. If the performance is critical (as to have to effectively no slowdown compared to what the CPU can achieve), the CPU machine code instructions already do "the right thing" and it's the HL languages that abstract the carry or the saturation away to make the wrong plain "+". C with the CPU-specific extensions can "do the right thing." It's the "standard" "language lawyers" that are once again wrong.