Earlier quoted context omitted.
I would say an exception is much more convenient. Buggy code that silently continues to run is very hard to debug!
It's not convenient at all in a language like Coq.
Can you elaborate?
1/0 = 0
281–290 of 593 posts
Re: 1/0 = 0
#282> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks It actually does break something, the symmetry between division and multiplication and the many pieces of code that assume that (x / y) * y equals x. Here is a naive and non practical example, but it is not impossible to find a real world example where this simplified code manifests itself accidentally or by de…
> (x / y) * y equals x Even without Pony's assumption, that's only true when y != 0.
It should be true for every y that is allowed in the denominator.
That is how fractions are handled in higher math. (Either called "localization" or "ring of fractions").
Re: 1/0 = 0
#283Earlier quoted context omitted.
To clarify, in Javascript 1/0 is Infinity, not NaN.
You are correct. But it really should be NaN, since 1/ε is positive infinity, whereas 1/-ε is negative infinity. Oh well :)
Nope, I'd disagree. Zero isn't an approximation of some epsilon, it's really just zero. It makes sense for the output sign to match the input sign.
Re: 1/0 = 0
#284My problem with "1/0 = 0" is that it's essentially masking what's almost always a bug in your program. If you have a program that's performing divide-by-zeroes, that's almost surely something you did not intend for. It's a corner case that you failed to anticipate and plan for. And because you didn't plan for it, whatever result you get for 1/0 is almost surely a result that you wouldn't want to have returned to the…
I almost want two different division operations: One where 1/0 = 0, exclusively for use in progress bars and stuff like that, and another one for everything else. Because frequently division by zero indicates a bug. But similarly frequently, I end up crapping out annoying little bits of code like if (foo == 0): return 0 else: return bar / foo
I've run into this a lot, but I'm also not sure what I really want to happen. Even for progress bars, the behavior can be different depending on how exactly you're obtaining the denominator -- does it increase dynamically or is it known from the beginning? Is it one of those fake progress bars that just ignores the fact that it'll stay at 100% for the next hour, or would it filling up genuinely mean that the work is actually done? After all, if you have 0 operations total and you've finished 0 of them, are you really 0% done? Wouldn't it make more sense to say you're 100% done? At the end of the day the user is trying to figure out how long they should keep waiting, to which the answer would be "you don't need to wait, there's no more work left to do".
Re: 1/0 = 0
#285"Mathematics does not give us truths, it gives us consequences." I'd like to point out that, as I stated in another comment in this thread, the author's supposed refutation of the inconsistency inherent in division by zero within fields is incorrect. Their refutation is as follows: The problem is in step (3): our division theorem is only valid for c ≠ 0, so you can’t go from 1/0 0 to 1 * 0/0. The “denominator is nonz…
First, mathematics does not give us true statements about the world, it gives us consequences that must follow if we accept various axioms or definitions.
Isn't a consequence in itself a true statement?
Re: 1/0 = 0
#286The explanation in the article basically boils down to the following:
let a/b mean, in my programming language's syntax, = { a divided by b when b is not zero, or 0 otherwise.
Yeah, it's not "mathematically invalid," but it punches a hole in the fidelity between numerical methods and the math that they approximate.
Re: 1/0 = 0
#287This article grinds my gears. He quotes a number of mathematicians that correctly state the undefined nature of 1/0. Then proceeds to interpret that this means that we can choose any specific value to represent as 1/0 that we want. NO. We have "NaN" for a reason and it is an important signal to the programmer that a mistake was made. The language that assigns it to 0 silently is bunk as is this article.
> correctly state the undefined nature of 1/0 Erm, when we say it's "undefined" we mean it literally -- standard mathematical systems of arithmetic do not define a value for that division. If you make another system of arithmetic you can define it how you want and be consistent with "regular maths" for the operations in which things are defined. It's an extension. > We have "NaN" for a reason Funnily enough, IEEE754…
Standard mathematical systems of arithmetic do not permit a reasonable definition of 1/0.
Mathematicians define equality of fractions by stating that a/b = c/d if and only if a·d = b·c. This means that if we define 1/0 = 1 then 0 = 1.
To be fair, this is perfectly consistent, except everything in our system is equal to zero.
Re: 1/0 = 0
#288Earlier quoted context omitted.
I almost want two different division operations: One where 1/0 = 0, exclusively for use in progress bars and stuff like that, and another one for everything else. Because frequently division by zero indicates a bug. But similarly frequently, I end up crapping out annoying little bits of code like if (foo == 0): return 0 else: return bar / foo
Isn't a ternary here nicer? return (foo == 0) ? 0 : bar / foo or even return bar / max(1, foo) in the case where foo is integer or tiny foo would overflow your range anyway
Ternary doesn't really look any better. I'd do this in a language that supports it though:
return foo && bar / fooRe: 1/0 = 0
#289You lose simple properties of division, such as (a + b)/c = a/c + b/c. If you set 1/0 = 1 (as the author claimed causes no inconsistency), then (2 + 1)/0 = 2/0 + 1/0 is false If you come to rely on division by zero behaving a certain way (as happens to all features/bugs of any language), then suddenly silly decisions about how to implement a formula can cause wildly different behavior. Good luck refactoring!
[deleted]
Re: 1/0 = 0
#290Sometimes I wonder how much actual energy is expanded by humanity in such 'debates' (electricity, coal, nuclear..). I'm just that kind of person that likes to put thing into perspective. I'm certainly as 'guilty' as the next person in engaging in such trifle matters :-)