1/0 = 0 • Hacker News Board

Re: 1/0 = 0

#231

Post by lmm » Fri, Aug 10, 2018, 10:37 PM UTC

wan23 wrote: post #184

ggggtez wrote: post #139

Earlier quoted context omitted.

No, you are assuming that 1/0= "undefined" where "undefined" is a magical value. It's not. It literally means 'That operation has no definition, and there is no reasonable result to return'. Many languages handle this in a practical way by creating a special value "undefined", "NaN", or others that has special properties. But let's be clear that "0" is a normal number in the real number space, as so expectations abou…

When there is no reasonable result to return does it really matter what result is returned? 1 / 0 == 0 is about the same as 1 / 0 == 3. To avoid this just don't do 1 / 0 in your program.

> 1 / 0 == 0 is about the same as 1 / 0 == 3

Sure, and both are bad.

> To avoid this just don't do 1 / 0 in your program.

If you're going to avoid doing it, better to have it throw an exception if you do it by accident.

Re: 1/0 = 0

#232

Post by throwawaymath » Fri, Aug 10, 2018, 10:37 PM UTC

pmiller2 wrote: post #19

gjulianm wrote: post #17

Earlier quoted context omitted.

I think OP means that nothing breaks mathematically. It is not inconsistent and not false, so you can work with it. The only issue is to deal specially with the case of division by zero, which you have to do anyways. Code that assumes that (x/y) * y = x is wrong if you don't check for y = 0, independently of what you define x/0 to be.

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 by saying, "well no, you have yet to define division by 0 according to the field axioms, so you can't use that division as part of your proof." That's the point! The proof does not demonstrate that division by 0 results in 1, it demonstrates that you cannot define division by 0 while maintaining the algebraic structure of a field.

If the author wants to talk about defining division by 0 in wheels or something esoteric they're more than welcome to. But among fields, and among the real numbers, it's not possible. This whole exercise of trying to refute what has been commonly accepted for over a century is frankly ridiculous for trying to justify undefined behavior in a programming language.

Re: 1/0 = 0

#233

Post by elwell » Fri, Aug 10, 2018, 10:37 PM UTC

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…

What the world really needs: "1/0 = 0" in production build, "1/0 throws error" in development build...

Re: 1/0 = 0

#234

Post by spooneybarger » Fri, Aug 10, 2018, 10:39 PM UTC

behringer wrote: post #225

spooneybarger wrote: post #103

Hi, I'm on the Pony core team. I will be writing in more detail about this decision. A few short notes until then: 1) no one on the team has ever been happy with ending up here, understanding why the decision was made involved understand how partial functions (one that can produce errors like division by zero) are handled in Pony and interesting ergonomic issues that can result that is a large part of what my post wi…

1/0 is not infinity either...

but with floating point units, 1.0/0.0 is infinity.

Re: 1/0 = 0

#235

Post by gmfawcett » Fri, Aug 10, 2018, 10:39 PM UTC

jacobolus wrote: post #78

hexane360 wrote: post #55

Earlier quoted context omitted.

Yes, that's correct. The fact that 1/0 shouldn't be defined as infinity isn't an argument that it should be defined as 0.

There are many contexts where defining either 1/0 = -1/0 = ∞ or 1/0 = +∞ and –1/0 = –∞ is better than the alternatives, especially when working in an approximate number system like floating point. In geometric modeling kinds of applications, I would say that these definitions are typically desirable, with 1/0 = undefined only better in unusual cases. As a simple example, it is typically much more useful for the “tang…

Yes, exactly, I have no idea why you're being downvoted.

Re: 1/0 = 0

#236

Post by huehehue » Fri, Aug 10, 2018, 10:40 PM 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…

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

Re: 1/0 = 0

#237

Post by spooneybarger » Fri, Aug 10, 2018, 10:40 PM UTC

skybrian wrote: post #220

spooneybarger wrote: post #196

Earlier quoted context omitted.

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…

If I understand correctly, instead of the usual kind of boxing, they use a separate type tag (one byte) and support union types with up to 255 other "special" enum values. The type tags and data are stored separately, so instead of an array of boxed values, they internally have two arrays, one for type tags and the other for data. Apparently this can work well with SIMD instructions.

That's pretty cool. There's a lot that a couple of us on the Pony core team like about Julia from our limited knowledge. I'll have to look into that more.

Re: 1/0 = 0

#238

Post by lmm » Fri, Aug 10, 2018, 10:41 PM UTC

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks and you can’t prove something false. Everybody who was making fun of Pony programmers for being ‘bad at math’ doesn’t actually understand the math behind it.

This is playing semantic games. A whole lot does break: / no longer has its usual properties, and if you use those usual properties you can certainly prove false things. It's no different from saying that it's totally fine to define 2 + 2 = 5 and nothing breaks, you then just have to say that 5 isn't the arithmetic successor of 4 any more.

Re: 1/0 = 0

#239

Post by Jach » Fri, Aug 10, 2018, 10:41 PM UTC

wodenokoto wrote: post #101

phyzome wrote: post #60

Some people say "oh, that's easy, 1/0 is +Infinity". So the real fun is at 0/0. The limit of x/y as x and y go to zero depends on which path across the xy plane you take towards the singularity. Along one approach, the limit is 0, along another approach the limit diverges to infinity, along yet another the limit is 17. I'm not kidding! Go to https://www.geogebra.org/3d and enter "x/y" and spin the graph around. The "…

I always thought division by zero was, at best, + and - infinity, depending on the path, which is why we leave it undefined. How would a path lead to 17?

In calculus you're supposed to learn that y/0 with y != 0 is "undefined" (±Inf with limit expressions), while 0/0 is "indeterminate" (can construct any value using a limit expression that contains x/x with x -> 0).

Re: 1/0 = 0

#240

Post by Someone » Fri, Aug 10, 2018, 10:45 PM UTC

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…

I think you’ll find that extremely annoying in programs that do ‘real’ calculations. The compiler will rarely be able to prove that a divisor is non-zero, so you will have to add lots of code to handle edge cases. That can be worth it if you are writing robust numerical code, but I doubt even those writing numerical software libraries would want to handle each edge case.

Worse, division by zero is just the tip of the iceberg. There’s overflow and underflow (which both can happen with addition, subtraction, multiplication, and division) and invalid operations (0/0, √-1, arcsin(2), etc), and you might even want to extend this to detect inexact computations (e.g. to properly report whether you are sure a later division by zero actually is a division by zero)

IEE754 ‘won’ because it is relatively simple to use and many times good enough for real use.