6 ms·

Number divided by zero shall be zero. The possibly-floating-point exception of immediate program death is an interesting idea that has aged poorly. Loads of thi

Number divided by zero shall be zero. The possibly-floating-point exception of immediate program death is an interesting idea that has aged poorly. Loads of things go wrong in software. Div / 0 badly upsetting mechanical calculators isn't a reason for software to abort at the sight of it. Counterarguments in comments perhaps. Someone have a driving passion for this particular edge case of missed input validation being wildly more important than all the others?

nemetroid 2y ago
Should we do the same for segmentation faults? Silently return zero and let the program continue with whatever broken internal state it ends up with?
- JonChesterfield 2y ago
  Sometimes, yes. One choice is the right and proper self flagellation and sorrow for poor behaviour. The other is to not disable the engines on your warship when a programmer missed an edge case.
  - 8organicbits 2y ago
    I wonder what calculation was being made. Something related to fuel valves? Carelessly proceeding with bad data could destroy machinery, start a fire, and sink the ship. There's no easy, one size fits all answer here.
  - DonHopkins 2y ago
    I hope they disable the guns on your warship when a programmer missed an edge case.
  - nemetroid 2y ago
    Disabling the engines sounds like a pretty good deal compared to what bad software could make a warship do.
anlsh 2y ago
Your idea that your program should just spit out an incorrect answer when it runs into an unexpected condition? That's really stupid
- shrimp_emoji 2y ago
  That's what humans do! Or, more generally, what neural networks do. :p And I agree: ideally, software would be more rational than that.
- JonChesterfield 2y ago
  Zero is a fine answer for integer division by zero. "Oh noes you can't do that math, my teacher told me so in a school" isn't a brilliant heuristic to work from. How about modulo zero? That can be completely correctly define or a floating point exception if you decided to define it in terms of divide and also decided divide should do that. What about floating point? It gave up on reflexive equality and yet programs do things with doubles despite that. The integer divide zero industry best practice of promptly falling over isn't an axiom of reality. It's another design mistake from decades ago.
  - anlsh 2y ago
    [flagged]
    - JonChesterfield 2y ago
      Neither. I guess we'll try argument from authority. A sibling post called out pony. Lean, coq, isabelle define integer division by zero to be zero. E.g. https://xenaproject.wordpress.com/2020/07/05/division-by-zero-in-type-theory-a-faq/ https://xenaproject.wordpress.com/2020/07/05/division-by-zer... So by case analysis either: - I am a moron, and so are the developers of lean, coq and isabelle - Most of the responders to this thread are failing to think for themselves - Responders all think "number" must mean "real number" Reading through the various responses, it's looking somewhat likely that "number" means "real number" for most people here. And divide zero on the reals is not well formed. Which is weird given it's a programming themed board and your language is far more likely to give you integers mod word size and floating point than real numbers. By "number" I mean "the number your computer can represent", which appears to have been accidental trolling on my part. The reference to a mechanical calculator struggling was perhaps insufficient.
hyperhello 2y ago
Decriminalize all operations!
bee_rider 2y ago
I don’t remember if it is on by default or not, but there’s some mxcsr flag to make division by zero return an INF, I’m pretty sure. Division by zero returning a zero is a pretty bad and confusing result mathematically.
- JonChesterfield 2y ago
  7 / 2 = 3 is similarly nonsense. It's just more familiar. How about 5 - 8 = 0? Sensible result for the natural numbers. X + 7? Surely you meant addition modulo 2^64. What's the count leading zeros on zero? Is it zero, 64, random noise found in a register? What's X shifted by word size? Zero? Minus one? X? These are all choices. Some are familiar. But knowing integer divide zero is wrong is a tenant of faith.
  - linearrust 2y ago
    > 7 / 2 = 3 is similarly nonsense. It's just more familiar. It isn't nonsense. 7/2 represents a real number. You can round a real number up or down. So you can round 3.5 to 3. 7/0 doesn't represent a real number. It doesn't even make sense to do anything to an undefined number.
    - JonChesterfield 2y ago
      How about a rational number? Why not a complex number? That you especially like the real numbers is particularly unfortunate when they are so poorly represented in essentially all programming languages.
      - linearrust 2y ago
        > How about a rational number? All rational numbers are real numbers. > Why not a complex number? What? > That you especially like the real numbers is particularly unfortunate It's not a matter of me liking or disliking real numbers. It's just that the topic at hand is about real numbers. > when they are so poorly represented in essentially all programming languages. Not essentially all programming languages. In every single one. It's the nature of real numbers. It's also not just 'programming languages', it's hardware as well.
