Why does a division by zero produce an error or undefined message?

[AtoMick-u235]

A division by zero is a mathematical oddity, , if a computer or calculator etc performs a 1\0 they would crash, the OS prevents the execution, and displays ERROR or UNDEFINED, , , some versions of windows calculator display positive or negative infinity, , try it

Any ideas on this ?

 

[fresh_42]

Division by zero is simply not defined. There is no need to divide by zero because it isn't part of the multiplicative group. Addition and multiplication are only connected by the distributive law. That's all you are allowed to use. Since zero belongs to addition, multiplication is simply not a question. You wouldn't ask for the inverse sine function value of two, wouldn't you? Why would you want to divide by zero? It is the same nonsense.

 

[Mark44]

A division by zero is a mathematical oddity, , if a computer or calculator etc performs a 1\0 they would crash, the OS prevents the execution, and displays ERROR or UNDEFINED, , , some versions of windows calculator display positive or negative infinity, , try it

In my experience, computers don't crash if a program attempts to divide by zero. Instead, the program will throw an exception; namely a divide by zero exception.

In Windows 10, both the Scientific mode and Standard mode simple display a message: "Cannot divide by zero". Which versions of the Windows calculator are you talking about?

BTW, I have moved your thread to the General Math section as it has nothing to do with relativity.

 

[Infrared]

If $1/x$ is the number you have to multiply $x$ by to get $1$, what would that mean for $1/0$? No real number times zero is $1.$

 

[Dale]

Any ideas on this ?

It is pretty straightforward. $$x=a/b$$ means solve the following equation for $x$:$$bx=a$$If $b=0$ then that equation has no solution. So division by zero is undefined

 

[AtoMick-u235]

It is pretty straightforward. $$x=a/b$$ means solve the following equation for $x$:$$bx=a$$If $b=0$ then that equation has no solution. So division by zero is undefined

Hi, i understand the math:-

x = a/b so .5 = 1/2

bx = a so 2 x .5 = 1

But Infinity is not a Natural number, Integer, Rational, or even a Real Number so it cannot be represented with pen and paper, but i think in the real world with a computer the answer is 00000001 / 00000000 = infinity

 

[fresh_42]

Hi, i understand the math:-

x = a/b so .5 = 1/2

bx = a so 2 x .5 = 1

But Infinity is not a Natural number, Integer, Rational, or even a Real Number so it cannot be represented with pen and paper, but i think in the real world with a computer the answer is 00000001 / 00000000 = infinity

In the real world, the computer throws an exception. (see above)
In the mathematical world, we demand $1\neq 0$ which puts zero out of the range of multiplication. (see above)

The question has been answered on all meaningful levels so the thread is closed.

 

[DrClaude]

Apologies to my co-mentors @Mark44 and @fresh_42, but I will reopen the thread as some of the answers are incorrect/incomplete.

A floating point following the IEEE Standard for Floating-Point Arithmetic (IEEE 754) can represent a real number, but can also represent positive or negative infinity, and NaN (not a number). Following that standard, since $\lim_{ x \rightarrow 0} a/x = \pm \infty$, division by zero should return $\pm \infty$ (the sign will depend on the sign of $a$ and the sign of $0$, which is a signed number in IEEE 754). See https://en.wikipedia.org/wiki/Division_by_zero#Computer_arithmetic

 

[fresh_42]

Apologies to my co-mentors @Mark44 and @fresh_42, but I will reopen the thread as some of the answers are incorrect/incomplete.

A floating point following the IEEE Standard for Floating-Point Arithmetic (IEEE 754) can represent a real number, but can also represent positive or negative infinity, and NaN (not a number). Following that standard, since $\lim_{ x \rightarrow 0} a/x = \pm \infty$, division by zero should return $\pm \infty$ (the sign will depend on the sign of $a$ and the sign of $0$, which is a signed number in IEEE 754). See https://en.wikipedia.org/wiki/Division_by_zero#Computer_arithmetic

