divide by zero... why?

[kryton9]

We all know you can't divide by zero, why aren't compilers written to just treat a division by zero as division by 1 and save programmers from having to write the condition all the time to check for division by zero and not cause errors? If a programmer for sure didn't want this to happen then he could add the check for division by zero into the code, but otherwise for other uses it would save a common error and not really hurt anything.

[Barney]

...why aren't compilers written to just treat a division by zero as division by 1...

That would also be an error, and quite a big one, that's why. A good compiler (actually a language) would have support for handling runtime exceptions of such nature and this would make it easier for the programmer. However, a good programmer would also know where and when a division by zero is likely to occur and would code those parts of his/her program accordingly.

Barney

[Parker]

You would still have bugs, but in that case they would be harder to find. Whenever the denominator is zero, you would have quirky behaivor (actually x/0 = infinity), and you would still have to trap it, but if you forgot you wouldn't be "reminded" by the error.

[kryton9]

I guess I didn't explain it correctly, what I am saying is the compiler would do the check for a divide by zero and if it sees a zero, it places a 1 instead of the zero, no exception is thrown and the program continues. This is for the many times as a programmer you don't care if such a substitution is made for you and saves you from having to always check for a divide by zero.

If however it was important that 1 not be subsituted for a 0, then you would just code in the check yourself as we do now, so this way you get the best of both worlds and one less error to deal with and many checks for zero in your code when you shouldn't really have to anymore.

[Ionic Wind Support Team]

Wow  .  How would giving an incorrect answer solve anyones problem ?  Division by zero is an error because there is no real answer, substituting anything other than zero would be bad.  Glad our missle control software designers didn't resort to that.  There is an infinate number of values between zero and 1 that would not cause an error, so why chose 1??

Anyway the compiler has no idea what the result of an equation will be at runtime, it just converts code from Aurora->assembly->machine code.  So the compiler can't make a substitution anyway. Some goes for all other true compilers.  An interpreter, however, knows what is in variables at runtime so usually handles the error more elegantly. 

The compiler treats well written code the same as poorly written code. As long as the syntax is correct you will get an executable, what that executable does after that is out of the hands of the compiler.  It is up to you as a programmer to write acceptable code, with the necessary checks for nulls, divisions by zero, and overflows. 

That would also be an error, and quite a big one, that's why. A good compiler (actually a language) would have support for handling runtime exceptions of such nature and this would make it easier for the programmer. However, a good programmer would also know where and when a division by zero is likely to occur and would code those parts of his/her program accordingly.

Exception handlers are childs play.  Fletchie wrote one for IBasic Pro that caught things like stack overflow, access violations, and division by zero, I will dig through my archives for it. However the common use of an exception handler is to catch errors from poorly written code.  C++ uses them to the point of being anal about it.  Where a common IF statement will do in most cases. 

The bottom line is a division by error is the fault of the programmer, not the language. 

[kryton9]

Anyway the compiler has no idea what the result of an equation will be at runtime, it just converts code from Aurora->assembly->machine code.  So the compiler can't make a substitution anyway. Some goes for all other true compilers.  An interpreter, however, knows what is in variables at runtime so usually handles the error more elegantly.

That is a good explanation of why it can't be done and I will leave it at that, the question then becomes moot anyways.

[Ionic Wind Support Team]

Glad you understand.

For others that may not be following think of it this way:

a = b / RAND(100);

That equation is poorly written.  The RAND function will return a number between 0 and 100 but the compiler can't know what the function will return when the executable is run.  It just converts the statement to assembly:

Code Select Expand


mov eax, $a
push eax
xor eax,eax
push eax
mov eax,100
push eax
call $RAND
mov ebx, $b
mov esi,eax
mov edi,[ebx]
mov eax,edi
cdq
idiv esi
mov edx,eax
pop esi
mov [esi],edx


At this point the compiler is done with its purpose in life, it has converted the source code to assembly and the IDE then calls the assembler to make it into a binary object and the linker to create the executable.  At no point do any of the three parts of Aurora have any idea what the the 'call $RAND' instruction is going to return.

