Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite

I know that modern languages handle integer divide by zero as an error just like the hardware does, but what if we could design a whole new language?

Ignoring existing hardware, what should a programming language does when an integer divide by zero occurs? Should it return a NaN of type integer? Or should it mirror IEEE 754 float and return +/- Infinity? Or is the existing design choice correct, and an error should be thrown?

Is there a language that handles integer divide by zero nicely?

EDIT When I said ignore existing hardware, I mean don't assume integer is represented as 32 bits, it can be represented in anyway you can to imagine.

share|improve this question
It seems that what you want is a compiler/language that will by default ignore your programming and logic errors! If you divide by zero you have made a mistake, it may be a design error or just a typo perhaps just insufficient validation -- but you have made a mistake. – James Anderson Nov 16 '11 at 3:02

migrated from stackoverflow.com Nov 16 '11 at 1:52

12 Answers

up vote 14 down vote accepted

Usually, integer types of programming languages do not support NaN values. Since they use the whole, say, 32 bits for storing the number without any special values. IEEE754 defines special bit patterns for +Inf, -Inf, Nan, ... which are not defined for an int.

Personally, I believe the way it's handled by throwing a DivideByZeroException is pretty good. If you reach a point that you hadn't checked for divide by zero, you've probably missed something you shouldn't have ignored, therefore, it's critical to issue a fatal error.

EDIT: Ignoring the way hardware handles integers, I still believe the error should be in form of an exception or something, at least by default. The primary reason doubles allow divide by zero is the fact that due to a computation, you might have a very small value near to zero to divide by. In fact, +Infinity does not mean real infinity. It means it's much larger than can be handled by a double. For an int, the range is much limited and the closest positive value to 0 is 1, so divide by zero in an int is most likely a programming error as opposed to a precision loss.

share|improve this answer
I said ignoring existing hardware, so why are integers 32 bits? – Pyrolistical Jan 5 '09 at 18:58
1  
I thought you meant ignoring the way hardware deals with divide by zero! – Mehrdad Afshari Jan 5 '09 at 18:59
up vote 13 down vote

Yes, it is an error, This is a number that has no meaning (it is not infinity despite what some may say).

The best solution would be to check for this before the division occurs.

The second best case is to throw an exception and handle it.

Here is a link to a blog entry on zero Good math bad math

share|improve this answer
1  
Agree with this 100%. A division op is math, and in math dividing by 0 is undefined. It's not legal, it's not allowed, and it's not infinite unless taking limits. Unless your language is overloading division to be more than a mathematical op, divide by 0 should be an error. – nezroy Jan 8 '09 at 21:14
Checking before the division occurs is not the best solution. That would slow down the computation considerably to handle the rare case when the divisor is zero. – kevin cline Nov 16 '11 at 4:20
Even if taking limits; lim x->0 1/x is undefined as it could be positive or negative infinity. – Anton Golov Jan 31 '12 at 1:34
@AntonGolov: The ideal handling of zeroes, infinities, etc. would be to have one unsigned zero, along with positive and negative infinitesimals (the latter two being produced by multiplications or divisions whose result would be too small to represent). Adding two infinitesimals of opposite sign should yield unsigned zero; in all other cases, adding something to an infinitesimal should simply yield the other operand. Under such rules, division by "unsigned zero" should yield NaN, but division by an infinitesimal would yield positive or negative infinity, yielding correct limit behavior. – supercat Jul 12 '12 at 17:59
@supercat: I'm just going to assume that's sarcasm. Please let me keep believing that. – Anton Golov Jul 19 '12 at 21:51
up vote 5 down vote

The existing design choice is correct. If you want NaNs and infinities you should be computing in the floating-point space to begin with. Today's floating-point units do integer arithmetic very efficiently.

A language that handles divide by zero nicely is Standard ML: dividing by zero is guaranteed to raise an exception, but it's an exception (Div) like any other and can be caught by user code.

