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

271–280 of 593 posts

Re: 1/0 = 0

#271

Post by xxbgbqbq »

bunderbunder wrote: post #94
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…

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

Actually, bar/foo STILL has a gotcha which can throw exception, many developers doesn't think of this.

Just try INT_MIN/-1, can blow most "foolproof" divide logic away.

Re: 1/0 = 0

#272

Post by improv32 »

sclv wrote: post #200
imh wrote: post #85

Earlier quoted context omitted.

This is explicitly talked about in OP about 2/3 of the way down the page. "If 1/0 = 0, then 1 = 0 * 0" is untrue. Your argument is "1/0 = 0, so multiply both sides by zero: 1/0 * 0 = 0 * 0, and then take 1/0 * 0 = 1 * 0/0." That last step isn't the case for reasons covered in the article we're ostensibly discussing.

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.

You missed the part where he defines division as a/c = a * inverse(c) for all c != 0

Re: 1/0 = 0

#273

Post by todd8 »

Let f(x) = 1/x, then (from a mathematician’s perspective) the limit of f(x) as x->0 doesn’t converge and is representeted as being infinite, definitely not zero.

As the denominator gets smaller, the result is bigger and bigger and bigger. The closer the denominator gets to zero the larger the result. Why would we want to pick an answer that is small when instead it should be larger than any number?

One might argue that 1/0 should be MAXINT or IEEE 754 plus infinity due to the limitations of our hardware, but I’ve never wanted 1/0 to result in zero in any program I’ve ever written.

I would prefer that it be treated as an error or possibly some reserved value that behaves like INF while still being an integer in the programming language.

Re: 1/0 = 0

#274

Post by simonbyrne »

spooneybarger wrote: post #257
simonbyrne wrote: post #244

Earlier quoted context omitted.

What about I64.min_value() / (-1)? Why does that give 0? If you're doing wrap-around arithmetic it should give I64.min_value(). https://tio.run/##K8jPq/z/PzG5JL9IwTcxM49LAQjyUssVkotSE0tSNV...

That might be an LLVM bug. `I64.max_value() + 1` gives the expected result. I'm going to have to look into that. Thanks.

Apologies, I realise my comment was a bit snarky. Pony looks like a really neat language: I'll be interested to see what you do with it.

Unfortunately LLVM considers division overflow undefined: http://llvm.org/docs/LangRef.html#id109

If it's any use, you can see what Julia ended up doing here: https://github.com/JuliaLang/julia/issues/8188

Re: 1/0 = 0

#275

Post by imh »

throwawaymath wrote: post #232
pmiller2 wrote: post #19

Earlier quoted context omitted.

It is inconsistent. If 1/0 = 0, then 1 = 0*0.

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.

Re: 1/0 = 0

#276

Post by throwawaymath »

skybrian wrote: post #255
throwawaymath wrote: post #242

"Mathematics does not give us truths, it gives us consequences." I'd like to point out that, as I stated in another comment in this thread, the author's supposed refutation of the inconsistency inherent in division by zero within fields is incorrect. Their refutation is as follows: The problem is in step (3): our division theorem is only valid for c ≠ 0, so you can’t go from 1/0 0 to 1 * 0/0. The “denominator is nonz…

It seems like he covered that in the article. There is no multiplicative inverse of zero. But that isn't the same as defining a division operation.

He didn't cover that in the article, or at least not in a way that actually supports his point. Since there is no multiplicative inverse of 0, division by 0 is undefined behavior. Trying to remediate that by refuting the "proof" that it's undefined while still asserting that we can define it as something else is mathematically incoherent.

If you want to see why it doesn't work from a number of different angles, read through the /r/math thread[1] or the Wolfram MathWorld blurb [2].

The formal problem comes down to one of uniqueness of elements. If you define division by zero in a field, you must end up in a place where it follows that every element is equal to every element. Then you only have one element - 0. So really we should be stating that division by zero is undefined behavior in fields with at least one nonzero element.

But again - we can neatly sidestep all of this, because trying to defend your choice of undefined behavior in a programming language based on the abstractions of field axioms is silly. In the actual world we don't even deal with real numbers computationally, let alone the particular nuances of whether or not our programming language implements number systems composing a field or any other algebraic structure.

__________________________

1. https://www.reddit.com/r/math/comments/3b5i6p/can_you_divide...

2. http://mathworld.wolfram.com/DivisionbyZero.html

Re: 1/0 = 0

#277

