1/0 = 0 • Hacker News Board

Re: 1/0 = 0

#521

Post by jejones3141 » Sat, Aug 11, 2018, 2:15 PM UTC

rzwitserloot wrote: post #491

whack wrote: 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…

The authors covers this at the end: [1] The author has a dislike of the notion that 1/0 = 0 in a programming language. The author identifies this as a personal preference; I'm sure that preference is based on falsiable notions, but the author doesn't elaborate. The author _DOES_ elaborate their motivation for writing the post: The post debunks the notion that 1/0 = 0 is 'bad math'. [2] Pony chose 1/0 = 0 because the…

Does Pony have some analogous dodge for logarithms and square roots of reals, or for the gamma function?

Re: 1/0 = 0

#522

Post by lomnakkus » Sat, Aug 11, 2018, 2:18 PM UTC

innocentoldguy wrote: post #442

electrum wrote: post #429

Earlier quoted context omitted.

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…

One big difference between Erlang and Java is that all processes (threads) in Erlang are safely contained in private memory, whereas in Java threads occur in public memory. Another big difference is that Erlang has supervisor processes to restart child processes that have crashed. Java just farts itself.

Indeed. Java is in fact a sort of worst-of-all-worlds in that it's even possible to catch things that are really unrecoverable errors like StackOverflowException or OutOfMemoryError. To to uninitiated it might not like appear that catching these is that bad, right? In addition to the problems with finally clauses not necessarily running to completion under such circumstances catching these exceptions can cause extremely hard-to-debug deadlocks because object locks won't be released properly.

This is an area where the design of Java/JVM is badly screwed up.

[1] JVM, really. It's pretty unavoidable on most (all?) JVM languages.

Re: 1/0 = 0

#523

Post by throwawaymath » Sat, Aug 11, 2018, 2:22 PM UTC

svat wrote: post #509

throwawaymath wrote: post #417

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…

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…

I follow everything you're saying. As I have said many times already, I have no problem with convention 2. But don't use field theory to justify convention 2, because it's mathematically incoherent and unnecessary. I broadly agree - there is no reason to be involving field theory in programming language design.

I don't take issue with division by 0 - you can do that in mathematics just fine! I take issue with defining that division and calling the consequent system a field when it's not a field, and acting as though everyone else is wrong. The author invited this criticism when they loaded in the full formalism of field theory without needing to.

If the author had just stated they wanted to define division by zero that wouldn't be a problem. I have no idea why they felt the need to pull in abstract mathematics. I'm not disagreeing with their point, I'm taking issue with the strange and incorrect way they defended it.

Note that in my top level comment I specifically said, "Mathematics does not give us truths, it gives us consequences." I will happily agree with you that there is usefulness and coherence in a definition of 0. There is no canonical truth about the world regarding that matter. But a direct consequence of defining any division by 0 is that you cease to have an algebraic field.

Therefore, using field theory to defend a system which defines division by 0 doesn't make sense. It's not that the system is "wrong" for some meaning of wrongness. It's that you shouldn't be trying to pigeonhole field theory to make it work, because you don't need to.

Re: 1/0 = 0

#524

Post by jschwartzi » Sat, Aug 11, 2018, 2:23 PM UTC

optimuspaul wrote: post #247

behringer wrote: post #225

Earlier quoted context omitted.

1/0 is not infinity either...

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.

Re: 1/0 = 0

#525

Post by FrozenVoid » Sat, Aug 11, 2018, 2:32 PM UTC

A trick to ensure you don't divide by zero in C with minimal overhead(that converts zeros to 1) x/(y+(y==0))

Re: 1/0 = 0

#526

Post by svat » Sat, Aug 11, 2018, 2:44 PM UTC

throwawaymath wrote: post #523

svat wrote: post #509

Earlier quoted context omitted.

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…

I follow everything you're saying. As I have said many times already, I have no problem with convention 2. But don't use field theory to justify convention 2, because it's mathematically incoherent and unnecessary. I broadly agree - there is no reason to be involving field theory in programming language design. I don't take issue with division by 0 - you can do that in mathematics just fine! I take issue with definin…

Glad you follow! But I'm not sure we agree yet, as there's still something puzzling when you say:

> But don't use field theory to justify convention 2, because it's mathematically incoherent

> defining that division and calling the consequent system a field when it's not a field

> a direct consequence of defining any division by 0 is that you cease to have an algebraic field