Paul.

[Ionic Wind Support Team]

I should also note that if you build a debug executable, and run that exe in debug mode, then the line that caused a divide by zero will be shown.

[Kale]

More info: http://en.wikipedia.org/wiki/Divide_by_zero

[kryton9]

I understand this can't be done in a compiled language but, just to talk about this as it is fun...

My thinking to all of this besides what I already wrote and why I chose 1:

I have 10 chairs, I divide by 2 I have 5 chairs. I divide those 5 chairs by 0 in the real world, I still have 5 chairs.
By making the 0 a 1, you then have a correct answer mathematically that matches the real world, since 5 divided by 1 is also 5, we are making programs to mimic the real world with objects, it makes sense, at least to me. In addition, you always have the option of putting in the check for a zero division in your code if you don't want this substitution

[John Syl.]

If I am unsure whether a divisor will be 0 I generally use a small value like 0.000001 to add to the divisor, so the divisor can never be 0.

This is on the premise that as the divisor tends towards 0 the quotient will head towards infinity.
As explained infinity is not easy to define on a computer, so we will say the quotient tends towards a really big number

Using this approach means that the number added to the divisor will obviously limit the quotient value and should therefore be chosen so as not to affect the results too much. 

regards
John

[Ionic Wind Support Team]

Kryton who was you highschool math teacher?  I want to slap him

In the real world we deal with fractions and decimals.  Dividing by a fractional values is the same as multiplying by the reciprical of the fractional amount. 

5 / 0.5 = 10
5 / 0.05 = 100
5 / 0.005 = 1000
5 / 0.0000000005 = 10000000000

The closer we get to zero the closer we get to infinity, not to the original whole number as you suggest.  That is the real world.

[Rock Ridge Farm (Larry)]

Why not test the divisor prior to using it for 0 value?

[John S]

My thinking to all of this besides what I already wrote and why I chose 1:
I have 10 chairs, I divide by 2 I have 5 chairs. I divide those 5 chairs by 0 in the real world, I still have 5 chairs.

I agree with Paul's great statement, "who was you highschool math teacher?  I want to slap him"

You should/must test your denominator before attempting any division to prevent dividing by zero and your test should flag and error or call some corrective measure.  By testing and automatically putting 1 in for the result of dividing by zero you get the wrong answer.   An alternate numeric routine should be called which has been prepared ahead of time to handle the situation.

[kryton9]

Guys, I understand the math, my teachers were very good, they probably would slap me too for what I am saying maybe from a strictly math point of view, but from what I am saying they would smile and chuckle walk away thinking about what I said, and that is not what I am trying to argue

I am saying in the real world, physical world I can say John, take that chair and divide it by zero, what do you get , you still get that one chair. Mathematically to match this situation that is the same as saying divide this chair by 1. The answer is the same then. You still get 1 as the answer.

So if I am programming in classes and creating objects, lets say I programmed in a virtual chair, the same idea should apply, if someone tries to divide the virtual chair by zero, they should get an answer and still be left with their one chair instead of getting a crash or error message. That is all I am saying. Now if I am programming a missle tracking system, yes then by all means I would write code to check many things.

I have no problem with checking for a division for zero, or tracing a bug if one occurs because of this, and somehow my poor communication skills have lead you guys to think that is what I am saying. I am just saying that a program or language should allow for this in the future if we are to try to model as close to the real world as possible. And yes in our world there are 2 worlds, the math theoretical world and the physical world, why not the same in a language and in our coding.

Paul showed currently with compilers it can't be done, but it can be in interpreted languages. So maybe if anyone is working on such an interpreted language, it might be something to consider, that is all really

[Ionic Wind Support Team]

Sorry but dividing by zero is an error and should not be substitued by even an interpreter.  In the real world we do deal with fractional values on a daily basis.  Ever pay taxes?, how about dividends from stocks? ever get a discount at a store?  A language that would make a substitution for 0 to 1 wouldn't be received very well.  The store clerk enters zero by mistake when giving you a discount and the till substitutes 1 because the software was written by your hypothetical language.  So instead of getting a 10% discount on your lamp you get the lamp for free. 

