Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1/0 = 0

hillelwayne.com

Post reply on HN
Print view View original

291–300 of 593 posts

Re: 1/0 = 0

#291

Post by bcheung »

I consider it infinity because the limit as the denominator goes to 0 is infinity.

I see this with investments that have infinity ROI. If you get into an investment using only other people's money (OPM) and you make a profit then you have made x / 0. Saying I made an infinity return makes more logical sense than I made 0 return.

There's a saying about the difference between a mathematician and an engineer. If there is a $100 bill on a table and each step you take must be half the remaining distance or less the mathematician will never get there, but the engineer will get there no problem.

It's a non-sensical debate IMO but from the investing scenario that I described above, for all practical purposes, it makes more sense to consider it infinity.

Re: 1/0 = 0

#292

Post by IAmTheTucan »

whatshisface wrote: post #286

The explanation in the article basically boils down to the following: let a/b mean, in my programming language's syntax, = { a divided by b when b is not zero, or 0 otherwise. Yeah, it's not "mathematically invalid," but it punches a hole in the fidelity between numerical methods and the math that they approximate.

I knew that but my friend didn't. So thank you for explaining that for my friend.

Re: 1/0 = 0

#293

Post by abakker »

rubatuga wrote: post #251
abakker wrote: post #222

I am not really a programmer or mathematician, so take this for what it is, but to me, the statement makes linguistic sense, if you read it out like a first grader. If I divide one thing into zero groups, how many items do I have in each group? Zero. Edited per comment below. If I were really pedantic, I'd say that in the above, it's almost like the input "1" is not being divided, but grouped. The funny thing then, i…

I think you mean if I divide one thing into zero groups, how many items do I have in each group

Edited, thanks!

Re: 1/0 = 0

#294

Post by antidesitter »

emileokada wrote: post #124

It's quite staggering how many people have posted on this thread without reading the article. Nearly all the objections people have raised are directly addressed in the post. For those who still object to the argument, would you object to me defining the piecewise function f:R->R defined to be 1/x for x =/= 0 and 0 for when x=0?

Nearly all the objections people have raised are directly addressed in the post.

Are they? I see nothing in the article about the negative consequences of surprising users with silent failure, for example. Or the fact that it makes little sense in real-world scenarios.

would you object to me defining the piecewise function f:R->R defined to be 1/x for x =/= 0 and 0 for when x=0?

What do you mean by objecting to you defining a function?

Re: 1/0 = 0

#295

Post by throwawaymath »

imh wrote: post #275
throwawaymath wrote: post #232

Earlier quoted context omitted.

This should not be getting downvoted. The author of the article made an incorrect refutation of this point under the "Objections" heading. Division by 0 in fields is undefined precisely because it leads to contradictions like this. The full statement of a proof that 1/0 = 0 includes the temporary assumption that you have defined division by 0 such that it is no longer undefined. You can't logically refute that proof…

But the point is you keep the structure of a field for everything that already has it, right? No structure is taken away. All statements valid on any subset of the reals are still valid without modification under this new definition. The algebraic structure is still a field obeying the same axioms. There are just some new valid statements too.

No that's not correct, and this is why I think the author's entire point is pretty inane. If you're going to start off your argument with the full formalism of field axioms and consequent theorems, you need to be prepared to split hairs about whether or not your definitions constitute a field.

Mathematics is thoroughly pedantic about definitions for a reason. If those formalisms don't matter because what you've done is "close enough", then skip the song and dance about field definitions and stop trying to use it to justify the behavior of an undefined operation in a programming language. Just say you're defining 1/0 to be equal to whatever you want because the world doesn't break down. It actually detracts the author's point to so confidently (and incorrectly) refute something that is robustly proved in the first few weeks of an undergraduate analysis course. Why is this even in a blog post about a programming language?!

This is essentially the same point as the extended real (or complex) number systems. The sets of all real and complex numbers (respectively) form fields under the axioms of addition and multiplication. But you can define division by 0 and division by infinity in a way that works with familiar arithmetic (I explained how to do this in another comment barely two weeks ago [1]). But the key point here is that in doing this you sacrifice the uniqueness of real numbers.

The author tries to refute this observation by claiming the proof uses an undefined division operation, but that's a red herring. The real assertion is that you cannot define division as an inverse operation from multiplication to be inclusive of division by the unique unit (i.e. 0, in the real field) unless you are willing to state that every number is equal to every other number in the entire field. And you can do that, but it trivially follows that you no longer have a field without a nonzero element.

