Live data from Hacker News

1/0 = 0

hillelwayne.com

481–490 of 593 posts

Re: 1/0 = 0

#481
post #346
post #342

Earlier quoted context omitted.

This is valid C and C++.

It is, but it will always give you a divisor of 1 (because "true" is 1 -- I also thought it would work until I tested it): % cat >division.c int main(void) { printf("1/0 = %d\n", 1 / (0 || 1)); printf("1/2 = %d\n", 1 / (2 || 1)); printf("1.0/0 = %f\n", 1.0 / (0 || 1)); printf("1.0/2 = %f\n", 1.0 / (2 || 1)); } % gcc -Wall -o divison divison.c % ./divison 1/0 = 1 1/2 = 1 1.0/0 = 1.000000 1.0/2 = 1.000000 In Python thi…

Some trivia: GNU extensions to C/C++ include a "?:" operator that does what you'd want in this case, e.g.

    x / (divisor ?: 1)

Re: 1/0 = 0

#482
post #346

Earlier quoted context omitted.

It is, but it will always give you a divisor of 1 (because "true" is 1 -- I also thought it would work until I tested it): % cat >division.c int main(void) { printf("1/0 = %d\n", 1 / (0 || 1)); printf("1/2 = %d\n", 1 / (2 || 1)); printf("1.0/0 = %f\n", 1.0 / (0 || 1)); printf("1.0/2 = %f\n", 1.0 / (2 || 1)); } % gcc -Wall -o divison divison.c % ./divison 1/0 = 1 1/2 = 1 1.0/0 = 1.000000 1.0/2 = 1.000000 In Python thi…

It shouldn't be valid in C++. booleans cannot participate in arithmetic operations. You will get a warning from the compiler if you are lucky. C doesn't have booleans and treat them as integers 0 or 1, it can do the math and will always return 1.

That's not true. C++ does define an implicit conversion from bool to int:

https://en.cppreference.com/w/cpp/language/implicit_conversi... (under "Integral promotion")

And C has a boolean type as of C99.

Re: 1/0 = 0

#483
> These things are conventions, exactly the same as announcing that x^-n = 1/x^n and that x^0 = 0.

The convention that x^0 = 1 (including 0^0 = 1) is genuinely useful because it removes a case distinction from lots of combinatorial formulas. Hence this: http://tinyurl.com/zeropowerzero

x^0 = 0 seems to me to be - I won't say "wrong" because you're free to define things the way you like - in general less useful than x^0 = 1.

For similar reasons, (0 * log 0) = 0 makes sense when computing entropies and stuff in certain machine learning applications. This one can also be justified as the limit of x * log(x) as x -> 0 is 0, but I've seen at least one person just trying to define "log 0 = 0" which I consider less elegant; in the kind of application where this convention is useful, you'll rarely if ever see a log 0 that's not multiplied by a plain 0.

Where it gets really weird is when you do KL divergence and can end up with 0 * log (0/0), but again you can save a case distinction by just declaring this to be 0. The elegant way to do this is to define d(p, q) = p * log(p/q) when p, q != 0 and 0 otherwise. In this particular application, just going with 1/0 = 0 seems to work fine in practice as in a term q * log(q/0) you can rewrite the whole thing by flipping the sign to get 0 * log(0/q) in that term, which we have already declared to be 0 (whether or not q is 0 itself).

In this case it's not a bug in the code, it's being able to handle probability distributions with mass 0 on some points at the level of arithmetic rather than as a special case in the formula.

Re: 1/0 = 0

#484

Earlier quoted context omitted.

I have to disagree -- this isn't sleight of hand. The standard definition isn't being violated here, because standard division isn't a total function. The denominator's domain in Hillel's function is a proper superset of the standard domain: when restricted to the standard domain, the two functions are precisely equivalent. Therefore, every standard identity still holds under Hillel. The hole that he is filling here…