Post by FlipperBucket »

ggggtez wrote: post #24
sgillen wrote: post #4

I mean sure Pony, but as a programmer this result would surprise me quite a lot, which I tend to view as a bad thing. https://en.wikipedia.org/wiki/Principle_of_least_astonishmen... However: > One of developers of Pony reached out to me. They’re planning on writing a more in-depth explanation of why Pony chose 1/0 == 0, which I will linked when available. As I understand it, it’s because Pony forces you to handle all…

Based on the tweet, I don't expect it to be very enlightening. Since programmers write programs to solve real problems, and real problems define 1/0=undefined... then this is only going to mask bugs in those programs.

> programmers write programs to solve real problems, and real problems define 1/0=undefined

Saying that is easy and common. Can you come up with a contrived example?

Re: 1/0 = 0

#278

Post by spooneybarger »

wutbrodo wrote: post #226
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…

> But in this case, they are hurting their users far more than they are helping. How could you possibly make an assertion like this without knowing why they made said choice[1]? Per the article, they didn't do it for fun, or to avoid exceptions (as you point out, more like defer exceptions). FTA: > As I understand it, it’s because Pony forces you to handle all partial functions. Defining 1/0 is a “lesser evil” conseq…

Hi I'm on the Pony core team and spent some time explaining the reasoning to Hillel. He hasn't written any Pony but I did walk him through how we ended up where we currently are.

I will be writing up a post about why we made this decision.

Re: 1/0 = 0

#279

Post by throwawaymath »

pron wrote: post #266
throwawaymath wrote: post #242

"Mathematics does not give us truths, it gives us consequences." I'd like to point out that, as I stated in another comment in this thread, the author's supposed refutation of the inconsistency inherent in division by zero within fields is incorrect. Their refutation is as follows: The problem is in step (3): our division theorem is only valid for c ≠ 0, so you can’t go from 1/0 0 to 1 * 0/0. The “denominator is nonz…

> The whole point is that the proof shows you any way you define division by 0 is going to compromise your definition of a field, or it's going to make fields with nonzero elements impossible. But it does neither. All field theorems pertaining to inverses/division take the form `x ≠ 0 ⇒ ... x⁻¹ ...` None of them is compromised. > In fact, the modern, axiomatic definition of a field explicitly excludes the unit 0 from…

> The whole problem is one of formalization. "Undefined", as it's used in mathematics, is very much informal. It is used to say that a certain expression, 1/0, while "grammatically" correct, is meaningless. Formal systems simply cannot do that: the expression 1/0 must either be ill-formed (can be done with dependent types but is often inconvenient) or it must mean something in the semantic domain of the language. Different formal system define what that something is, but whatever it is, it is no longer "undefined" in the informal sense.

We're substantially in agreement here. This circles back to my core thesis - there is no point in defending the implementation of something mathematically undefined in a programming language by retreating to the formal axioms of fields (or any other algebraic structure, for that matter).

Your other point about 1/0 = x for whatever you'd like x to be is something I mentioned in my comment. The extended real number system does something similar by defining arithmetic of positive and negative infinities. But the extended real number system is not a field. It's a fine and useful system, but you insert pathologies into the real field by trying to accept infinity as a real number. Likewise if you want 1/0 to be equal 42, that's fine. But you're going to "infect" everything that 42 touches in the process. You won't compromise arithmetic, but you will compromise the definition of a field.

What I'm getting at is that 1) mathematically speaking, the author's entire preamble about division by 0 is both incorrect and irrelevant, 2) we should not be trying to justify implementation behavior in systems which cannot use real numbers through the wizardry of field theorems.

Re: 1/0 = 0

#280

Post by spooneybarger »

simonbyrne wrote: post #274
spooneybarger wrote: post #257

Earlier quoted context omitted.

That might be an LLVM bug. `I64.max_value() + 1` gives the expected result. I'm going to have to look into that. Thanks.

Apologies, I realise my comment was a bit snarky. Pony looks like a really neat language: I'll be interested to see what you do with it. Unfortunately LLVM considers division overflow undefined: http://llvm.org/docs/LangRef.html#id109 If it's any use, you can see what Julia ended up doing here: https://github.com/JuliaLang/julia/issues/8188

I didn't take it as snarky. I was genuinely surprised. Thank you. If you intended it to be snarky, I didn't notice.

And thank you for the additional info, I've updated the issue I opened accordingly:

https://github.com/ponylang/ponyc/issues/2858

Post reply on HN