1/0 = 0 (2018)

In retrospect, I see his point better - practical use trumps theory in most language design decisions.

I haven't changed my mind but the reason has shifted more toward because "it's what a larger set of people expect in more situations" rather than mathematical purity.

Trying to calculate... I don't know, how many 2-disk raid6 groups I need to hold some amount of data is an error, not "lol you don't need any".

If my queue consumer can handle 0 concurrent tasks, it will take literally forever to finish, not finish instantly.

explains Lean's behavior. Basically, you use a goofy alternate definition of division (and sqrt, and more), and to compensate you have to assume (or prove based on assumptions) that the things you will divide by are never zero.

Hillel's pedantry is ill-taken, though, because he starts off with a false accusation that the headline tweet was insulting anyone.

Also, 1/0=0" is sound only if you change the field axiom.of division, which is fine, but quite rather hiding the ball. If you add " 1/0=0" as an axiom to the usual field axioms, you do get an unsound system.

When software engineers make mistakes dividing by 0 and end up with Exceptions being raised or NaNs being output, they'll usually blame themselves.

When the results are wrong numbers all over the place, they'll blame the language.

There are 2 cases when people are going to "use" x/0:

1. They made a mistake.

2. They KNOW that x/0 returns 0 and they take it as a shortcut for (y == 0 ? 0 : x/y)

Is that shortcut useful? No. Is it dangerous? Yes. Hence, this is a bad idea.

IMO, whether something like this makes sense is a separate matter. Personally I always just think of division in terms of multiplicative inverses, so I don't see how defining division by zero helps other than perhaps making implementation easier in a proof assistant. But I've seen people say that there are some cases where having a/0 = 0 works out nicely. I'm curious to know what these cases are, though.

You have a field (a set of "numbers"). Multiplication is defined over the field. You want to invent a notion of division. Let's introduce the notation "a/b" to refer to some member of a field such that "a/b" * b = a.

As Hillel points out, you can identify "a/b" with a*inverse(b), where "inverse" is the multiplicative inverse. And yes, there is no inverse(0). But really let's just stick with the previous definition: "a/b" * b = a.

Now consider "a/0". If "a/0" is in the field, then "a/0" * 0 = a. Let's consider the case where a != 0. Then we have "a/0" * 0 != 0. But this cannot be true if "a/0" is in the field, because for every x we have x * 0 = 0. Thus "a/0" is not in the field.

Consider "a/0" with a=0. Then "a/0" * 0 = 0. Any member of the field satisfies this equation, because for every x we have x * 0 = 0. So, "a/0" could be any member of the field. Our definition of division does not determine "0/0".

Whether you can assign "1/0" to a member of the field (such as 0) depends on how you define division.

And I think if you look at the Riemann sphere, the inverse of zero is the point where +infinity and -infinity meet. I would call that 0^(-1).

My gripe with arbitrary choices like this is that it pushes complexity from your proof's initial conditions ("we assume x != 0") into the body of your proof (every time you use division now you've split your proof into two cases). The former is a linear addition of complexity to a proof, whereas the latter can grow exponentially.

Of course, nothing is stopping you from using an initial condition anyway to avoid the case splitting, but if you were going to do that why mess with division in the first place?

Additionally, if inverses are defined as separate objects then what is 2 plus the inverse of 2? It doesn't simplify to 2.5 because there's no addition axiom for numbers and multiplicative inverses, or for that matter any rules for inverses with inverses. So you might have 1/2 and 5/10 but they're not equal and can't be multiplied together.

Without arbitrary precision numerics and functions which aren't explicit about corner cases it's always a simplification. However performance-/code-wise this is usually not feasible.

I tried once to investigate the implications, but it quickly became far more complex that with 'i' and never went far. Still intrigued if this is somewhat interesting or a total time loss though.

There is only one correct behavior for something named "int". Give the correct result or throw an error.