> If something is explicitly undefined, there's nothing mathematically wrong with defining it, as long as the definition doesn't lead to inconsistency. The definition does lead to inconsistency...you can't look at the field axioms, observe that 0 has no multiplicative inverse, then proceed to define a special, one-off division rule that doesn't involve multiplicative inverses for that one element. Either your divisio…

> Onlookers reading these comments probably think those of us harping on this point are anal pedants with a mathematical stick up our ass. But this thread is increasingly illustrating my central point, which is that the author shouldn't have tried to justify numerical operation definitions in a programming language using field axioms of all things.

You can't use your own stubbornness to justify itself.

I'm waiting for you to justify your claim that this extension to division breaks any of the field axioms. pron even made you a nice list of them.

Just name one equation/theorem that the new axiom would break.

I'm completely open to being convinced! But so far you've only given arguments about giving a multiplicative inverse to zero. Everyone agrees on that. It's the wrong argument.

Re: 1/0 = 0

#486

Earlier quoted context omitted.

I think OP means that nothing breaks mathematically. It is not inconsistent and not false, so you can work with it. The only issue is to deal specially with the case of division by zero, which you have to do anyways. Code that assumes that (x/y) * y = x is wrong if you don't check for y = 0, independently of what you define x/0 to be.

You do realize that division is the inverse operation of multiplication, right? Like subtraction is the inverse of addition. By defining addition we define subtraction. By defining multiplication we define division. This is where the author fails. Division is multiplication of a fractional value. This is VERY important. And just because it is mathematically a field does not mean it is particularly the right choice. A…

The usual definition of division is the multiplicative inverse, yes. But that does not mean that, as an intellectual curiosity (which is how I take this post) you can't define "division" as having other value. Sometimes that's useful, sometimes it's not. Most of the time it is fun to see how things break and don't break. For example, the infamous 1+2+3+... = -1/12 sum[1]: for most purposes it's a divergent sum but you can find ways to assign a finite value and make that useful.

1: https://en.wikipedia.org/wiki/1_%2B_2_%2B_3_%2B_4_%2B_%E2%8B...

Re: 1/0 = 0

#487
So I believe in this article the equation:

y = 1/x

will result in 2 nice asymptotes with a dot in the middle (0,0)

1/0 = 0 doesn't make sense to me, even because lim x->0+ 1/x is infinite and lim x->0- 1/x is -infinite

so the value that makes more sense for 1/0 is infinite

Re: 1/0 = 0

#488
post #413

Earlier quoted context omitted.

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.

What is the sign of 0? It's 0.

Or as IEEE 754 sees it (you can try this in your JavaScript REPL).

  >> 1 / 0
  Infinity
  >> 1 / -0
  -Infinity

Re: 1/0 = 0

#489
Well, it's a design choice that you can make for rational numbers and the restricted rationals with error values that we typically use in computer arithmetic. There's nothing wrong with it and as the article points out, even most proof assistants use this definition for rational division.

For real numbers though, division by zero will always diverge or be undefined, no matter how you represent them. All computations on real numbers are continuous and there is no continuous extension of division which includes 0 in the domain of the denominator.

One can get around this by switching to projective reals (essentially reals extended with a new element that's both +infinity and -infinity). This is no longer totally ordered and has some other problems, but it's actually a great choice for a lot of numerical computations. Yet, I've never seen something like this implemented in hardware, aside from John Gustafson's unum concept.

Re: 1/0 = 0

#490
post #72

My 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…

My comment from when this came up on Reddit, slightly edited for context: `/`-by-0 is just an operation and it tautologically has the semantics assigned to it. The question is whether the specific behaviour will cause bugs, and on glance that doesn't sound like it would be the case. Principally, division is normally (best guess) used in cases where the divisor obviously cannot be zero; cases like division by constant…

> `average = 0` with no elements

Imagine a Mars lander program that looks at the average of altitude measurements to decide when it's ok to jettison the parachute, sees no measurements, and decides that altitude is zero.

Post reply on HN