Live data from Hacker News

1/0 = 0

hillelwayne.com

501–510 of 593 posts

Re: 1/0 = 0

#501
post #497

Earlier quoted context omitted.

You have a point, but I think this is a difference in the target markets. NASA can afford to have a thoroughly-tested, redundant, quickly-accessible failure path that restarts and reinitializes the process, and their processes are so thoroughly tested that they can expect their production instances not to have any software failures. Pony is made for a more typical scenario where every failure case is a new, untested…

It's not only NASA. Zero is just not a reasonable default value for an average. Imagine average credit card balance for FICO score, average blood pressure, average temperature in a freezer, etc. UB is not the only way. You can have NULLs (they come with their own sets of problems, but still). In many cases no value is better than incorrect value.

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.

Re: 1/0 = 0

#502
post #497

Earlier quoted context omitted.

It's not only NASA. Zero is just not a reasonable default value for an average. Imagine average credit card balance for FICO score, average blood pressure, average temperature in a freezer, etc. UB is not the only way. You can have NULLs (they come with their own sets of problems, but still). In many cases no value is better than incorrect value.

You can check for 0 and throw in those cases, and then propagate the error path appropriately. And as they've already said in this thread, they will be providing a checked arithmetic in the standard library to do that for you.

Well, sometimes the average is 0, e.g. (-2 + 2)/2.

And the whole point is that this is meant to catch unforeseen interactions as soon as possible. If you add a check it's no longer unforeseen, and it may easily slip the programmer's mind.

Re: 1/0 = 0

#503
post #126

Earlier quoted context omitted.

> the many pieces of code that assume that (x / y) * y equals x The same issue if division by zero throws an exception. This is simply a more practical approach that dispenses with the exception handling (ie becomes a less irregular test case). Edit: Not buggy behavior, when expected.

Assuming an exception is equivalent to any non-exceptional value doesn't break anything. See "Fast and Loose Reasoning is Morally Correct".

Holy moly that is not at all what that paper says! It specifically argues that certain equational properties of a given total language continue to hold in the total fragment of a given partial language. It is an embedding theorem combined with lifting properties, not a license to perform _any_ reasoning at all regarding the non-total portion of the language it considers!

Re: 1/0 = 0

#504

Earlier quoted context omitted.

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

Because a divisor cannot exist unless it is a multiplicative inverse. Therefore 0 is not a divisor.

This is getting to be Kafkaesque...it breaks the field axioms themselves. How many different explanations and external resources do I need to provide in this thread for you to be convinced that this is not a controversial point in modern mathematics? I just explained it in the comment you responded to.

You have exactly two options here.

If you define x/0, that definition must interact with the rest of the definitions and elements of the field. To maintain multiplicative closure (a field axiom!) there must be a unique y element equal to x/0. So tell me how you will define x/0 such that x is not equal to the product of 0 and y. Regardless of what you think the author has shown, the burden of proof is not on me at this point to show that you can't do it, because it follows directly from the field axioms. Trying to impose a one-off bizarro divisor function defined only on {0} is not only mathematically inelegant, it immediately eliminates the uniqueness of all field elements. Therefore your "field" just becomes {0}, and since it lacks a multiplicative identity it ceases to be a field. There is your contradiction. Why don't you tell me how you're going to prove any equation defined over a field that relies on the uniqueness or cancellation properties of fields?

On the other hand, let's say you tell me you want define x/0 so that the definition doesn't interact with any of the field definitions or elements. Then you haven't actually introduced any new operation or definition, you've just designed a notation that looks a lot like division but has no mathematical bearing on the field itself (i.e. absolutely nothing changes, including for 0). That's not a divisor function, it's just a confusing shorthand. You can't just add another axiom to a field and call it a field.

If you believe I'm stubborn, that's fine. I might be a poor teacher! There are ample resources online which will patiently explain this concept in mind numbing detail. It boggles my mind that there are people in this thread still fighting an idea in earnest which has been settled for over a century.

Re: 1/0 = 0

#505
post #497

Earlier quoted context omitted.

It's not only NASA. Zero is just not a reasonable default value for an average. Imagine average credit card balance for FICO score, average blood pressure, average temperature in a freezer, etc. UB is not the only way. You can have NULLs (they come with their own sets of problems, but still). In many cases no value is better than incorrect value.

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 pressure and shocks the patient when his heart stops (blood pressure drops to zero). We attach the defibrillator to a patient, turn it on, and it shocks the patient immediately because there are no blood pressure measurements yet and therefore it thinks the average is zero.

Third example, a thermostat that turns on the freezer if average temperature is above a set threshold. It never turns on because average (of zero observations) is already zero.

Of course you can hard-code handling of those special cases, but if you did not, failing would be preferable to continuing to work incorrectly.

Re: 1/0 = 0

#506

Earlier quoted context omitted.

