Live data from Hacker News

1/0 = 0

hillelwayne.com

511–520 of 593 posts

Re: 1/0 = 0

#511
post #505

Earlier quoted context omitted.

It's a value type, so you can't really have NULL. I don't see the issue with those examples; if you have no samples, there's nothing to mislabel. An average blood pressure of 0 across 0 patients is only going to harm 0 patients.

> I don't see the issue with those examples Let me elaborate then. Average credit card balance predicts probability of default. Joe who maxed out his credit card is higher risk than Jane who pays back her entire credit card balance every month. Now we have Jack with no credit card. We predict that Jack is low risk because his average credit card balance is zero. Second example, defibrillator that monitors blood press…

https://en.m.wikipedia.org/wiki/Credit_score_in_the_United_S...

Credit scores don't work this way. Zero is not a valid credit score, and the things you mentioned describe different components of the score.

I work a lot with survey data, to be interpreted by humans. In this problem domain, zero is a sane value for an empty average, though "N/A" is usually better. I wish our language would let us define it as zero so long reports don't die in the middle. But it's about your problem domain, as usual.

Re: 1/0 = 0

#512
I don’t really understand the main argument given in the article; since zero has no multiplicative inverse, you can’t prove anything involving a division by zero. (So why talk about field axioms?)

However, to extend an operation usefully to a larger set of numbers, we can isolate some properties that we want to keep, for example:

1. Division is linear in the first argument: (ab + c)/x = a(b/x) + c/x, for all a,b,c,x.

2. If x has a multiplicative inverse, then x * (1/x) = 1.

3. Taking reciprocals twice gets back to the original number: 1/(1/x) = x for all x.

The choice 1/x = 0 is consistent with all the above, and so probably still “useful”. What properties do you want out of a division function?

Re: 1/0 = 0

#513
But what does it give you? I may not like PHP's definition of "5uper" + 3 as 8, but at least I can see an advantage to it, a use for it. What would you do with that zero quotient, any examples? And I mean examples where you haven't checked the value of the divisor (otherwise what's the point). I appreciate spooneybarger's input as a core developer of Pony, because he lets us know this was a difficult decision, and frames the definition squarely in the context of the language.

On the other hand, the author of the article seems to push for a general, mathematical definition of 1/0 as 0. First of all, good luck with that, as there is no standards-issuing body in mathematics. And whether the author likes it or manages to overturn a very long tradition, division is defined when we grow up as multiplying by the multiplicative inverse, with some occasional notes like "Division by zero is undefined for the real numbers and most other contexts [1] or "In general, division by zero is not defined [2], pointing to settings where clearly you won't find consensus.

I refer to when we grow up because we should not forget the intuitive definition Wikipedia gives first and, I guess understandably, MathWorld gives last: "separating an object into two or more parts". As we know, this restriction of two parts can (more and then less) intuitively be loosened to one, negative numbers, rational numbers, real numbers, etc., but only arbitrarily for zero. But then again, even if we unanimously agreed on one value, what does it give you?

[1] https://en.wikipedia.org/wiki/Division_(mathematics)

[2] http://mathworld.wolfram.com/Division.html

Re: 1/0 = 0

#514

Earlier quoted context omitted.

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…

> Division is multiplication of a fractional value Thus, division by 0 is multiplying by (1/0). Does such a fraction exist? It can go along two potentially different paths depending on the limit we take. Alternatively, there is information lost when you multiply something by 0: a x 0 = 0, b x 0 = 0. When you perform an inverse by dividing, will you get back a or b (or any number)? Thus, it is not invertible at least…

>Alternatively, there is information lost when you multiply something by 0: a x 0 = 0, b x 0 = 0. When you perform an inverse by dividing, will you get back a or b (or any number)? Thus, it is not invertible at least at 0.

>>A field is not strictly definitely by addition and multiplication, it is definitely by two operators where one is an abelian group (addition in our case) and the other forms and abelian group over the non identity term of the first (eg multiplication is an abelian group over non zero terms).

Re: 1/0 = 0

#515
This is very bad for numerical code. When you divide by almost zero you get a big number. If it becomes a zero it should be even bigger number. Having 1/0 = +inf is a perfect solution. Setting it to 0 breaks continuity and isn't useful at all.

One of those proposals which can only be made when you don't take time to understand and appreciate use cases the current solution was created for.

Re: 1/0 = 0

#517
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…

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

Wait, when creating a progress Duke you divide in other direction: (things already done) / (all things). Can you give a specific example when it causes problems? My experience of writing code like that is that there a clearer way or I made a mistake somewhere.

Re: 1/0 = 0

#518
post #447

Hi, I'm on the Pony core team. I will be writing in more detail about this decision. A few short notes until then: 1) no one on the team has ever been happy with ending up here, understanding why the decision was made involved understand how partial functions (one that can produce errors like division by zero) are handled in Pony and interesting ergonomic issues that can result that is a large part of what my post wi…

As an aside, I have thought recently that integers should also have NaN value, just like floating point values have. It's useful in statistics to differentiate between not having a value and value of 0. And I was thinking that perhaps 0x80000000 (in two's complement arithmetic) would be a good value for integer NaN. This value is already fixed point with respect to negation, so why not make it into an exception on it…

I like the idea of having integer NaN but I think unsigned numbers are problematic as there isn't any convenient way to encode it.

Re: 1/0 = 0

#519
post #463

Earlier quoted context omitted.

An example well-defined use case is if you want to compute a harmonic mean, e.g. x = 2/(1/a +1/b) This is a form of average where you are giving increased importance to the smaller number. It frequently pops up in science/engineering, e.g. in hydrology when you are computing flow of water underground. In this case, it's "obvious" that when e.g. a is zero, you want 1/a to be zero so you simply return b. There's typica…

"In this case, it's "obvious" that when e.g. a is zero, you want 1/a to be zero so you simply return b" b obviously isn't what you want from this harmonic mean when a is 0. And in any case x will be 2b if 1/a is 0, not b.

So, I did forget the correction such that you don't get 2b. The general case is described e.g. in the link below, and this is known as a "zero-corrected harmonic mean". It is actually "obvious" in some cases, but I'll concede that in other cases it's not.

https://www.rdocumentation.org/packages/lmomco/versions/2.3....

Re: 1/0 = 0

#520

Earlier quoted context omitted.

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

The OP says

> The field definition does not include division, nor do our definitions of addition or multiplication.

This is clearly a misunderstanding of not realizing that the definition of division is a symbolic shorthand for inverse multiplication.

Sure, you're right that we can define it another way. But I don't know what we would call an object with three operators. (Someone more knowledgeable in field theory please let me know, it's hard to Google) in the normal field we work with (standard addition and multiplication) we only have two unique operators. Everything else is a shorthand. In fact, even multiplication is a shorthand.

>For example, the infamous 1+2+3... = -1/12

Ramanujan Summation isn't really standard addition though. It is a trick. Because if you just did the addition like normal you would never end up at -1/12, you end up at infinite (aleph 0, a countable infinity). But the Ramanujan Summation is still useful. It just isn't "breaking math" in the way I think you think it is.

But I encourage you to try to break math. It's a lot of fun. But there's a lot to learn and unfortunately it's confusing. But that's the challenge :)

Post reply on HN