share|improve this answer
Um, what is so special about Standard ML's exception? Java has ArithmeticException, and C# must have something equivalent. (Not saying you claimed ML was unique, just wondering why you mentioned this particular language!) – Andres F. Jan 31 '12 at 0:29
@Andres: Nothing special. Standard ML was there 15 years before Java. – Norman Ramsey Jan 31 '12 at 2:50
good point :) I just asked because I guess many (if not most) modern languages have some way of handling arithmetic errors. – Andres F. Jan 31 '12 at 12:47
up vote 4 down vote

I think division by zero is pretty much the standard example of how exceptions work. Higher level languages throw DivisionByZero exception, the x86 hardware (in protected mode) throws a division by zero exception as wel, etc. Exceptions can be handled.

A division by zero is an error. Failing to report a severe error like that could have disastrous consequences.

What would you prefer: if the software of the X-Ray machine that is scanning you would throw an exception and shut down if it divided with zero for some reason, or just returned positive infinity and this would be the X-Ray dose you would get?

share|improve this answer
What do you prefer, a life support machine that halts that divides by zero, or just prints NaN since it was for display purposes? We both can make up examples that assume poor testing or design. – Pyrolistical Jan 5 '09 at 19:05
Pyrolistical: Obviously, on life-critical systems, robustness is extremely important. That's why a life support machine should throw an exception and reset if it divides by zero. Otherwise, it might kill the patient by using invalid data. It should never ignore division by zero. – DrJokepu Jan 5 '09 at 19:19
You missed by point. I am saying for life critical software, no matter how divide by zero is handled, it would be a great failure on testing and design if those two examples were to occur. – Pyrolistical Jan 5 '09 at 19:28
True, it shall never happen. But what if it still happens? No amount of good development practices, code reviews etc could filter out all of the bugs in all possible circumstances. There must be an error handling mechanism, and dividing by zero is definitely an error. Not handling it could be fatal. – DrJokepu Jan 5 '09 at 19:37
up vote 1 down vote

I don't think there's a nice way to handle it. Throwing an exception is probably the best thing to do, because it forces the developer to think about it, an code correctly. Assuming 1/0 returned NaN, what happens when you try to add NaN to something else, does it throw an exception, or does it return NaN again (same could be said for infinity). Since there is really no define action to take, the developer should program what they want to happen when divide by zero occurs.

share|improve this answer
The way IEEE 754 defines it is operations using NaN produces NaN, and NaN does to equal NaN. – Pyrolistical Jan 5 '09 at 19:06
up vote 1 down vote

An integer, by definition, is a whole number.

NaN, infinity, etc are NOT integers.

If you expect to be working with objects that are not integers, you should use objects that support the needed representations.

If you are expecting your data to always be representable by an integer, then by all means use an integer type, and if there is an error you'll need to handle it, but the bad data is the culprit - not the program (as long as the program is designed correctly). The program should then decide how to recover depending on the design.

So, in short, the current programming languages offer everything you need - an integer type for integers, and various other types for mathematical representations that are not whole numbers.

Please don't turn the integer into something it's not - there's no reason to make the integer handle non-integer values.

share|improve this answer
You could have two different types of NaN, one is integer, other is the IEEE 754 one... I don't see your point. – Pyrolistical Jan 9 '09 at 1:33
1  
The point is that neither of these conforms to the algebraic laws on numbers. – reinierpost Mar 5 '10 at 18:43
up vote 1 down vote

Division by zero doesn't make sense algebraically: a / b is defined as the number c such that c * b = a, but if b = 0, the only possible value for c * b you can produce is going to be 0, while a can be any number. So you can't pick a c even if you invent one - you're going to have to special-case that c in your code anyway.

Your program probably makes some implicit assumption somewhere that / means what it is defined to mean algebraically, and that assumption goes out the window as soon as you assign a number to be the value of division by zero. So it's best to blow up right away, where the problem arises.

share|improve this answer
up vote 0 down vote