IIRC, then the C++ compiler from MS throws an exception which has to be handled by the programmer or is thrown all the way up to the top, resulting in an automatic error message.

Your "can represent $\pm \infty$ or $NaN$" is exactly the exception handling, since the program cannot distinguish whether you tried to compute $\lim_{n \to \pm\infty}\frac{1}{n}$ or $1/0.$

Hence we have an exception anyway. Makes sense as many IDE are written in C++.

 

[DrClaude]

IIRC, then the C++ compiler from MS throws an exception which has to be handled by the programmer or is thrown all the way up to the top, resulting in an automatic error message.

Your "can represent $\pm \infty$ or $NaN$" is exactly the exception handling, since the program cannot distinguish whether you tried to compute $\lim_{n \to \pm\infty}\frac{1}{n}$ or $1/0.$

Hence we have an exception anyway. Makes sense as many IDE are written in C++.

There is no exception thrown when the IEEE 754 standard is followed.

Consider this code:

#include <iostream>

using namespace std;

int
main ()
{
  double a = 1.;
  double b = -1.;
  double zero_plus = 0.;
  double zero_minus = -0.;

  cout << a/zero_plus << " " << a/zero_minus << " " << b/zero_plus
       << " " << b/zero_minus << "\n";

  return 0;
}

Compiled with the gcc compiler, here is what one gets:

$ g++ div_zero.cpp
$ ./a.out
inf -inf -inf inf

As I said above, the sign of $\infty$ is determined fro the sign of the numerator and the sign of the zero, which in IEEE 754 is signed.

 

[fresh_42]

As I said above, the sign of ∞ is determined fro the sign of the numerator and the sign of the zero, which in IEEE 754 is signed.

Well, C++ has been a while since I last directly used it. And the IDE I use nowadays fortunately throws an exception since anything else is mathematical nonsense; and this thread has landed in GM.

 

[martinbn]

Is this thread about why the calculator does something when asked to divide by zero or is it about why division by zero is not defined?

 

[Mark44]

There is no exception thrown when the IEEE 754 standard is followed.

That's correct and is something I had forgotten about.

Is this thread about why the calculator does something when asked to divide by zero or is it about why division by zero is not defined?

Seems to be more about the former, although a result of either inf or -inf wouldn't be considered to be defined.

 

[Kat-hi]

I'm also confused about what the original questioner wanted to discuss - is it a question as to why do different OS's handle this differently or instead why it's not defined? Dividing by a number effectively asks how many iterations there are of a value in a quantity. The 'problem' seems more to have an issue with our definition of division because it does not include zero. And with an OS.. the usual computation rules attempt to strictly enforce that definition. Circular logic could enforce the execution of the rule to go on infinitely because it will never proceed with an answer (so some may return that it's infinite)... or an additional rule would be in place to not count 0 (so it's "undefined" when it's really "not included").

 

[AtoMick-u235]

Is this thread about why the calculator does something when asked to divide by zero or is it about why division by zero is not defined?

At the time i thought of both, but it's just a general question about "Division By Zero" errors

 

[fresh_42]

At the time i thought of both, but it's just a general question about "Division By Zero" errors

As soon as you say "error" as soon it is a programming issue since mathematics doesn't have a division by zero.

 

[Filip Larsen]

Well, C++ has been a while since I last directly used it. And the IDE I use nowadays fortunately throws an exception since anything else is mathematical nonsense; and this thread has landed in GM.

That is also possible in C++: https://en.cppreference.com/w/cpp/numeric/fenv/fetestexcept
(Well, a floating-point exception state anyway, the actual throw is still something the programmer has to do).

And by the way, being forced to handle exceptions and/or add zero-test guards in the middle of (some) complex numerical calculations is not easy, whereas detecting NaN or floating-point exceptions after the calculation is fairly easy.

 

[jack action]

It kind of makes sense to separate inf from undefined.

Playing around with the C++ program of @DrClaude , the only time it returns nan is when you have a form $\frac{0}{0}$ in your equation^[1].