So really the actual proof is that division by 0 is undefined for any field with at least one nonzero element.

__________________________________

1. https://news.ycombinator.com/item?id=17599087#17601806

Re: 1/0 = 0

#296

Post by sclv »

gmfawcett wrote: post #229
sclv wrote: post #200

Earlier quoted context omitted.

Right. So the multiplicative inverse property _breaks_! He just points out that it breaks, and thus you need to use a more complicated property instead. That doesn't mean that the property doesn't break.

He's not saying that it breaks; quite the opposite, he repeatedly states that 0⁻ doesn't exist. He's just defining division in a specific way. The MI property states that every element except 0 has a multiplicative inverse. He's defining division via two cases: If b≠0, then a/b = a*b⁻ (multiplicative inverse). If b=0, then a/b=0. This definition does not imply that 0⁻ exists, so there's no violation of MI.

The problem this and the other replies miss is that the standard definition of division is multiplication by the inverse. The entire argument rests on a notational slight of hand. The property that held before -- that _when defined_ division has the inverse property -- no longer holds. Thus many equational identities that otherwise would hold do not hold.

Re: 1/0 = 0

#297

Post by mayoff »

In some languages, you could define a new division operator that returns an Optional/Option/Maybe result, and then use a nil-coalescing operator to choose what you want in case of division-by-zero. In Swift:

    infix operator /? : MultiplicationPrecedence
    extension FloatingPoint {
        static func /? (lhs: Self, rhs: Self) -> Self? {
            return rhs == 0 ? nil : lhs / rhs
        }
    }
    extension BinaryInteger {
        static func /? (lhs: Self, rhs: Self) -> Self? {
            return rhs == 0 ? nil : lhs / rhs
        }
    }

    10 /? 2 ?? 0  // -> 5
    10 /? 0 ?? 0  // -> 0
    10 /? 0 ?? 10 // -> 10

Re: 1/0 = 0

#298

Post by user5994461 »

huehehue wrote: post #236
simias wrote: post #183

Earlier quoted context omitted.

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…

Practically, it's quite common to not immediately know the divisor. In cases where the divisor is initially unknown but takes an imperceptible amount of time to compute it's better to render 0%. Otherwise you might get a flash of a full progress bar (for example) while the divisor is determined. Of course, it's context dependent. As others mention, your code might be full of stuff like X / (divisor || 1) .

    X / (divisor || 1).
It's invalid code in C, C++ and Java.

Re: 1/0 = 0

#299

Post by antidesitter »

dilap wrote: post #194

Just yesterday I had a 1/0 bug (code iterating along some line segments that forgot to account for the possibility of a zero-length segment). If 1/0 was 0, the code would have worked correctly instead of crashing. So, there's one data point in favor. :-)

code iterating along some line segments that forgot to account for the possibility of a zero-length segment

Out of curiosity, could you describe what you were doing and why 1/0 = 0 would have returned the correct result?

Re: 1/0 = 0

#300

Post by lisael »

skybrian wrote: post #204

In case you're wondering, Elm has a strict "no runtime errors" rule, but avoids this by not having integers. Another interesting example is array access. What should a[len(a)+1] be if your language doesn't have runtime errors? Elm returns a Maybe type. However, this would be very awkward if you're actually doing a lot of calculations using arrays. [Edit: Pony is different.]

Pony does have exceptions, and indexing an array does raise if the index is out of bound. It doen't have runtime errors because all exception must be handled somewhere in the call stack, the sooner, the better.

Because of this rule, defining / as a partial function forces the user to fence every single division in a try clause.

Using boxed integer as Elm does is not an option as Pony targets high-speed computing, not browser rendering. Different fields, different trade-offs.

Defensive users can well define `div(I32, I32): I32?` that throws an error and use it instead of `/`.

As repeated in this thread, 1/0 is undefined because nonsensical. So, it's OK to have any sane, consistent and well documented behaviour. At least with Pony, the user can choose speed and convenience when they're sure there is no possible 0 at this place. Well, TBH, I think it's always the case. Because there is no such thing as a division by zero, you're algorithm is simply wrong and unsound if it ends up dividing by 0, and that's where this case differs from integer overflow

Note: in Pony literature, "partial" means "can throw an error". "partial" as in "doesn't apply to the whole domain of the arguments types"

Post reply on HN