Sadly, the only general answer to this one is...

... it depends.

'Nicely' can be a right PITA in fact.

Best is to know the implications of such a condition, and handle them.

share|improve this answer
up vote 0 down vote

Well, I don't know if it's too important, but I think it throwing an error is reasonable. I'm guessing this is highly subjective, but to me having NaN defined in a language is a workaround for something that shouldn't be done. Dividing by zero is meaningless, and thus an error should be thrown.

But that's just my subjective opinion.

share|improve this answer
up vote 0 down vote

You can do that, but most of the time it won't make any sense.

I have the experience that it is almost always sensible to check if you are going to dived by zero. Because most of the times it will indicate a special situation.

share|improve this answer
up vote 0 down vote

Matlab, a numerical computing environment and programming language, has Inf.

1/0 is Inf. 0/0 is NaN.

share|improve this answer
Matlab doesn't have integers, it just doubles pretending to be integers. – Pyrolistical Jan 5 '09 at 19:07
1  
1/ very very small number tends toward infinity, but 1/0 is meaningless. – Jim C Jan 5 '09 at 19:16
actually the limit of a/x for +x -> 0 is positive infinity for positive a, so you can say the limit of 1/0 is infinity – Pyrolistical Jan 5 '09 at 19:26
@Pyrolistical - Yet your claim is only true if x != 0, even if it is infinitesimally close to zero. An answer to this question has been attempted for thousands of years, including by Newton and Pythagoreas. The problem with allowing it to be a number (even if the number is infinity) is that using that as a fact would allow many laws of nature (particularly in physics) to be violated by using some fancy math which relies on division by zero to return a valid result. – Dunk Jan 30 '12 at 23:28
You can think of it this way. No matter how small x becomes, there is always some infinite number of those small x's that divide into the top number. However, if x == 0, then there is no amount of infinite x's that could ever divide into any number. – Dunk Jan 30 '12 at 23:33
show 1 more comment
up vote 0 down vote

It is definitely a must for a good programming language to support detection of integer overflows because they are a common error and the overflow detection relies on CPU flags that are available only to the compiler, but not the programmer (except in assembler ;-) ).

Basically there are the following strategies to handle something like that:

  1. Don't handle it. That's what C/C++ does.
    This results in the corresponding data types effectively being defined as modulo their size.
  2. Result is largest possible value for the specific data type.
  3. Exception.
  4. Run-time error.
  5. Error indicator (e.g. errno in C).
  6. Special return value (NaN), like usually for floating point.

For every of these strategies, there are situations where they are appropriate and where they are not.

If we look at the strategies,

No. 1 is very error-prone and for the cases where it is really needed, it is redundant if the programming language has got a modulo operator. A good compiler should be able to detect this situation and simply disable overflow checking for this calculation, so that doesn't cost any performance, compared to the C/C++ way.

No. 2 has got the disadvantage of not being able to tell if the calculation delivered the largest result possible or an overflow occured. However, there are applications where an inaccurate result is better than a program error, so this can be useful. For these few cases, it can be emulated with any of the methods 3.-6., so it's redundant.

The strategies 3 & 4 are quite similar, so we could come along with one of them, preferably exception because it's more universal.

No. 5 belongs into the same category, but there are cases where it can simplify error handling over exceptions, etc. It's redundant with the other possibilities 3, 4 and 6
In languages that have an inline assembler, it's possible to examine the corresponding CPU flags in a non-portable way to achieve this, as long as the CPU supports this detection at all (has anyone know one that doesn't?).

No. 6 has also got huge disadvantages, it leads to the definition of the integer type being different from what's common and the special value must not be used accidentially, e.g. as the result of a successful calculation, so the compiler has to generate additional checking code for calculations. Therefore I don't like it.

In my view, the default behaviour should be an exception or something similiar to ensure that the error is noticed. The programmer should be able to disable this or switch to a "less destructive" strategy like 5 by using compiler switches or pragmas.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.