Live data from Hacker News

1/0 = 0

hillelwayne.com

531–540 of 593 posts

Re: 1/0 = 0

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

What do you expect for that C code?

In the context of this discussion, the idea was that it would act the same way as Python. But it obviously doesn't.

Re: 1/0 = 0

#532

Earlier quoted context omitted.

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

The fact that it's a shorthand means that it's not in the definition, just a convention. In fact, nowhere in my studies I saw anyone using 'division' when working explicitly with fields in algebra, it's always multiplicative inverse.

By the way, you cannot do the addition like normal on that series, you don't end up at anything. You can say it diverges and its limit is +infinity (not aleph0, aleph0 is used for cardinality of sets so I think no one would use it as the result of a divergent series). When I said it 'broke math' what I meant was that, in the same way that OP did, it is a way to assign values to things that usually don't have one. I know it does not actually break math.

Re: 1/0 = 0

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

[deleted]

Re: 1/0 = 0

#534

Earlier quoted context omitted.

If we assume that we got to 0 because of a rounding error we do know that it should be some positive integer. I think that 1/0 = infinity is a reasonable substitute for an actual value. 1/0 = 0 seems absurd. 1/(a number approaching 0) produces ever increasing integers. I don't know, does it even matter? What happens when you try to divide a physical object into 0 parts? It doesn't create infinite pieces. It doesn't m…

Actually if your embedded system will stop keeping a patient alive if you crash and the zero value doesn't cause any harm then you don't crash. There are lots of situations where it makes sense to keep computing even if you suspect the input data is wrong. It's not really good practice to always be crashing. You need to decide how to handle the bad input on a case-by-case basis.

I think "crash" in these discussions generally refers to "abort the current action and return to a safe state".

Re: 1/0 = 0

#535

Earlier quoted context omitted.

An issue with D that has repeatedly engendered heated debate is what should happen when a programming bug is detected at runtime. The two camps are: 1. The program should "soldier on" if it can. 2. The program should go immediately to jail, it must not pass Go, and must not collect $200. I'm solidly in the latter camp. If a program has entered a state unanticipated by the programmer, then there is no way to know how…