total += price - (price * (1/discount));

Now the clerk doesn't notice because she's entering the 14 other items you purchased and since the till didn't give an error she accepts your money and moves on to the next customer.  You get home and shout for joy because you got a free lamp.  Meanwhile the clerk gets fired, ends up in a homeless shelter, and loses her children to social services. 

All because you wanted a language to accept an error as something else 

[kryton9]

I don't know how many times I said, I am all for putting a check in by the programmer when it matters as in the cases you give. What is so good about that cashier getting a crash and her register not working? Of course the arguement we both are making is that is wrong and of course in a program that would do such a function a check for a zero value should be done.

But what about the situation I wrote about... I have a virtual chair, a virtual robot is asked to divide the chair by a value entered by the user, the user enters 0, what should happen?

[Rock Ridge Farm (Larry)]

I think you are flogging a dead chicken here.
Divide by zero is bad so the programmer must prevent it.
I do not think anything is going to change in hardware land to alter this.

[Steven Picard]

Should we discuss how there use to be a negative zero and a positive zero which is why we moved to ones compliment?   

[John Syl.]

The robot gives a virtual divide by zero error!!

[Bruce Peaslee]

Dividing by zero is an error. If the user enters something to cause it, you should catch it and politely notify the user. If your program does it, it is a bug. It makes no sense to me to continue, in either event, as if nothing happend.

[Steven Picard]

It makes no sense to me to continue, in either event, as if nothing happend.

For those who wish to ignore all errors I recommend VB or VBscript:
On Error Resume Next


edited to add: Recommending On Error Resume Next for ignoring errors was a joke and VB has made that bad practice very easy to do.

[Ionic Wind Support Team]

I don't know how many times I said, I am all for putting a check in by the programmer when it matters as in the cases you give. What is so good about that cashier getting a crash and her register not working? Of course the arguement we both are making is that is wrong and of course in a program that would do such a function a check for a zero value should be done.

But what about the situation I wrote about... I have a virtual chair, a virtual robot is asked to divide the chair by a value entered by the user, the user enters 0, what should happen?

A message box should pop up informing the use that it is an invalid value.  This is not the job of the language, but of the programmer.  The language should never make an unpredictable choice like substituting a value.  I could just imagine the exploits and security warnings that would generate

The cashier getting a crash gets to keep her job, the company who made the register that gets the crash report looks at the output, determines the offending line by looking in the .map file of a debug build, corrects the error and moves on with life.   

Of course in the real world the design cycle would have caught that possibility before the registers went into produciton.  But that is besides the point. 

[John S]

K9,
I understand your dividing a chair by zero example and the thoughts behind it, but the premise is incorrect.  The problem is that a single unit chair cannot even be divided in half.  To quote from the movie One Flew over the Coo-Coo's Nest, " a half a cigarette isn't s*%t Martini!"  A half a chair is not a chair just as you cannot get 2 chairs by dividing a whole chair by 1/2 (0.5).  In this case, you are dealing with integer math (integer numbers are only possible).  You are not allowed to divide by fractional values or zero and therefore should test for values less than 1 and greater than -1 (if negative values have use).

John

[kryton9]

Guys, great posts and points. I understand all the math issues and I guess it is hard to get passed that with programming as it is based on math.
I never really considered what the compiler actually did, and yes what I initially proposed could only work with an interpreted language currently.

For my chair divisible example with the virtual world... I guess it is a matter of philosophy and points of view.

The simple answer is, as I argued that if it mattered the coder would code for the zero check, but I should just say, hey, the way things are now, the coder could
write a check and make a 0 a 1 if he wants and not really depend on the compiler/interpreter, so I yield to your guys points. Good game and congrats you have me convinced
100% of your views, but I will one day make a virtual bot that will divide by zero, better yet he will taunt the user to enter a zero value and issue him to make a division by zero