1/0 = 0 • Hacker News Board

Re: 1/0 = 0

#421

Post by ordu » Sat, Aug 11, 2018, 5:45 AM UTC

spooneybarger wrote: post #196

skybrian wrote: post #181

Earlier quoted context omitted.

I'm curious, what do you think about Julia's approach with its special "missing" value? Does this approach make sense outside the context of data analysis? https://julialang.org/blog/2018/06/missing

I can't really comment. I don't know how they are doing it and why they made that choice. I assume that Julia was already boxing integers in some fashion at which point this 100% makes sense to me. Also, given the performance profile that you are seeking to allow programmers to achieve, I think boxing all integers makes sense, then you can give folks protection from integer overflow and underflow and otherwise make h…

> We allow for 3/2=1 because, integer math is faster than floating point math

Is it? I didn't measured it myself, but from reading Abrash's The Black Book I had got an idea that floating point division is faster on x86 with FPU.

Re: 1/0 = 0

#422

Post by gowld » Sat, Aug 11, 2018, 5:46 AM UTC

spooneybarger wrote: post #175

mywittyname wrote: post #169

Earlier quoted context omitted.

I don't think this really solves the problem. It just kicks the same problem over to addition instead. let a = 17 let b = 10 let c = 7 let d = a - (b + c) // throws AddsToZeroException > Make division by zero impossible with the type-checker. Forcing programmers to consider division by zero when it occurs can be done simply by having the language compiler force handling of a divide by zero exception when division occ…

> Forcing programmers to consider division by zero when it occurs can be done simply by having the language compiler force handling of a divide by zero exception when division occurs. Which is what Pony originally did and, lordy that can be an ergonomic nightmare when I know I don't have 0 and can prove it except, I can't prove it to the compiler and the type system. This problem is why integer division by zero is ze…

Wouldn't it be better to have an explicit unsafeCastToNonZero() function in the stdlib instead forcing invisible unsafe casts in every division statement of every program?

Re: 1/0 = 0

#423

Post by skrebbel » Sat, Aug 11, 2018, 5:47 AM UTC

WalterBright wrote: post #375

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…

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 by uncommon data shouldn't crash the entire server.

I don't know much about Pony, but given that it is also actor based, I'd imagine this would be a great opportunity to crash early and eagerly. It gives you all the advantages of catching a bug early while not crippling a production app under what might be a pretty low-impact, low-frequency bug.

Re: 1/0 = 0

#424

Post by pron » Sat, Aug 11, 2018, 5:47 AM UTC

throwawaymath wrote: post #388

pron wrote: post #359

Earlier quoted context omitted.

If you mean this, https://news.ycombinator.com/item?id=17737661 , then it contains a mistake, which I pointed out in a reply. The references you linked to are irrelevant as they refer to informal mathematics. Of course you can't meaningfully divide by zero (in the sense that the value of division corresponds with our intuitive understanding of what division is). But when it comes to formalization you must assign some…

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 unacceptable (i.e. it does not precisely and fully define what a field is)? If so, why? If not, can you write a single theorem in this theory that would be falsified if I added the axiom, ∀ x . x/0 = 0 ?

If your answer to both questions is no, then your only point may be that the extended definition of the symbol / does not deserve the name "division" because it does not conform to our intuitive, informal notion. That's fine but is a long way from claiming that there is no acceptable formalization of fields or that division by zero introduces a mathematical contradiction or breaks equational laws. Note that you cannot say that the original theory defines a field while the extended one doesn't, because the latter's models are a subset of the former's.

This then leaves open the matter of whether such a philosophical, aesthetic consideration trumps pragmatic ones or vice-versa, to which I don't think anyone has a universal answer, and it is not the issue, anyway.

Re: 1/0 = 0

#425

Post by ummonk » Sat, Aug 11, 2018, 6:03 AM UTC

The standard definition of r = p/q is the number that solves the equation rq = p. This version of "division" does not satisfy that definition, and is therefore not actual division. Call it division* or something.

Edit: it seems that Pony is only doing this for integer "division", which isn't regular division anyway, and the standard rules don't apply.

Re: 1/0 = 0

#426

Post by Ngunyan » Sat, Aug 11, 2018, 6:04 AM UTC

throwawaymath wrote: post #393

pron wrote: post #358

Earlier quoted context omitted.