For example, it returns the correct answer $0$ to the equation cout << 1/(2/0.); even if you do it into 2 separate equations like so: a = 2/0.; cout << 1/a;.

----------------------------------------------------
^[1] $0 \times \infty$ and $\frac{\infty}{\infty}$ are just special cases of $\frac{0}{0}$, namely $0 \times \frac{a}{0}$ and $\frac{^a/_0}{^b/_0}$.

 

[Mark44]

It kind of makes sense to separate inf from undefined.

Well, yes. The token inf implies a result that is unbounded or large in absolute value. Values that are undefined can come from domain errors; for example, from expressions such as sqrt(-1.0) or acos(2.0). In Visual Studio, attempting to evaluate these expressions produces -nan(ind) and nan(ind), respectively -- indefinite NaNs (NaN means not a number).

Playing around with the C++ program of @DrClaude , the only time it returns nan is when you have a form $\frac{0}{0}$ in your equation^[1].

For example, it returns the correct answer $0$ to the equation cout << 1/(2/0.); even if you do it into 2 separate equations like so: a = 2/0.; cout << 1/a;.

First off, none of these is an equation. They are all statements. As you probably know, the symbol '=' in C and other languages derived from C is the assignment operator.
Second, a program that produced 0 as the "correct answer" for these calculations would be highly suspect.

----------------------------------------------------
^[1] $0 \times \infty$ and $\frac{\infty}{\infty}$ are just special cases of $\frac{0}{0}$, namely $0 \times \frac{a}{0}$ and $\frac{^a/_0}{^b/_0}$.

 

[AtoMick-u235]

In my experience, computers don't crash if a program attempts to divide by zero. Instead, the program will throw an exception; namely a divide by zero exception.

In Windows 10, both the Scientific mode and Standard mode simple display a message: "Cannot divide by zero". Which versions of the Windows calculator are you talking about?

BTW, I have moved your thread to the General Math section as it has nothing to do with relativity.

I am a computer technician, i have been a Motorola 68000 Assembly programmer, and have been building IBM compatibles since 1996, , , i am sure it was Windows 95\98 , , I just tried WinXP "Cannot Divide By Zero"

 

[fresh_42]

I would be far more interested in the question of how it is realized. How does the program know that it should throw an exception?

 

[AtoMick-u235]

With Win98 calculator and errors in general, Its obvious, and simple programing, if the divisor equals zero, do not execute the command, and print "Positive Infinity" , , otherwise i still believe a computer would, crash !!

 

[fresh_42]

I meant the C++ compiler, more precisely, the result it produces, not a stupid program code IF "/0" THEN. How did they tell the compiler to produce a machinery code that knows when to throw an exception?

Edit: Before someone is offended. Stupid refers to the fact that this hard-coded line has no intrinsic intelligence, whereas exception handling is not trivial in my mind.

 

[AtoMick-u235]

I meant the C++ compiler, not the program code.

In all my programing over the years, i have done a lot of compiling , a "Division by Zero" is extreamly rare, my cousin has been an accountant for 40 years, i asked her, and she never encountered a "Division by Zero" ever, , ha

A copilier is a program !!

 

[fresh_42]

In my all my programing over the years, i have done a lot of compiling , a "Division by Zero" is extreamly rare, my cousin has been an accountant for 40 years, i asked her, and she never encountered a "Division by Zero" ever, , ha

This does not answer the question of how Throw Exception Catch Exception is realized so that it can catch division by zero or any other exception. It's not always a numerical problem, but those count, too, e.g. the logarithm of a negative number or an invalid string handling.

Divisions by zero occur in the developing and testing phase of a project. I even had a PL/I compiler error because it didn't correctly handle the initialization of an integer as zero. Things happen, and hopefully, before the accountants use a program.

 

[AtoMick-u235]

if I remember right with the 68000, Exceptions are just a JUMP and can be operated in User or Supervisory mode. it has been exactly 30 years ago, so i'm a bit rusty, , ,

 

[pbuk]

This does not answer the question of how Throw Exception Catch Exception is realized so that it can catch division by zero or any other exception.

