Slashdot Mirror
Ask Slashdot: What's the Harm In a Default Setting For Div By Zero?
New submitter CodeInspired writes: After 20 years of programming, I've decided I'm tired of checking for div by zero. Would there be any serious harm in allowing a system wide setting that said div by zero simply equals zero? Maybe it exists already, not sure. But I run into it all the time in every language I've worked with. Does anyone want their div by zero errors to result in anything other than zero?
Does anyone want their div by zero errors to result in anything other than zero?
Yes.
It means your code is wrong. Who knows what led up to that /0 error.
Burning karma here to see if anyone else has the same problem. Mod offtopic if you like.
New posts of mine aren't showing up for about half an hour typically. Do they need to be staff approved now or something?
Second, on several front page stories, I no longer have the option to post. They say, "Nothing to see here. Move along" and "Archived discussion".
I think the new design changes are pretty alright, but those two are breaking changes for me.
Umm, wtf is this shit?
"Rather than failing when an unexpected condition arises, I want all software on my system to continue running with a possibly invalid or meaningless internal state."
Sure, what could go wrong?
So how do you know if you had an error if you return "0" for a divide by 0 error? Now you have a whole 'nother set of problems to code around.
LongTail SSH Brute Force analysis tool is here!
Because that usually means I'm trying to do something that's mathematically meaningless and I'd rather handle the special case than silently get a meaningless result.
...aside from the fact that it's completely wrong I can't see a problem with it.
I think infinity makes a bit more sense than zero. And max is the closest thing to infinity.
... he is tired of life.
Division by zero if anything would be +infinity or -infinity depending on signs, not zero. A while ago I wrote an autopilot that handled division by zero by looking at the signs and setting the result to (maxpos) or (maxneg), the zero's sign being derived from the variable's last value scavenged from the PID function.
Liberty - Security - Laziness - Pick any two.
This idea reminds me of "On Error Resume Next". The reason you don't do that is because a divide by zero indicates that you've got a logic failure somewhere else in your code. It's frequently easier to find an error when it's flashing big and red and throwing exceptions, rather than failing silently.
no, because div by zero is not equal to zero
I'd rather either have an exception thrown or a "NaN" value used than a zero returned. A divide by zero error is nasty, but just "papering over" it by returning a zero is only going to introduce more subtle bugs in the code.
Hi SlashDot. I'm a programmer who is tired of sanitizing inputs and checking for exceptions. Can you suggest a way to change the world so those things don't exist?
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
There's a reason you're calculating a division. That number is supposed to be used for something. If your program is dividing by zero, the data it's working with is wrong. The consequences of just pretending to have a valid answer could vary from totally harmless to nuclear winter. But what's the upside?
Zero doesn't make a lot of sense if for instance you are dividing something by a dynamically changing denominator that hits zero at some point... the result would change from a very large number suddenly to 0.
Divide by zero is infinity so using the largest supported number type seems reasonable for the calculation of real numbers.
No, mathematically, division by zero is undefined.
Only engineers think it's infinity!
Good thing you're pushing untested code into production, Dice!
Well, you see, they had this divide by zero error ...
Does anyone want their div by zero errors to result in anything other than zero?
Yes.
No.
Maybe.
Would there be any serious harm in allowing a system wide setting that said div by zero simply equals zero?
What could possibly go wrong when you assert that infinity equals zero? Well, let's see, your logic errors will go undetected, for one. If you are dividing by zero YOU ARE DOING IT WRONG. You might as well just ignore bus errors as well. And while you are at it, just ignore if the disk is full and keep writing anyway. What could go wrong?
100.0 / 0 = 3
402350.32302 / 0 = 3
pi / 0 = infinity
1942 / 0 = 0
194.3 / 0 = 0
101 / 0 = 1
1010 / 0 = 2
200.02 / 0 = 3
4004004 / 0 = 4
Somebody please submit a RFP for this to C++17 standards committee.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Apparently so that everyone can hit some stupid Share button by mistake instead.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
The Limit as x aproaches 0+ of a/x = infinity.
But the Limit as x approaches 0- of a/x = negative infinity.
because this represents a jump-discontinuity, the value of a/0 is just plain undefined.
This is like week-1 of high school precalc shit. Come on.
You want to find out how many Euros in those Zimbabwean dollars you're keeping track of. The exchange rate fluctuates. The web-API you're using goes offline and returns zero, so you divide by zero. Whoops. How do you tell the difference between worthless numbers and just worthless currency?
You want to draw an interlaced gif of some sort, so you do every nth line, then every n-1th line, as you get the interlaced lines and work down towards a full image with every row drawn. And then you cock up at the end, accidentally hit zero and you overwrite the first line thousands of times with garbage rather than spot the mistake.
Zero is so completely the wrong answer, you don't even understand why. The actual real answer shouldn't even be the largest integer you can hold. And if it is, it could also be the smallest (i.e. largest negative). But actually it's none of them.
Division by zero is NOT something that produces a number. It cannot happen. It cannot return zero (which is incredibly wrong), nor can it return any single other consistent constant. It should actually just error, which is why it does. It should produce something that's not a number (NaN). And it does exactly that.
Divide by zero is like a null pointer. On the face of it is appears singularly useless. Why on earth would you want a pointer that you can't dereference? But it's there as an indicator. You cocked up. Majorly. If your maths is at all important at that point (a cell in a spreadsheet), then you're potentially losing billions of digits of accuracy.
You can continue on blindly with your cockup quite easily. Any idiot can overload the divide operator to return zero when the denominator is zero. And you won't get any of those nasty errors. Errors which are indicative of an earlier error that you're just ignoring.
There's a reason that, even back in the days of BASIC and very limited ROM space, you programmed in divide by zero as an error rather than just returning zero and documenting it. It's the same reason that you don't just "ignore" NULL pointer dereferences by saying "Oh, well, we won't call that function and just carry on from where we were then". Any idiot could make some kind of overload to allow that as well if they really wanted.
The fact is that if you're dividing by zero you're doing something that's mathematically impossible. There is no amount of zeroes you can multiply to get anything other than zero. Not even if you multiply infinities of zeroes do you get anything other than zero. Hence division by zero of any non-zero integer is IMPOSSIBLE. It doesn't have an answer.
And, like the square root of -1, if you just ignore it and pretend it exists you will run into all kinds of trouble. If you want to do something with it, in the same way that we use "i" to represent the square root of -1 to get lots of magical maths that actually works, use a language that recognises NaN and test against it.
But I'll tell you now that it's quicker and easier to test if you're dividing by zero BEFORE you do the divide.
2/0.1 = 20
2/0.01 = 200
2/0.00000001 = 200000000
2/0.000000000000000000000000000000000000000000000001 = 0
Exactly as you would expect!
When things get complex, multiply by the complex conjugate.
Perhaps the Big Bang was a divide by zero error? That would explain a lot.
No, 0/0 is still undefined.
Let's say I have have product sales like 4,6,0,5 and want % changes:
6/4-1 = 0.5 = +50% ok
0/6-1 = -1 = -100% ok
5/0-1 = -1 = -100% epic fail
Though I really wish you could get NULL when doing a divide by 0 in a database instead of an error.
Live today, because you never know what tomorrow brings
In a code as simple as that it is easy to spot but in more complex code this simple verification may be done in more steps or split in many different operations like:
where some_function(speed1, speed2), built by other team has:
Now, how this question was accepted as legitimate in an advanced forum like this it is amazing. Rock bottom.
After 20 years of programming, I've decided I'm tired of checking for div by zero.
I am amazed that someone can persist in a career for 20 years without a clue as to what they are doing. If you are getting divide by zero errors there is something wrong with your logic. Don't blame the computer and certainly don't try to outsmart the computer which is trying to help you by pointing this out. Div by zero errors aren't something you should gloss over, they're something that should make you sit down and come up with an algorithm that actually does what you thought it was supposed to do.
Seven puppies were harmed during the making of this post.
... for extremely large values of 2.
While you are making changes ....
Have gnu, will travel.
You will have many horrible consequences.
You have no idea what your code will produce.
You will never know that your code actually works.
As you spend a VAST amount of time debugging weird stuff, you will eventually realize it would be better if the program crashed when the error happened.
Example from yesterday. A web-based graphing package had a field "Number of minor ticks per tick". I selected 0 and pressed ENTER. The webserver crashed with a division by zero error.
If that software had FOOLISHLY decided to replace a division by zero with 0, then it would have gone into an infinite loop drawing the graph when it calculated the
tickspacing to be zero...
Example from today. I was configuring a call to a SOAP service, which was receiving an error from the Server "Division by Zero". It turned out that the error was that I had an HTTP header with no value.
Division by Zero is an error TO BE IGNORED AT YOUR PERIL.
Yes, both pieces of software had sloppy coding, but they both crashed, which helped me continue.
"Can't I just be a programmer and not understand math?"
Dividing any other number than zero by zero is well defined as infinity or minus infinity.
We need a -1 Wrong mod for just this sort of post.
First issue, x/0 mathematically is infinity, not zero. Plus, you want the same exact result across all applications ever? There are certainly times where zero is appropriate, there are also many times when one would want to have some representation of infinity; yet others where this simply indicates an error of some other sort and zero is a valid result.
Actually, mathematics does not define the result of x/0 (except in the extended complex plane or Reimann sphere, the answer there is complex infinity). I also fail to see when zero is an appropriate answer. If an application is asked to divide by zero, any subsequent result that uses the outcome of that division will not be mathematically valid. Surely one can see that the application should stop the calculation and report to the user.
For definitions of "well-defined" that selectively ignore the definitions that mathematicians use, perhaps.
File under 'M' for 'Manic ranting'
You have one apple and no people, no one gets the apple. In the real world there is no problem with this reasoning,
In conclusion, math fails to express the natural world.
Umm, math is not failing to express the natural world, NOT AT ALL. It is the IMPLEMENTATION of the math that fails to express. Mathematics is totally comfortable with the idea of infinity. Integer arithmetic IS NOT.
FAIL
caused by dividing by zero returning zero.
Defining it to zero only makes sense where zero is also an error in the numerator, and/or zero is not a valid result in your problem domain.
Once a biologist, a mathematician, and a programmer were out riding in a Jeep on safari in Africa. Suddenly, there appeared, in a heard of zebras, a white zebra! This following conversation ensued:
Biologist: "A white zebra! We discovered a new species! We'll be famous!"
Mathematician: "Technically, we only know that it's white on one side."
Programmer: "Oh no, a special case!"
Programming is full of special cases. Part of being professional is learning to deal with it. There is no technology, no setting that will get rid of them for you.
"First they came for the slanderers and i said nothing."
You only think this makes sense in the real world because you phrased the answer improperly."No one gets the apple" does not answer "how much of the apple does each person get?" The answer to "how much of the apple does each person get?"is "the question makes no sense because there are no people, so there is no 'each person'." Which is the real-world equivalent of what the mathematics says ("No answer/not-a-number").
Absolute idiot. Reminds me of a time years ago when I was working at a University computer center. Despite my cultivated angry looks, a student came up to me with a printout and asked "Uh, what does this mean?" I said, "Oh, you want me to read it to you? It says: Error -divide by zero on line 50." I got a blank stare. So after a minute I further said" It means you are trying to divide by zero on line 50 of your code, which of course you can't do." That was responded to with another blank stare. So I said "look, here is line 50. See those two variables that you are multiplying together and then dividing into those other numbers? One of them must be reaching zero. Since you can't divide by zero the computer is trying to tell you that something has gone wrong. Go back, print out the variables inside the loop right before line 50 and see which one reaches zero. Then figure out why it is zero." The student said nothing and wandered away, apparently unhappy that I just didn't write the code for her.
A few days later one of the student operators who worked for me there said to me "Remember that girl that you tried to help with the divide by zero problem? She's getting a B+ in her computer science class." Such is the state of the education system. This was a while ago, but as far as I can tell, and this post indicates, things have no gotten any better.
No, you don't just ignore this problem and you absolutely don't put a system wide rule in effect to ignore the problem. If you get such an error it indicates a very fundamental problem wit the logic of the program. It is not trivial, and in real world situations could be deadly.
And you don't just return the largest system number rather than zero, as some other idiots have suggested. That would be just as wrong and just as dangerous.
And if you are really seeing this error often, I strongly suggest a change in profession to a short order chef.
I'm an American. I love this country and the freedoms that we used to have.
Or maybe after 20 years, he should stop dividing by zero, either way.
Honestly, I think I'd prefer having pi defined as three than have division by zero return zero. My answers will at least be in the right domain even if the value is off a bit.:)
Infinity does not exist. Real mathematicians (ie - NOT you) only speak of numbers APPROACHING infinity. So, as the divisor approaches zero, the quotient approaches infinity. You cannot have infinity as a quantity since it does not exist. Otherwise what happens when you divide infinity by zero, and is that new infinity the same as the first infinity?
Seven puppies were harmed during the making of this post.
Usually it just lets the magic smoke out. A divide by zero is usually called a short circuit and makes a lot of heat for a short period of time, after that you get the smell of the magic smoke.
Oh my god, this whole discussion is so misguided it hurts my eyes to look at. Why don't you people go educate yourself about floating-point arithmetics? IEEE754 standard was designed by top-notch numerical expert and YOU IGNORE IT AT YOUR AND YOUR USERS' PERIL.
And yeah, division of nonzero by +zero must give Inf, and there are actual useful numerical algorithms that make use of that.
No he isn't. He is right, too.
For certain kinds of abstract algebras division by zero is even defined, although typically as a special element like infinty, but not 0 (the additive identity element) which would lead to all kinds of peculiar situations: like 0 * 1/0 = 0, so 1/0 has to be regarded as both 1 and 0 at the same time.
BUT if you're dealing with regular numbers or anything that obeys the axioms of an algebraic field, division by zero always represents a failure of the assumptions under which you undertake the calculation. Since it is a failure of assumptions it should always be treated as an exception to normal logic flow. If the correct -- or more accurately speaking the safest -- course of action to take is to assign a value of 0 to a calculation then of course you can do that, but that's still a case of exception handling. Building that as default behavior FORCES a certain response to an exception which of course the language designer can't possibly know is the safest response.
In fact, even implicitly allowing division by zero in a sequence of algebraic manipulations can lead to faulty results even without actually performing the arithmetic operation in question. That's behind several algebraic "paradoxes" that have made the rounds of the Internet over the years, such as the following algebraic "proof" that "2 = 1":
Let a = b // multiply both sides by a // subtract b^2 from both sides // factor both sides // divide both sides by (a-b) // substitute b for a on the left side // collect terms // factor out b
[1] a^2 = a*b
[2] a^2 - b^2 = ab - b^2
[3] (a-b)*(a+b) = b * (a - b)
[4] a + b = b
[5] b + b = b
[6] 2b = b
[7] 2 = 1
It all looks kosher, but it's not because there's a division by zero in the *algebra*. I've actually seen programs that give faulty errors because the programmer simplified expressions in ways that commit this exactly blunder. The language and compiler can't catch this because the division by zero occurred in the programmer's head.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There's a classic document appropriately titled What Every Computer Scientist Should Know About Floating-Point Arithmetic. The "Special Quantities" section discusses plus and minus 0, denormal numbers, infinity, and NaN and offers some rationales for why those special values exist in IEEE floating-point arithmetic.
Well, you're fighting against the people whose opinion is, "God, I just want my program to compile and run so I can go home! Who cares if it gives stupidly incorrect answers!"
Comment removed based on user account deletion
Indeed. And my programs would run a lot quicker if pi was 4. Does anyone really want pi to be anything other than 4?