Great analysis! I think that summarizes a lot of dev arguments. That said, Erlang appears to agree with both camps. If an error occurs, the _process_ immediately crashes (not OS process, it's Erlang Kingo for an actor or a green thread), but the _program_ soldiers on as if nothing happened. The idea behind the design, I believe, is that programmer errors are unavoidable, but that eg a bug in some edge case triggered…

It's not just programmer error, it can soldier on through some hardware errors, rogue cosmic rays, and arguably the hardest - other people's software errors, like os errors, driver errors, library errors, network stack errors...

Re: 1/0 = 0

#536
post #424

Earlier quoted context omitted.

> What exactly are you looking for me to say here? Very simple. Here is a theory of a field in FOL: ∀ x . x + 0 = x ∀ x . ∃ -x . x + (-x) = 0 ∀ x, y . x + y = y + x ∀ x, y, z . (x + y) + z = x + (y + z) ∀ x, y . x – y = x + (-y) ∀ x . 1x = x ∀ x . x ≠ 0 ⇒ ∃ x⁻¹ . xx⁻¹ = 1 ∀ x, y . xy = yx ∀ x, y, z . (xy)z = x(yz) ∀ x, y . y ≠ 0 ⇒ x/y = xy⁻¹ ∀ x, y, z . x(y + z) = xy + xz Do you claim that this formalization is unacc…

In the definition of a field ∀ x . x/0 = undefined, not 0 or any other value you might prefer. A field is exactly defined by the field axioms: adding or removing any other axiom makes it no longer a field.

> A field is exactly defined by the field axioms: adding or removing any other axiom makes it no longer a field.

This is clearly not true. Adding axioms (as long as they don't introduce consistency) can only reduce the set of models. Anything that satisfies the larger theory also satisfies the smaller theory. This is exactly why a group is a monoid is a semigroup. This is why fields are rings. In fact, this is why the rationals or the reals are fields: they satisfy the field axioms, and more (for example, they are ordered).

> In the definition of a field ∀ x . x/0 = undefined, not 0 or any other value you might prefer.

What is "undefined"? First let's look at the logic itself: What is true ∨ undefined ? What is true ∧ undefined? Now at the theory: What is undefined + x ? What is 0 * undefined ? What is 0 = undefined ? etc.[0]

While it is possible to formally define this magic non-value (sometimes written as ⊥ in the logics that contain it) as is done in some programming languages (and it has been done), this would entail adding quite a few more axioms to FOL and to the theory of fields. When people say FOL, they mean a particular language[1], one that is considered by mathematicians to be sufficient to formalize all of mathematics and has very particular syntax and semantics. FOL + undefined is a very different language, which much more complicated semantics. If you think that when people refer to FOL they refer to FOL + undefined, I challenge you to find any mention of it in descriptions of standard FOL. Similarly, if you think that by common theories, say fields or sets, people really mean field + undefined or ZFC + undefined (what is {undefined}? What is undefined ∈ {undefined}? etc.), I challenge you to find any mention of the complex axioms required in treatments of these common theories.

But it's not just a matter of convention. The reason you won't find it in the standard logics/theories is that it's completely unnecessary. If you work it out, you'll find that the theory of fields I provided and the more complicated one involving undefined that you suggest is the common formalization are the very same theory, in the sense that they yield exactly the same theorems, except for those specifically involving undefined (i.e., your theory has more theorems than mine). You'll find that you cannot find a "bad" theorem that you can prove with the simple theory but cannot with the one involving undefined, and therefore it is unhelpful except for the purpose of satisfying a certain desire for intuition that requires significantly complicating the formal system.[2]

There's a paper by Sol Feferman[3] reviewing formal systems with explicit handling of "undefined." AFAIK, they are rarely if ever used. Such semantics are certainly not part of the trusty-old FOL, considered the default language of formal mathematics.

[0]: BTW, if you think that the meaning of every expression involving undefined is undefined, then you'll see that this doesn't work. For example, you have: x=0 ⇒ x(1/x)=1. This is a valid formula, and so it's true even when x=0, but then you have undefined on the right-hand side, so you want at least false ⇒ undefined to be equal to true. But A ⇒ B = ¬A ∨ B, which means you want at least true ∨ undefined = true. Similarly, you'll want at least 0 = undefined to be false etc.

[1]: https://en.wikipedia.org/wiki/First-order_logic

[2]: E.g., while in your theory you will be able to prove the rather useless theorem 1/0 ≠ 0, in my theory you will not be able to prove 1/0 = x for any x, so it really poses no issue.

[3]: https://math.stanford.edu/~feferman/papers/definedness.pdf

Re: 1/0 = 0

#537
post #505

Earlier quoted context omitted.

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

There are many different credit scores. The range of valid FICO scores does not include zero, but internal acquisition and behavior scores that banks use might.

But in this case it's irrelevant because average balance is independent variable (input of the scoring model).

Re: 1/0 = 0

#538

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.

> Having 1/0 = +inf is a perfect solution.

It makes sense if we have signed zeros; then +0 represents an infinitesimal positive value. IEEE 754 has signed zeros, though the signs may sometimes not match programmers' expectations, e.g. 1 - 1e-50 - 1 == +0.

Maybe 1/+0 == +inf is reasonable, but would you agree that there's no reasonable answer for 0/0? So IMO, reasonable languages must define division as a partial function, or a function that can throw an error (or return NaN, Nothing, etc).

And if division is a partial function anyway, it seems best to not allow division by zero at all, since even 1/+0 == +inf can have unexpected consequences.

Re: 1/0 = 0

#539

Earlier quoted context omitted.

Great analysis! I think that summarizes a lot of dev arguments. That said, Erlang appears to agree with both camps. If an error occurs, the _process_ immediately crashes (not OS process, it's Erlang Kingo for an actor or a green thread), but the _program_ soldiers on as if nothing happened. The idea behind the design, I believe, is that programmer errors are unavoidable, but that eg a bug in some edge case triggered…

Java has essentially the same behavior with threads. If an error occurs in a thread, it will throw an exception that will terminate the thread if uncaught. Other threads are not directly affected. This is typically what you want as threads are usually independent of each other, often processing an isolated request, which may encounter a bug due to bad data or other conditions. Contrast this to languages like C++, whe…

In C++ the default behaviour is for the runtime to call std::terminate, not segfault. It's easy to catch exceptions by wrapping the callable in a packaged_task and then the exception is available in the future. The key point is that the exception is rethrown when accessing the result through the future.

Swallowing exceptions is a really poor idea. Does Java really do that?

Re: 1/0 = 0

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

It seems to me taking averages would be inappropriate in all three of those scenarios.

Credit risk is based on total debt, and since credit cards are a revolving line of credit, the entire credit limit is considered debt, even if the balance is zero. That's why you can improve your credit score by closing out a credit card that you never use and that carries a zero balance (which we did in order to qualify for a mortgage several years ago). In other words, it's a sum, not an average; there's no division involved.

Setting aside the fact that there are much more reliable ways to detect a stopped heart than blood pressure: If you're taking a running average of BP over time, a low reading after a heart attack would just be a single data point, and you'd probably have to accumulate a bunch of them in order for it to register (particularly if you got a high reading just before the event). Even if you take a reading every five minutes, which is ridiculously frequent for BP, the patient will be long dead by the time you notice. You should be acting based on the last reading; again, no division involved.

I don't see why a freezer would be based on running averages rather than the most recent reading either. Thermostats generally work off of two thresholds: a higher one above which the compressor turns on, and a lower one below which it turns off. That smooths out any measurement noise without taking averages. Even if you do use averages for some reason, though, presumably it will start measuring at _some_ point and the compressor will turn on; I don't see why the average would stay at zero.

I'm not convinced that `1/0 = 0` is correct in any meaningful way, but I feel like any situation where it would cause bugs more critical than a UI issue probably points to a deeper design flaw. After all, if the alternative is to crash on a failed assertion, that's not necessarily preferable in a life-or-death situation.

Post reply on HN