divide-by-zero

I have come across this problem in a calculation I do in my code, where the divisor is 0 if the divident is 0 too. In my code I return 0 for that case. I am wondering, while division by zero is generally undefined, why not make an exception for this case? My understanding why division by zero is undefined is basically that it cannot be reversed. However, I do not see this problem in the case 0/0. EDIT OK, so this question spawned a lot of discussion. I made the mistake of over-eagerly accepting an answer based on the fact that it received a lot of votes. I now accepted AakashM's answer ,

My toy compiler crashes if I divide by zero in a constant expression: int x = 1 / 0; Is this behaviour allowed by the C and/or C++ standards? The mere presence of 1 / 0 does not permit the compiler to crash. At most, it is permitted to assume that the expression will never be evaluated, and thus, that execution will never reach the given line. If the expression is guaranteed to be evaluated, the standard imposes no requirements on the program or compiler. Then the compiler can crash. 1 / 0 is only UB if evaluated. The C11 standard gives an explicit example of 1 / 0 being defined behavior when

I don't quite understand why I don't get a division by zero exception: int d = 0; d /= d; I expected to get a division by zero exception but instead d == 1 . Why doesn't d /= d throw a division by zero exception when d == 0 ? C++ does not have a "Division by Zero" Exception to catch. The behavior you're observing is the result of Compiler optimizations: The compiler assumes Undefined Behavior doesn't happen Division by Zero in C++ is undefined behavior Therefore, code which can cause a Division by Zero is presumed to not do so. And, code which must cause a Division by Zero is presumed to never

Everybody knows you're not supposed to compare floats directly, but rather using a tolerance: float a,b; float epsilon = 1e-6f; bool equal = (fabs(a-b) < epsilon); I was wondering if the same applies to comparing a value to zero before using it in division. float a, b; if (a != 0.0f) b = 1/a; // oops? Do I also need to compare with epsilon in this case? Floating point division by zero is not an error. It raises a floating point exception (which is a no-op unless you're actively checking them) on implementations that support floating point exceptions, and has well-defined result: either

This question already has an answer here: Inconsistency in divide-by-zero behavior between different value types 5 answers We get compile time error when integer is divided by zero whereas in case of double there is no compilation error but at run-time we get infinity/NaN as the result. Any idea why int & double have different behavior when it comes to divide by zero exception? void Main() { int number = 20; var result1 = number/0; // Divide by zero compile time exception double doubleNumber = 20; var result2 = doubleNumber/0.0; // no compile time error. Result is infinity or NaN } Because

I have the following code: scores = [matrix[i][i] / sum(matrix[i]) for (i, scores) in enumerate(matrix)] My problem is that sum(matrix[i]) could be 0 in some cases, resulting in a ZeroDivisionError . But because matrix[i][i] is also 0 in that case, I solved this as follows: scores = [divide(matrix[i][i], sum(matrix[i])) for (i, scores) in enumerate(matrix)] The function divide(x, y) returns 1 if y == 0 and (x / y) if y > 0 . But I wonder if there is an easier way. Maybe I could use some ternary operator, but does that exist in Python? TerryA Yes, in Python it's called the conditional

Perhaps this is the wrong sort of question to ask here but I am curious. I know that many languages will simply explode and fail when asked to divide by 0, but are there any programming languages that can intelligently handle this impossible sum - and if so, what do they do? Do they keep processing, treating 350/0 as 350, or stop execution, or what? From Wikipedia : The infinities of the extended real number line can be represented in IEEE floating point datatypes, just like ordinary floating point values like 1, 1.5 etc. They are not error values in any way, though they are often (but not