This is hardware and software dependent, and may also vary for different types of operation (integer, floating point, SIMD (vector)). I will outline one way (perhaps the most common way).

• When the CPU encounters an exception condition it executes a trap with a certain value (a trap is a special kind of interrupt, one that is generated by the CPU rather than external hardware or software).
• The processer handles the trap like other interrupts by looking up the value in an interrupt vector which stores the address of a subroutine to call.
• The addresses stored in the interrupt vector are set by the operating system which will default to terminating the relevant program when an exception occurs.
• An application program may include code to handle exceptions occurring while it is executing itself. On loading it will tell the operating system about this so that instead of terminating the program the OS will call the relevant code.
• Many high level languages include instructions to handle exceptions, typically using a ‘try…catch’ block (‘try…except’ in Python and Pascal). When the compiler encounters the ‘try’ token it inserts code to call the ‘catch’ block when an exception is encountered.
• Most high level languages will ignore floating point divide by zero by default, allowing the program to continue with the value of + or - Infinity (or NaN for 0/0). Among modern languages used for scientific applications (including Matlab and Mathematica), Python is an outlier in this respect: it throws an exception for any division by zero.

It's not always a numerical problem, but those count, too, e.g. the logarithm of a negative number or an invalid string handling.

The logarithm of a negative number yes, but 'invalid string handling' is not something that the CPU understands: strings are implemented in high level languages which must insert code to detect for such invalid handling and create the exception. The c++ std::string library does this whereas of course C style strings do not (and are therefore the source of many bugs and hacking exploits).

This thread probably belongs in computing rather than General Math.

 

[Vanadium 50]

I hate to bring this up, but there is also something called "defensive coding" - instead of throwing an exception and recovering from it, the program checks if the denominator is zero before executing the division. If it is, it can recover more gracefully.

The usual objection to that is "it's slow!". To that, I say "so are exceptions" and "it is the rare program indeed that spends most of its time dividing two numbers - will you even notice this?" And if I am grumpy, I'll say "Get the code working and bug-free, then profile it, and only then worry about speed."

SIMD

I would say that's where you really, really want to do this. If you have a divide by zero in one calculation, you will have to handle not just that, but all the simultaneous good calculations in the same instruction.

Don't count your chickens before they're hatched, and don't optimize your code before its written.

 

[pasmith]

Computers also do not understand removable discontinuities; if you tell a computer to find $(x^2 - 9)/(x - 3)$ and $(x - 3)/(x^2 - 9)$ for $x = 3$ it will produce NaN for both, rather than 6 and 0 respectively. If you want the latter, youl have to catch it and handle it yourself.

 

[Vanadium 50]

removable discontinuities

That would be a good example of something to be handled before throwing the exception rather than as part of the recovery.

 

[hmmm27]

If the divisor is small enough compared to the dividend that the quotient has gotten too big for its register, an "Overflow" (or maybe "Size Error" which covers a few more bases) return-code gets tossed back to the program, instead of the usual "yup, worked fine".

If you've gotten a literal "Divide by Zero" error, that's probably extra code in the software, inserted by a "helpful" compiler/interpreter. The hardware doesn't actually care, and will continue onwards unless you've coded in something to do if an error occurs.

 

[hmmm27]

Lots of machine operations produce return-codes that get sent back to the program running on them whether something unusal happened or not. It's up to the programmer to choose to use them.

In the case of a Size-Error for a divide, it doesn't have to be a zero, just any number small enough (compared to the dividend) that the quotient overflows its register.

If you get a literal "Divide By Zero", that's probably some code introduced by the "helpful" compiler/interpreter, as a pre-check.

Doesn't hurt the machine ; it will just keep chugging along either way.

 

[Vanadium 50]

I just looked it up. IEEE 754, which is the standard most chips use for floating point returns +INF for a/+0 and -a/-0 (where a is a positive number) and -INF for a/-0 and -a/+0. It also have two zeros, +0 amd -0. Dividing either zero by either zero gives NaN.

How the program treats this is, of course, up to the programmer.