8organicbits 2y ago
This is discussed in the article. The standard is to use infinity, not zero. > A hardware example of exception handling is the IEEE 754 standard for floating point arithmetic which defines values for various exceptions (e.g. infinity for divide-by-zero)
- foobar1962 2y ago
  > This is discussed in the article. The standard is to use infinity, not zero. It's wrong. How is infinity returned as a result anyway? It's not a number, and it's not <the largest number the computer can return> either.
  - ikekkdcjkfke 2y ago
    No idea but in javascript Infinity is a type of constant i guess, any subsequent operations on Infinity just returns infinity instead of crashing
  - recursive 2y ago
    Infinities have representation in many computer number systems, such as IEE-754 floating point, which is the number system used by Javascript.
    - 8organicbits 2y ago
      Lots of programming languages use this standard. It's helpful to know. https://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html https://www.gnu.org/software/libc/manual/html_node/Infinity-...
tcmart14 2y ago
I don't know if I per-se agree with defaulting to zero in all instances, but I agree with a somewhat general sentiment. Division by zero, it would be nice if it returned something we can count on. In my mind, I see it some pre-determined safe default value. Which in many cases, may be zero. I think what I would like is perhaps a way to have something almost like an interrupt. And being able to set what the interrupt does or swap between different interrupts. At runtime we can see the denominator is zero, so trigger the interrupt. For a set of functions, I can set an interrupt where a divide by zero does return zero, these would be functions whose callers can safely handle the zero or perform some default state at zero. But other functions, maybe there is a different default value that callers can use and it not screw everything up. Some may gripe about, but its a mathematically in correct answer. Sure, it is. But for systems, especially saftey critical systems, I'd rather know that in the event I didn't properly guard against a 0 in the denominator, a behavior that I can account for is guaranteed to happen (some safe default).
- dylan604 2y ago
  > I don't know if I per-se agree with defaulting to zero in all instances, but I agree with a somewhat general sentiment I agree with this. Forcing every instance to be 0 might hide the issue as 0 could be a valid if unexpected result in situations which might make debugging more difficult. The same reason === is a thing. NaN seems plausible yet equally awkward. Null could work too

nemetroid 2y ago

Should we do the same for segmentation faults? Silently return zero and let the program continue with whatever broken internal state it ends up with?

JonChesterfield 2y ago
Sometimes, yes. One choice is the right and proper self flagellation and sorrow for poor behaviour. The other is to not disable the engines on your warship when a programmer missed an edge case.
- 8organicbits 2y ago
  I wonder what calculation was being made. Something related to fuel valves? Carelessly proceeding with bad data could destroy machinery, start a fire, and sink the ship. There's no easy, one size fits all answer here.
- DonHopkins 2y ago
  I hope they disable the guns on your warship when a programmer missed an edge case.
- nemetroid 2y ago
  Disabling the engines sounds like a pretty good deal compared to what bad software could make a warship do.

anlsh 2y ago

Your idea that your program should just spit out an incorrect answer when it runs into an unexpected condition? That's really stupid

shrimp_emoji 2y ago
That's what humans do! Or, more generally, what neural networks do. :p And I agree: ideally, software would be more rational than that.
JonChesterfield 2y ago
Zero is a fine answer for integer division by zero. "Oh noes you can't do that math, my teacher told me so in a school" isn't a brilliant heuristic to work from. How about modulo zero? That can be completely correctly define or a floating point exception if you decided to define it in terms of divide and also decided divide should do that. What about floating point? It gave up on reflexive equality and yet programs do things with doubles despite that. The integer divide zero industry best practice of promptly falling over isn't an axiom of reality. It's another design mistake from decades ago.
- anlsh 2y ago
  [flagged]
  - JonChesterfield 2y ago
    Neither. I guess we'll try argument from authority. A sibling post called out pony. Lean, coq, isabelle define integer division by zero to be zero. E.g. https://xenaproject.wordpress.com/2020/07/05/division-by-zero-in-type-theory-a-faq/ https://xenaproject.wordpress.com/2020/07/05/division-by-zer... So by case analysis either: - I am a moron, and so are the developers of lean, coq and isabelle - Most of the responders to this thread are failing to think for themselves - Responders all think "number" must mean "real number" Reading through the various responses, it's looking somewhat likely that "number" means "real number" for most people here. And divide zero on the reals is not well formed. Which is weird given it's a programming themed board and your language is far more likely to give you integers mod word size and floating point than real numbers. By "number" I mean "the number your computer can represent", which appears to have been accidental trolling on my part. The reference to a mechanical calculator struggling was perhaps insufficient.

