Not automatically, when you catch this error you can implement a procedure to end the program without necessarily catastrophic consequences.Yeah--where the subroutine prints an eror message, and exits the program.
nimzo
Last edited:
Not automatically, when you catch this error you can implement a procedure to end the program without necessarily catastrophic consequences.Yeah--where the subroutine prints an eror message, and exits the program.
Yeah--where the subroutine prints an eror message, and exits the program.
Dividing by zero usually means either 1) you messed up the calculations, or 2) you screwed up the valid domain
Now if you look at division this way, lets say you have an apple (thinking of Newton) to be divided among 2 people... each gets half. Now if you divide the apple between ZERO people, what do you get? I beleive its the whole apple... so dividing by true zero is the number itself!
exactly. Amazing how few folks use that deviceAnd in both cases you'll put in a sanity check right before the divide, too, just in case. Unless you're in an extremely tight embedded system. In which case it's probably worth the effort anyway.
can't emphasize how much faster and more stable my coding has become since I took the extra 10 seconds to test for divide by zero, array bounds access, pointer != NULL (and pointers all initialized to NULL), years and years ago. Even if something doesn't work, at least you're not crossing your fingers hoping the same error occurs when you step through the code as when you simply run it anymore.
Even if you don't think you're dividing by zero (say, you're dividing a known non-zero by another known non-zero) you could still, in theory, create a zero via division underflow, where you divided it so small it turns into zero on the internal representation. So you never know. So, too, for dividing by a sufficiently small number creating a +INF number, or even a valid number that's simply way larger than you're thinking possible.
bsolutely--you print the error message, the values, and normally exit by pretending you're done.Yeah--where the subroutine prints an eror message, and exits the program.
Not automatically, when you catch this error you can implement a procedure to end the program without necessarily catastrophic consequences.
Or there are no data points for which to calculate the mean. Or the array to be sorted is empty. Or the string to be centered is null.rwguinn said:Dividing by zero usually means either 1) you messed up the calculations, or 2) you screwed up the valid domain
Well, it seems that no one here has studied more than high school math (no offense meant),
but you can divide by zero. Although, of course, this does require to accept the so-called hyperreal numbers, where infinitesimals exist.
The hyperreal numbers have existed for a long time now, and are a consistent mathematical framework, although not all mathematicians accept them, or like them. Besides, although it is not strictly correct (not in common algebra at least, and very gross abuse of mathematical notation) any real number divided by zero is equal to infinity.
Zero can't be divided by zero in this way. Which is why the guy invented nullityany real number divided by zero is equal to infinity.
any real number divided by zero is equal to infinity.
I really, really wish people would understand this simple statement: YOU CAN'T DIVIDE BY 0 ON THE REALS. NO NO NO NO NO NO NO. STOP TRYING.
I spend so much time coding defensively to avoid problems that I never get around to making my programs do anything useful. But damn I catch a lot of errors.I can't emphasize how much faster and more stable my coding has become since I took the extra 10 seconds to test for divide by zero, array bounds access, pointer != NULL (and pointers all initialized to NULL), years and years ago. Even if something doesn't work, at least you're not crossing your fingers hoping the same error occurs when you step through the code as when you simply run it anymore.
Yes, there are infnite numbers in non-standard analysis, but as you point out yourself, they are the reciprocals of infinitesimals; none of them is the reciprocal of zero.And I thought that if we accept infinitesimals, this means that we have to accept their multiplicative inverses, which could allow to represent infinites as numbers, and so 'define' the division of a number by zero...?
The assert statement is your friend. From one small module of an application I'm writing:Beerina said:I can't emphasize how much faster and more stable my coding has become since I took the extra 10 seconds to test for divide by zero, array bounds access, pointer != NULL (and pointers all initialized to NULL), years and years ago. Even if something doesn't work, at least you're not crossing your fingers hoping the same error occurs when you step through the code as when you simply run it anymore.
assert source_ok: not nil? src;
assert not_empty: source_sp > 0;
assert source_available: source_sp > 0;
Sure-you can do anything you want--just ask any 3rd graderThis is wrong. If a/0 = infinity then -(a/0) = -(infinity). But -(a/0) = -a/0, and -a is another real number, so a/0 = -infinity. Well damn, that looks like a contradiction unless you let -infinity = infinity.
I really, really wish people would understand this simple statement: YOU CAN'T DIVIDE BY 0 ON THE REALS. NO NO NO NO NO NO NO. STOP TRYING.
Turing completeness and the Church-Turing Thesis are now on the scrap heap of history.Yeah, the Turing machine quote confused me as well. If he somehow conceived of a machine which was "more powerful" than a Turing machine (can compute more things) then there are a lot of computational theorists that want to have a little talk.