In combinatorics and discrete probability, `0**0 = 1` is a useful convention, to the point that some books define a new version of the operator - let's call it `***` - and define `a***b = a**b` except that `0***0 = 1` and then use the new operator instead of exponentiation everywhere. (To be clear, `**` is exponentiation, I could write `a^b` but that is already XOR in my mind.)

So one might as well overload the old one: tinyurl.com/zeropowerzero

This causes no problems unless you're trying to do real (or complex) analysis.

1/0 can cause a few more problems, but if you know you're doing something where it's safe, it's like putting the Rust `unsafe` keyword in front of your proof and so promising you know what you're doing.

Pff. The author wants to show off their knowledge of fields by defining a "division" operator where 1/0 = 0. Absolutely fine. I could define "addition" where 1 + 2 = 7. Totally fine.

What I can't do is write a programming language where I use the universally recognised "+" symbols for this operation, call it "addition" and claim that it's totally reasonable.

Under the standard definition of division implied by '/' it is mathematically wrong.

What they obviously should have done is use a different symbol, say `/!`. Obviously now they've done the classic thing and made the obvious choice unsafe and the safe choice unobvious (`/?`).

1 / 0 = 0 (2018) - https://news.ycombinator.com/item?id=42167875 - Nov 2024 (8 comments)

What is the best answer to divide by 0 - https://news.ycombinator.com/item?id=40210775 - April 2024 (3 comments)

1/0 = 0 - https://news.ycombinator.com/item?id=17736046 - Aug 2018 (570 comments)

If you actually write 1/0 in a manner that can be discovered through static analysis, that could just be a compile time error.

If you compute a zero, and then divide by it… I dunno. Probably what happened was the denominator rounded or truncated to zero. So, you actually have 1/(0+-e), for some type-dependent e. You have an interval which contains a ton of valid values, why pick the one very specific invalid value?

If so, how weirdly arbitrary that the additive zero is omitted for all multiplicative inverse definitions. (At least it seems to me). I always figured this was a consequence of our number systems, not of all fields.

It's a version of "you can't divide by zero, but you can multiply the divisor on both sides of the equation and then use 0*a=0."

If they ignore it, I do not care, it is the business problem anyway.

Worked for me for decades :)

I like that. I try to live by a similar protocol.

On topic: Each context has the right to establish their own rules.

If the rules work, the context survives. If not, then the context dies.

Ergo, x/x=1, so 0/0=1. You can use the same logic for x/0=any rational number.

Defining x/0=0 is impossibly arbitrary.

That is an intuition why division by zero is undefined.

Defining it arbitrarily is uninteresting.

Disapointing

0 ∈ (−∞, ∞)

Just because it’s formally consistent doesn’t mean it isn’t dumb.

Note that infinity would be a fine answer IF MATHEMATICS COULD BE CONSISTENTLY EXTENDED to define it to be so, but this cannot be done (see below). Note that using infinity does not "break" mathematics (as some have suggested below) otherwise mathematicians would not use infinity at all.

If we have an expression that is not a number, such as 1/0, you can sometimes consistently define it to be something, such as a number or positive infinity or negative infinity, IF THAT WOULD BE CONSISTENT with the rest of mathematics. Let's see an example of the standard means of getting a consistent definition of exponentiation starting with its definition on positive integers and extending eventually to a definition for on a much bigger set, the rationals (ratios of signed integers).

We define 2 ^ N (exponentiation, "two raised to the power of N") for N a positive integer to be 2 multiplied by itself N times. For example: 2 ^ 1 = 2; 2 ^ 2 = 4; 2 ^ 3 = 8.

Ok, what is 2 ^ N where N is a negative integer? Well we did not define it, so it is nothing. However there is a way to CONSISTENTLY EXTEND the definition to include negative exponents: just define it to preserve the algebraic properties of exponentiation.