hyperhello 2y ago

Decriminalize all operations!

bee_rider 2y ago

I don’t remember if it is on by default or not, but there’s some mxcsr flag to make division by zero return an INF, I’m pretty sure. Division by zero returning a zero is a pretty bad and confusing result mathematically.

JonChesterfield 2y ago
7 / 2 = 3 is similarly nonsense. It's just more familiar. How about 5 - 8 = 0? Sensible result for the natural numbers. X + 7? Surely you meant addition modulo 2^64. What's the count leading zeros on zero? Is it zero, 64, random noise found in a register? What's X shifted by word size? Zero? Minus one? X? These are all choices. Some are familiar. But knowing integer divide zero is wrong is a tenant of faith.
- linearrust 2y ago
  > 7 / 2 = 3 is similarly nonsense. It's just more familiar. It isn't nonsense. 7/2 represents a real number. You can round a real number up or down. So you can round 3.5 to 3. 7/0 doesn't represent a real number. It doesn't even make sense to do anything to an undefined number.
  - JonChesterfield 2y ago
    How about a rational number? Why not a complex number? That you especially like the real numbers is particularly unfortunate when they are so poorly represented in essentially all programming languages.
    - linearrust 2y ago
      > How about a rational number? All rational numbers are real numbers. > Why not a complex number? What? > That you especially like the real numbers is particularly unfortunate It's not a matter of me liking or disliking real numbers. It's just that the topic at hand is about real numbers. > when they are so poorly represented in essentially all programming languages. Not essentially all programming languages. In every single one. It's the nature of real numbers. It's also not just 'programming languages', it's hardware as well.

8organicbits 2y ago

This is discussed in the article. The standard is to use infinity, not zero. > A hardware example of exception handling is the IEEE 754 standard for floating point arithmetic which defines values for various exceptions (e.g. infinity for divide-by-zero)

foobar1962 2y ago
> This is discussed in the article. The standard is to use infinity, not zero. It's wrong. How is infinity returned as a result anyway? It's not a number, and it's not <the largest number the computer can return> either.
- ikekkdcjkfke 2y ago
  No idea but in javascript Infinity is a type of constant i guess, any subsequent operations on Infinity just returns infinity instead of crashing
- recursive 2y ago
  Infinities have representation in many computer number systems, such as IEE-754 floating point, which is the number system used by Javascript.
  - 8organicbits 2y ago
    Lots of programming languages use this standard. It's helpful to know. https://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html https://www.gnu.org/software/libc/manual/html_node/Infinity-...

tcmart14 2y ago

I don't know if I per-se agree with defaulting to zero in all instances, but I agree with a somewhat general sentiment. Division by zero, it would be nice if it returned something we can count on. In my mind, I see it some pre-determined safe default value. Which in many cases, may be zero. I think what I would like is perhaps a way to have something almost like an interrupt. And being able to set what the interrupt does or swap between different interrupts. At runtime we can see the denominator is zero, so trigger the interrupt. For a set of functions, I can set an interrupt where a divide by zero does return zero, these would be functions whose callers can safely handle the zero or perform some default state at zero. But other functions, maybe there is a different default value that callers can use and it not screw everything up. Some may gripe about, but its a mathematically in correct answer. Sure, it is. But for systems, especially saftey critical systems, I'd rather know that in the event I didn't properly guard against a 0 in the denominator, a behavior that I can account for is guaranteed to happen (some safe default).

dylan604 2y ago
> I don't know if I per-se agree with defaulting to zero in all instances, but I agree with a somewhat general sentiment I agree with this. Forcing every instance to be 0 might hide the issue as 0 could be a valid if unexpected result in situations which might make debugging more difficult. The same reason === is a thing. NaN seems plausible yet equally awkward. Null could work too