There is a mistake in your step 3, as it relies on an informal and imprecise "division is the inverse of multiplication". If you were to write that formally, you'd get `∀ x ≠ 0 . x(1/x) = 1`. This holds unchanged even if you define division by zero. Even if you could come up with another formalization that does cause a problem, e.g. `∀ x ∈ dom(1/t) . x(1/x) = 1` (and I would say that this is the only formalization th…

This is nonsense. 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, just as is the case for subtraction and additive inverses. The problem is not that field theory doesn't tell you "what happens" when you divide by 0 - you haven't defined that, there is no what happ…

This is arguing by hectoring...

>The problem is not that field theory doesn't tell you "what happens" when you divide by 0 - you haven't defined that, there is no what happens because nothing happens at all.

This is intuitively mistaken. If "when you divide by 0 .. nothing happens at all", then how come multiplication by 0 is zero, when they're both operations against 0? The problem is that mathematicians have forgotten the meaning of 0. Anything multiplied by zero is zero. Anything divided by zero is zero. This agrees with normal intuition on working with nothingness, and the original idea from Brahmagupta.[ https://www.storyofmathematics.com/indian_brahmagupta.html]

Re: 1/0 = 0

#427

Post by ummonk » Sat, Aug 11, 2018, 6:06 AM UTC

simias wrote: post #183

bunderbunder wrote: post #94

Earlier quoted context omitted.

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

I'm reading the "Pony" tweet quoted in TFA and your comment and I'm left very puzzled: is that really that common to want x / 0 == 0 ? In practice where does that crop up? You say that you frequently have to write your little shim but honestly I don't remember writing code like that in recent memory. You talk about progress bars, I suppose it makes sense if you somehow try to copy 0 elements for instance, and you end…

>It's also a bit odd because it introduces a discontinuity: as the divisor goes towards zero the result of the operation gets greater until it reaches exactly zero and it yields 0. Wouldn't it make more sense to return INT_MAX (for integers) or +inf for floats?

Unless you're using unsigned ints, the discontuity will exist no matter what you do, because of negative divisors.

Re: 1/0 = 0

#428

Post by Zarel » Sat, Aug 11, 2018, 6:09 AM UTC

tikhonj wrote: post #187

c3534l wrote: post #145

Edit: I guess there's a reason I'm not a language designer. I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible w…

This kind of type becomes really tedious to use unless there is some sort of viable "subtyping"—you certainly want to be able to use a non-zero number where any number works and, ideally, you want to be able to recover a non-zero number when you write a function that takes in a normal number and always returns a positive value. If you're forced to use a bunch of explicit conversion functions to achieve this you add a…

> generally, the most common function is going to be along the lines of "I know this is positive, so throw an error if it's 0"—which is exactly what we get anyway.

That's still a lot better than before. It's not too hard to read a function and be reasonably confident that it will always return a positive value. On the other hand, it's pretty hard to audit an entire codebase to make sure a value can never be negative, or something like that.

The main difference is probably only needing to do that audit once, when writing the function, instead of every time you need to rely on the function's return value being positive.

It would also save a lot of work because a lot of operations _can_ be detected automatically. positive * positive = positive, etc. So you would only have to manually assert in the cases it wouldn't be doable automatically, which would be significantly fewer than before.

Re: 1/0 = 0

#429

Post by electrum » Sat, Aug 11, 2018, 6:09 AM UTC

skrebbel wrote: post #423

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…

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++, where the usual behavior is to segfault and crash the process.

Special care must be taken if threads are manipulating shared data structures, especially inside a "critical section" where the data structure invariants must be maintained. This is why automatically terminating the JVM when OutOfMemoryError occurs is a best practice, as code is often not paranoid enough to handle it.

Re: 1/0 = 0

#430

Post by Ceezy » Sat, Aug 11, 2018, 6:13 AM UTC

First the difinition of given of a field is wrong https://en.wikipedia.org/wiki/Field_(mathematics) . But why not? the author might not know but 1/0 is by definition the inverse of 0 and that s why 1 * (1/0) = 1. What he do is extanding the definition of the division FUNCTION. And you can always do that. But by doing that you lose most of algerbaic and arithmetical propreties for numbers. But worst! There exists 1/ 0 = infinity, but also infinity * 0 = 0(in probability). So please stop creating fake controversies about stuff that really doesn t need ANY DEBATES.