For exponents we have: (2 ^ A) * (2 ^ B) ("two raised to the power of A times two raised to the power of B") = 2 ^ (A+B) ("two raised to the power of A plus B"). That is, when you multiply, the exponents add. You can spot check it: (2 ^ 2) * (2 ^ 3) = 4 * 8 = 32 = 2 ^ 5 = 2 ^ (2 + 3).

So we can EXTEND THE DEFINITION of exponentiation to define 2 ^ -N for positive integer N (so a negative integer exponent) to be something that would BE CONSISTENT WITH the algebraic property above as follows. Define 2 ^ -N ("two raised to the power of negative N") to be (1/2) ^ N ("one half raised to the power N"). Check: (2 ^ -1) * (2 ^ 2) = ((1/2) ^ 1) * (2 ^ 2) = 1/2 * 4 = 2 = 2 ^ 1 = 2 ^ (-1 + 2).

Ok, what is 2 ^ 0 ("two raised to the power of zero")? Again, we have not defined it, so it is nothing. However, again, we can CONSISTENTLY EXTEND the definition of exponentiation to give it a value. 2 ^ 0 = (2 ^ -1) * (2 ^ 1) = 1/2 * 2 = 1. This always works out no matter how you look at it. So we say 2 ^ 0 = 1.

I struggled with this for days when I was a kid, literally yelling in disbelief at my parents until the would run away from me. I mean 2 ^ 0 means multiplying 2 times itself 0 times, which means doing nothing, so I thought it should be 0. After 3 days I finally realized that doing nothing IN THE CONTEXT OF MULTIPLICATION is multiplying by ONE, not multiplying by zero, so 2 ^ 0 should be 1.

Ok, is there a way to CONSISTENTLY EXTEND the definition of exponentiation to include non-integer exponents? Yes, we can define 2 ^ X for X = P / Q, where P and Q are integers (a "rational number"), to be 2 ^ (P/Q) = (2 ^ P) * (2 ^ -Q). All the properties of exponentials work out.

Notice how we can keep EXTENDING the definition of exponentiation starting from positive integers, to integers, to rationals, as long as we do so CONSISTENT with the properties of the previous definition of exponentials. I will not do go into the details, but we can CONSISTENTLY EXTEND the definition of exponentiation to real numbers by taking limits. For example, we can have a consistent definition of 2 ^ pi ("two raised to the power of pi") by taking the limit of 2 ^ (P/Q) as P/Q approaches pi.

HOWEVER, IN CONTRAST to the above extension of the definition of exponentiation, there is NO SUCH SIMILAR CONSISTENT EXTENSION to division that allows us to define 1/0 as ANY NUMBER AT ALL, even if we allow extending to include positive infinity and negative infinity.

The limit of 1/x as x goes to zero FROM THE POSITIVE DIRECTION = positive infinity. Some example points of this sequence: 1/1 = 1; 1/0.5 = 2; 1/0.1 = 10; 1/0.01 = 100, etc. As you can see the limit is going to positive infinity.

However, the limit of 1/x as x goes to zero FROM THE NEGATIVE DIRECTION = NEGATIVE infinity. Some example points from this sequence: 1/-1 = -1; 1/-0.5 = -2; 1/-0.1 = -10; 1/-0.01 = -100, etc. As you can see the limit is going to NEGATIVE infinity.

Therefore, since positive infinity does not equal negative infinity, there is NO DEFINITION of 1/0 that is consistent with BOTH of these limits at the same time. The expression 1/0 is NOT A NUMBER, even if you include positive and negative infinity, and mathematics cannot be consistently extended to make it into a number. Q.E.D.

Crashing would have been preferable.

1/0 = 0 is unsuitable and dangerous for anyone doing anything in the real world.

The question is what definitions will be useful and what properties you gain or give up. Being a partial function is a perfectly acceptable trade-off for mathematics, but perhaps it makes it difficult to reason about programs in some cases.

I suppose the aim of the article is to point out the issue is not one of soundness, which is useful — but I wish more emphasis had been put on the fact that it doesn't solve the question of what 1/0 should do and produced arguments with regards to that.