• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

BBC reports professor can divide by 0

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.

nimzo
 
Last edited:
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

And 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.

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.

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.
 
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!

Ahahahahahahahahaa.... hahahaha... ha...

...oh, I love the comments. You can't divide something into zero units. You might want to, but you can't.

I think a lot of them are misunderstanding the whole 1/x approaches infinity as x approaches 0 thing. You can't reach infinity because it's a mathematical concept, not a number. You can start saying "nullity" instead of "infinity", but you still can't reach it as a singular number.

If I'm wrong, feel free to correct me. I'm not a mathematics PhD, so I might be missing something.
 
And 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.
exactly. Amazing how few folks use that device:D

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.

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.

large differences in small umbers can be a problem, indeed.
Geat minds...?:p

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.
bsolutely--you print the error message, the values, and normally exit by pretending you're done.

nimzo
 
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.
 
rwguinn said:
Dividing by zero usually means either 1) you messed up the calculations, or 2) you screwed up the valid domain
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.

~~ Paul
 
This reminds of a time back in junior high when our local town paper had an article with a title something like
"Local 3rd Grade Class Finds Flaw in Calculators"

Our math teacher came in fuming because the "error" was the class's teacher not knowing the order of operations.

I agree with Paul, Nullity is stupid.
I prefer Infinitude.
 
Well, it seems that no one here has studied more than high school math (no offense meant),

Not so.


but you can divide by zero. Although, of course, this does require to accept the so-called hyperreal numbers, where infinitesimals exist.

If you abandon the standard reals many things are posible. 0.999... not equaling one is one example. However hyperreals do not allow for division by zero (there are systems which do but hyperreals are not one of them) what the hyperreals do allow is division by infinitesimals.

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.

While that appears to be a convient answer it doesn't quite work. Useing standard reals devideing by zero is undefined
 
I took the time to read his axioms, and I am not impressed. The semantics are similar to IEEE arithmetic (1/0 = +Inf, 0/0 = NaN), with very few differences (he thinks differently). In my opinion, the standard does it better.

In any case, an implementation would be full of implicit conditionals. For instance, he has the axiom "a/a = 1 for a != 0, Inf, NaN", implying that every division needs a check for 0, Inf or NaN in the denominator, as it did before. So if there was a problem, we are no closer to a solution. Redefining NaN or "Phi" as a "number" does nothing if we still need to treat it as a special case.

The rest of his site set off all my crackpottery detectors.
 
any real number divided by zero is equal to infinity.

This 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.
 
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 know, infinity is not a number, and is not defined with the real numbers. That's why I was saying that it was an abuse of notation. I think a better way to put it would be: limit(h-->0)a/h= infinity. It is just a way of saying that as h becomes smaller, the value of (a/h) becomes larger and larger. But I know, by definition, you can't divide by 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...?
 
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.
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.
 
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...?
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.
 
Claiming that doing nothing is doing something is not a new concept. Lawyers have been doing this for decades!
 
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.
The assert statement is your friend. From one small module of an application I'm writing:
Code:
assert source_ok: not nil? src;
assert not_empty: source_sp > 0;
assert source_available: source_sp > 0;

~~ Paul
 
This 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.
Sure-you can do anything you want--just ask any 3rd grader:D

Giving the value of x/0= is just another way of saying "you (rule 8)ed up."
call it infinity, whaterver--he!!, call it George (and love it and hug it...)
All you're doing is putting another label on "undefined"
 

Back
Top Bottom