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.
Quote from: kryton9 on October 03, 2006, 06:58:16 PM
...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
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.
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.
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.
Quote
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.
QuoteAnyway 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.
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:
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.
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.
More info: http://en.wikipedia.org/wiki/Divide_by_zero
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 :)
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
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.
Why not test the divisor prior to using it for 0 value?
Quote from: kryton9 on October 04, 2006, 09:27:04 AM
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.
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 :)
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 :'(
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?
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.
Should we discuss how there use to be a negative zero and a positive zero which is why we moved to ones compliment? ;D
The robot gives a virtual divide by zero error!! ;D
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.
Quote from: peaslee on October 04, 2006, 11:55:17 AMIt 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.
Quote from: kryton9 on October 04, 2006, 11:47:07 AM
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.
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
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 :)
K
you use chairs as your example; divide 5 chairs by 0 and you still have 5 chairs
lets use dollars.
Profits are $100 and I have 100 shareholders so each share holder gets a $1.
But what if there is a flaw in my program and I plug in 0 for the number of shareholders.
With your scheme I sub 1 for the 0 and determine that each shareholder should get $100.
I pass that to the check printing program and generate $10,000 worth of checks!
So you say you can add code in my case to check for 0 but in your case you don't want to.
I wouldn't want to have to do it one way sometime and a different way other times. That would make me more prone to miss a place I should have checked.
Quote from: kryton9 on October 04, 2006, 11:04:52 AM
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.
That's because our brains work at high level and have good exception handling. ;)
I already conceded to the great posts, but just wanted to clarify
QuoteBut what if there is a flaw in my program and I plug in 0 for the number of shareholders.
With your scheme I sub 1 for the 0 and determine that each shareholder should get $100.
I pass that to the check printing program and generate $10,000 worth of checks!
If you entered 1 then only 1 shareholder would get $100 and the rest nothing, you wouldn't be out $10,000 :)
So I do read all the posts and great points. I agree and conceded and actually my original proposal was wrong in what a compiler could do and worked. And as I wrote in my concession, if a user wanted a zero to be a one, he could code it in anyways.
I would be out the $10,000 if it was a modular program and my module only handled seeing how much each shareholder was to get and the other module was by someone else who took care of the printing.
Both modules were suppose to go to the same place to get the number of shareholders. The per share module got the wrong one but the print module got the right one.
If you're going to make a case for substitution (and I'm NOT), at least advocate the "more correct" direction and substitute a very large number. There is nothing even remotely correct about substituting 1... despite the equally flawed chair division logic.
I'll use a trigonometry example since that is where I've most often ran into the possibility of legitimate need (i.e. not an "error") for division by zero.
rise=0.0
run=2.0
angleD = atanD(rise/run) = 0ÂÃ,°
rise=2.0
run=1.0
angleD = atanD(2.0/1.0) = 63.435ÂÃ,°
rise=2.0
run=0.0
angleD = atanD(2.0/0.0) = atanD(infinity) = 90.000ÂÃ,° (correct, but computer won't do it)
angleD = atanD(2.0/0.0) = atanD( 1 ) = 45.000ÂÃ,° (substituting 1... very bad result)
angleD = atanD(2.0/0.0) = atanD( 99999 ) = 89.9994ÂÃ,° (substituting large number... approximately correct result)
I wouldn't advocate this though... unless an operation symbol other than "/" were used, clearly indicating the programmer's intent to accept approximate results, i.e.
angleD = atanD(2.0\\0.0) = 89.9994ÂÃ,°
It wouldn't be good enough in my field, but might be OK for non-critical games or graphics use... even then it may cause more problems than it solves.
Quote from: LarryA on October 05, 2006, 08:51:19 AM
...I'll use a trigonometry example...
rise=0.0
run=2.0
angleD = atanD(rise/run) = 0ÂÃ,°
...
The programmer needs to test and prepare for this contingency and others
// Divide by Zero example
// compile as a console exe
global sub main()
{
float rise, run, AngleD;
rise = 10.0;
for run = 10.0; run >= 0; run--
{
if run = 0.0
{AngleD = 90.0;}
else
{AngleD = ATanD(rise/run);}
writeln ( "\nRun = " + str$(run, 2) + " Angle = " + str$(AngleD, 2) );
}
while GetKey() = "";
return;
}
Quote from: John S on October 05, 2006, 11:21:28 AM
The programmer needs to test and prepare for this contingency and others
Yes, I've incorporated that test and quadrant tests in a few languages over the last 30 years and so far no airplanes have crashed as far as I know.
Your example has rise fixed positive, but a general purpose test needs to handle 270ÂÃ,° (neg rise, zero run) also.
Code can get pretty badly cluttered with these tests, not to mention you get sick of inserting them, and they are sometimes a hidden bug if you do a typo... so I usually create alternative "safe" functions where the testing and divison actually take place...
angleD = atanDsafe(rise, run)
The (very large) program I'm working on right now (prototyped in IBpro/GDI, finale in VB.net/GDI+) has so much trig I think the source code would be doubled if tests weren't in alternative functions.