The Pony devs did chime in and mentioned that they do define division by zero to be NaN (or positive infinity) where the underlying type supports it (e.g. IEEE 754 floats). Most integer representations have no space for such a value, so the only choices available to language developers are: 1. Throw an exception or otherwise consider it an error 2. Define the result to be 0 or 1 or some other integer value (0 being t…

> 0 being the only good choice Devil's advocate: why not a maximum integer like 18446744073709551615 or 9223372036854775807? 0 looks like a valid number, while 18446744073709551615 is an obvious NaN for any programmer looking at the output.

Pony core team member here.

In some domains it might be. In others it might not. It's no more right or wrong in my mind.

I think the size of the integer needs to be considered in your thinking as well:

If you have unsigned 8 bit integers, the max value is 255, is that really going seem NaN? How about 127 for a signed 8 bit integer?

And, should the result of division by zero vary based on the bit size of the integer? That's a discussion unto itself.

Re: 1/0 = 0

#507

Any division either works and returns a result, or doesn't work and doesn't return a result. This is similar to any other function that maybe returns a result (returns an Option /Maybe or even Result ). Perhaps it's not a good design to have division as an operator a programming language? Just like Maybe i = ParseInt("foo") one should also do this for division: Maybe q = Div(n, d) Is there any language that does this…

That's interesting. In my career, I've rarely encounted division by zero. I've encountered over and underflow considerably more. Different experiences, different points of view.

Re: 1/0 = 0

#508

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

Why infinity rather than negative infinity? Is 1/0 = 1/(-0)?

Re: 1/0 = 0

#509

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…

Consider the following two functions, that we can define for any field F:

• Our first function f(x, y) is defined for all x in F, and all nonzero y in F. That is, the domain of this function f is (F × F\{0}). The definition of this function f is:

f(x, y) = x times the multiplicative inverse of y

(Note that in the definition of f(x,y) we could say "if y≠0", but whether we say it or not the meaning is the same, because the domain of f already requires that y≠0.)

• Our second function g(x, y) is defined for all x in F, and all y in F. That is, the domain of this function g is (F × F). To define this function g, we pick a constant C in F, say C=0 or C=1 (or any C∈F, e.g. C=17 if 17 is an element of our field). And having picked C, the definition of this function g is:

• g(x, y) = x times the multiplicative inverse of y, if y ≠ 0, and C otherwise [that is, g(x, 0) = C].

Note that this function is defined for all (x, y) in F×F, and when y≠0 it agrees with f, i.e. g(x,y) = f(x,y) when y≠0.

Would you agree that both of these are functions, on different domains?

Next, we have the notation x/y. To assign meaning to this notation (and to the word “division”), there are two conventions we could adopt:

• Convention 1: When we say "x/y", we will mean f(x,y) (as defined above) — that is, x * y^{-1}.

• Convention 2: When we say "x/y", we will mean g(x,y) (as defined above).

The point of the post is that we can well adopt Convention 2: with such a definition of "division", all the properties that were true of f (on the domain F×F\{0}) continue to be true of g, except that g is defined on a wider domain.

----------------------------------------------

Now, maybe Convention 2 offends you. Maybe you think there is something very sacred about Convention 1. In all your posts in this thread, you seem to be insisting that "division" or "/" necessarily have to mean Convention 1, and the provided justification for preferring Convention 1 seems circular to me — here are some of your relevant comments, with my comments in [square brackets]:

> Since there is no multiplicative inverse of 0, division by 0 is undefined behavior [This seems to be saying: Because of Convention 1, we cannot adopt Convention 2.]

> Since y = x/0, it follows that the product of y and 0 is equal to x, because division is the inverse of multiplication [Here, your reasoning is "because we adopt Convention 1"]

> in algebraic fields division by x is equivalent to multiplication by 1/x. This is precisely why you cannot have a field that admits division by 0: because 0 has no multiplicative inverse. [Again, you're stating that Convention 1 has to hold, by fiat.]

> If F is a field with elements x, y, then the quotient x/y is equivalent to the product x(1/y). If 0 has no multiplicative inverse, there is no division by 0. The two concepts are one and the same [This is just stating repeatedly that we have to adopt Convention 1.]

> A multiplicative inverse is a division. [This is merely insisting that Convention 1 has to be adopted, not Convention 2]

> divisor cannot exist unless it is a multiplicative inverse [Again, stating Convention 1.]

> 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. [Why not?] ...you've introduced a division rule which is just a syntactical sugar [yes the same is true of Convention 1; what's the problem?]

All these comments, which emphatically insist on Convention 1, seem to ignore the point of the article, which is that Convention 2 has no more mathematical problems than Convention 1, because the function g is no less a “valid” function than the function f.

In mathematics when we use words like “obvious” or insist that something is true because it just has to be true, that's usually a hint that we may need to step back and consider whether what we're saying is really mathematically justified. What we have here is a case of multiple valid definitions that we can adopt, and there's no mathematical reason for not adopting one over the other. (There's a non-mathematical reason, namely “it breaks convention”, but the entire point is that we can break this convention.)

Re: 1/0 = 0

#510

This item reminded me of how I've owned a couple different German cars with a fuel consumption meter that showed minimum consumption (or maximum mpg) when the car was idling. It seems like they must indeed have defined (fuel used ÷ distance traveled) as zero when the distance is zero. Which is annoying and grossly wrong in my opinion. For some reason, Japanese cars seem to do it correctly. It may be true that 1/0=0 c…

I don’t think 1/0 = infinity is a good choice either, since -1/0 = 1/(-1 * 0) = 1/0, so we would have infinity being equal to negative infinity, which is assumedly not a practical choice. 1/0 = 0 is actually more symmetric in this regard.
Post reply on HN