If you go back to my comment (the one you're replying to), both the functions f and g assume a field F, and they are well-defined functions on F×F\{0} and on F×F respectively. (Do you agree?) For example, F may be the field of real numbers. Forget about the word “division” for a moment: do you think there is something about the function g, that makes F not a field?

To put it differently: I agree with you that it is a direct consequence of defining a multiplicative inverse of 0 that you cease to have an algebraic field. But the only way this statement carries over when we use the word “division”, is if we already adopt Convention 1 (that “division” means the same as “multiplicative inverse”).

Again, I think you are implicitly adopting Convention 1: you're saying something like “if we adopt Convention 2, then x/y means the function g and includes the case when y=0, but [something about multiplicative inverses, implicitly invoking Convention 1], therefore there's a problem". But there's no problem!

It is not a direct consequence of defining the function g(x,y) that something ceases to be a field: it is a consequence only if you also insist on Convention 1, namely if you try to assign a multiplicative inverse to 0 (which everyone here agrees is impossible).

Let me emphasize: whether we adopt Convention 1 or Convention 2, there is no problem; we still have the same field F.

Re: 1/0 = 0

#527

Post by Boulth » Sat, Aug 11, 2018, 2:53 PM UTC

Ace17 wrote: post #458

WalterBright wrote: post #375

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…

> If a program has entered a state unanticipated by the programmer, then there is no way to know how it entered that state [...] and hence no way to know what the program might do next (such as load malware). ... or kill the patient ( https://en.wikipedia.org/wiki/Therac-25 ) or set the company bankrupt overnight ( https://en.wikipedia.org/wiki/Knight_Capital_Group ), or simply delete all your data (happened to me wi…

> (Making special cases for NullPointerException or OutOfBoundsException, like some languages do, is, IMHO, a bad idea, that spreads the confusion between programming mistakes (i.e coming from the source code) and invalid runtime conditions (coming from environment). (I'm avoiding the ambiguous terms "errors" or "bugs" here)).

Actually if you check out the interviews with Java designers the checked exceptions mechanism was designed for that purpose: unchecked exceptions are for bugs that should never happen in a well written code while checked exceptions are for conditions that can happen regardless to how good is your code (e.g. i/o errors).

See: https://www.artima.com/intv/solid.html

There are of course also Errors for fatal conditions that should been be caught (actually in CLR even if you catch the exceptions will be re-raised automatically at the end of the handler).

Another interesting thing in CLR is Constrained Execution Regions that allow you to run the cleanup code reliably even when such a fatal condition is encountered (but the code to be run is limited e.g. it cannot allocate).

Re: 1/0 = 0

#528

Post by blablablerg » Sat, Aug 11, 2018, 3:09 PM UTC

pron wrote: post #424

throwawaymath wrote: post #388

Earlier quoted context omitted.

I don't know what to tell you. You're continuing to argue but you seem to not be following my point. I've already long since told you we're in agreement that you need to account for syntactically possible but theoretically impossible algebras for computation. In so doing I have gone further and repeatedly stated that because division by zero is not actually possible in fields , the author should not have tried to use…

> 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.

Re: 1/0 = 0

#529

Post by sacado2 » Sat, Aug 11, 2018, 3:19 PM UTC

Ace17 wrote: post #458

WalterBright wrote: post #375

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…

> If a program has entered a state unanticipated by the programmer, then there is no way to know how it entered that state [...] and hence no way to know what the program might do next (such as load malware). ... or kill the patient ( https://en.wikipedia.org/wiki/Therac-25 ) or set the company bankrupt overnight ( https://en.wikipedia.org/wiki/Knight_Capital_Group ), or simply delete all your data (happened to me wi…

> (Making special cases for NullPointerException or OutOfBoundsException, like some languages do, is, IMHO, a bad idea, that spreads the confusion between programming mistakes (i.e coming from the source code) and invalid runtime conditions (coming from environment). (I'm avoiding the ambiguous terms "errors" or "bugs" here)).

And that's why I like dual error mechanisms, like the panic vs manual error handling mechanism in Go (despite all its verbosity). It's very important to make the difference between an external error (that should be considered something "normal" to deal with) and an invalid state (that should lead to a halt of the program, maybe after logging something, or before trying to restart the program from zero).

Traditional expection mechanisms (à la try/catch) make it too hard to deal with an external error, and too easy to think you can recover from an invalid state.

Re: 1/0 = 0

#530

Post by JadeNB » Sat, Aug 11, 2018, 3:35 PM UTC

JadeNB wrote: post #310

excalibur wrote: post #27

> We’ve now established that if we choose some constant C, then defining division such that x/0 = C does not lead to any inconsistencies. No, you haven't. You've merely failed to locate any. You've said "I'm not going to prove that this works. I'm going to assume that it does and act as if it did, and place the burden on you to prove otherwise."

> No, you haven't. You've merely failed to locate any. You've said "I'm not going to prove that this works. I'm going to assume that it does and act as if it did, and place the burden on you to prove otherwise." Excellent point. It's not even known if we can get any inconsistencies without making this definition; and it's known that, if it's true that we can't get any inconsistencies without it, then we can't prove t…

(That's not mathematical maundering, by the way; it is a correct if informal statement of part of the incompleteness theorems. I appreciated excalibur (https://news.ycombinator.com/item?id=17736486 )'s point, and wanted to underline the significant, and mathematically precise, difference between "one apparent inconsistency is not present" and "there is no inconsistency.")