5 ms·

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

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.
  - 8organicbits 2y ago
    This is a much clearer argument to me. Theorem provers can be used to ensure certain constraints are met for all possible inputs. It doesn't matter to a theorem prover if 1/0=0, 1/0=infinity, or 1+1=3 so long as you can show the system stays within its constraints. It's not a question of math, it's about what you can prove the machine will do. I believe most of us doing systems programming and building control systems use IEEE 754, so it's surprising to see a conflicting suggestion. I'd say the biggest thing is that programmers need to be aware of how 1/0 is handled, as 0, infinity, or an exception can all cause undesired results.
  - nemetroid 2y ago
    Thanks for an interesting read. I don't think it's a convincing argument for general purpose languages, though. In Lean, the zero check is still there, just not in the arithmetic operator itself but in the various division related theorems you need to use in order to do anything useful with the division. But in C/Java/Python/whatever, there are no such guardrails, so 0 or 37 or whatever bogus value is returned from a division by zero will propagate to the rest of the program and cause subtler and harder-to-find bugs.
  - anlsh 2y ago
    Ok now we're talking: important clarifications. Neat read on the type systems. But this part is extremely important: > The idiomatic way to do it is to allow garbage inputs like negative numbers into your square root function, and return garbage outputs. It is in the theorems where one puts the non-negativity hypotheses. The equivalent condition here would be for everyone to include "zero-ness" checks on their numeric inputs. But that's awful, because whereas everyone agrees that nullptr is a meaningless pointer, zero is in fact a perfectly good integer/float whatever. So now you have something worse than null pointers- which have course caused us a huge amount of pain ever since being inflicted on the world So x / 0 = 0 is still a terrible, terrible, idea. But introduce something like the floating-point equivalent of NaN, and say x / 0 = NaN, and now your outputs will at least be obviously wrong, instead of just silently wrong
nvy 2y ago
>Zero is a fine answer for integer division by zero. It's not. Division (edit: of a positive integer) by zero is better approximated by +infinity rather than zero. In real life to divide something into zero groups is nonsensical, thus the number system in programs should reflect this. In the exceptionally-rare case where you want to divide by zero and it makes sense (can't think of a scenario where that's true but let's stipulate), then you can use your language's equivalent of try/catch or (if (zerop x) ...) to get around it. Don't fuck up normal mathematics for the rest of us just because some lazy programmer doesn't like to add error checking.
- foobar1962 2y ago
  > Division by zero is better approximated by +infinity rather than zero. No it's not. Division by zero is UNDEFINED. How does a calculation return +infinity anyway? On the positive side of the graph, 1/x approaches +infinity. However from the negative side of the graph 1/x approaches -infinity. So at zero, 1/x is simultaneously +infinity and -infinity, which is not possible. The answer to 1/0 is "there is no answer" which is UNDEFINED. A reasonable result for a calculation is to return "?" or possibly NULL or nothing, depending on what other parts of the system are expecting.
  - vlovich123 2y ago
    > No it's not. Division by zero is UNDEFINED Yeah OP is suggesting that the answer to lim x-> 0 1/x = infinity and thus that’s an intuitive answer. Unfortunately that’s obviously not correct precisely because it depends which side from 0 you approach and why just 1/0 is undefined (you could argue about 0+ and 0- but I view that more as IEEE754 weirdness that is used in niches rather than something that would meaningfully change the situation) > How does a calculation return +infinity anyway? Not sure what your actually asking but floating point representations generally support a concept of +/- inf. > A reasonable result for a calculation is to return "?" or possibly NULL or nothing, depending on what other parts of the system are expecting. That’s what floating point NaN is
  - nvy 2y ago
    >Division by zero is UNDEFINED. How does a calculation return +infinity anyway? I used the word "approximated" for a reason. I'll cop to the fact that I was only considering positive integers but your response is needlessly pedantic given the context of what I wrote.

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.
- 8organicbits 2y ago
  This is a much clearer argument to me. Theorem provers can be used to ensure certain constraints are met for all possible inputs. It doesn't matter to a theorem prover if 1/0=0, 1/0=infinity, or 1+1=3 so long as you can show the system stays within its constraints. It's not a question of math, it's about what you can prove the machine will do. I believe most of us doing systems programming and building control systems use IEEE 754, so it's surprising to see a conflicting suggestion. I'd say the biggest thing is that programmers need to be aware of how 1/0 is handled, as 0, infinity, or an exception can all cause undesired results.
- nemetroid 2y ago
  Thanks for an interesting read. I don't think it's a convincing argument for general purpose languages, though. In Lean, the zero check is still there, just not in the arithmetic operator itself but in the various division related theorems you need to use in order to do anything useful with the division. But in C/Java/Python/whatever, there are no such guardrails, so 0 or 37 or whatever bogus value is returned from a division by zero will propagate to the rest of the program and cause subtler and harder-to-find bugs.
- anlsh 2y ago
  Ok now we're talking: important clarifications. Neat read on the type systems. But this part is extremely important: > The idiomatic way to do it is to allow garbage inputs like negative numbers into your square root function, and return garbage outputs. It is in the theorems where one puts the non-negativity hypotheses. The equivalent condition here would be for everyone to include "zero-ness" checks on their numeric inputs. But that's awful, because whereas everyone agrees that nullptr is a meaningless pointer, zero is in fact a perfectly good integer/float whatever. So now you have something worse than null pointers- which have course caused us a huge amount of pain ever since being inflicted on the world So x / 0 = 0 is still a terrible, terrible, idea. But introduce something like the floating-point equivalent of NaN, and say x / 0 = NaN, and now your outputs will at least be obviously wrong, instead of just silently wrong

nvy 2y ago

>Zero is a fine answer for integer division by zero. It's not. Division (edit: of a positive integer) by zero is better approximated by +infinity rather than zero. In real life to divide something into zero groups is nonsensical, thus the number system in programs should reflect this. In the exceptionally-rare case where you want to divide by zero and it makes sense (can't think of a scenario where that's true but let's stipulate), then you can use your language's equivalent of try/catch or (if (zerop x) ...) to get around it. Don't fuck up normal mathematics for the rest of us just because some lazy programmer doesn't like to add error checking.

foobar1962 2y ago
> Division by zero is better approximated by +infinity rather than zero. No it's not. Division by zero is UNDEFINED. How does a calculation return +infinity anyway? On the positive side of the graph, 1/x approaches +infinity. However from the negative side of the graph 1/x approaches -infinity. So at zero, 1/x is simultaneously +infinity and -infinity, which is not possible. The answer to 1/0 is "there is no answer" which is UNDEFINED. A reasonable result for a calculation is to return "?" or possibly NULL or nothing, depending on what other parts of the system are expecting.
- vlovich123 2y ago
  > No it's not. Division by zero is UNDEFINED Yeah OP is suggesting that the answer to lim x-> 0 1/x = infinity and thus that’s an intuitive answer. Unfortunately that’s obviously not correct precisely because it depends which side from 0 you approach and why just 1/0 is undefined (you could argue about 0+ and 0- but I view that more as IEEE754 weirdness that is used in niches rather than something that would meaningfully change the situation) > How does a calculation return +infinity anyway? Not sure what your actually asking but floating point representations generally support a concept of +/- inf. > A reasonable result for a calculation is to return "?" or possibly NULL or nothing, depending on what other parts of the system are expecting. That’s what floating point NaN is
- nvy 2y ago
  >Division by zero is UNDEFINED. How does a calculation return +infinity anyway? I used the word "approximated" for a reason. I'll cop to the fact that I was only considering positive integers but your response is needlessly pedantic given the context of what I wrote.