Live data from Hacker News

1/0 = 0

hillelwayne.com

171–180 of 593 posts

Re: 1/0 = 0

#171

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…

> 2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value. Oh jeeze... to me that almost nullifies all of the points in the article. It does an alright job explaining how 1/0 = 0 is at least consistent with other notions in the language, but to hear that the same logic can’t be applied to floats is just... well, objectively it’s a mess.

Hillel is talking about math. Unfortunately computers don't really do "math". For example, math doesn't have overflow and underflow to deal with.

The floating point standard says that division by 0.0 should be Infinity and provides a value for it. The integer math, all possible values are used for numbers, so division by zero is undefined behavior.

And from there, every language is potentially going to have a mess of inconsistency to deal with.

You can make 1/0 = Infinity so long as you box all your integers. That is, its not using the machine type, but I type that is a wrapper that can be the machine type or Infinity. And every user takes a large performance hit even if they will never divide by zero.

For some languages boxing integers is not a bad thing because they already do it. Why do they do it? Usually, because of another not math problem. Overflow and underflow:

What is 0 - 1? Well, its -1 right? Except of course if you have an unsigned integer, then its the max value of the integer. And what if you had 1 to the max value that the computer can represent? You wrap around. Some languages make all integers protect you from this and take a performance hit to be able to box and be able to represent numbers better as we expect them to work. In return, you can not do integer math as fast as you could.

Computers and numbers... its an inconsistent mess and a series of tradeoffs for any language of performance and various possible errors.

I'm going to talk about this and more in my post.

Re: 1/0 = 0

#172

Earlier quoted context omitted.

IMHO I think the problem here is that most people focus on the "wrong side" of 1/0. I mean, what the mathematical definition of division says is not that 1/0 is indeed something and that that something is "undefined" or "NaN" or anything else really. What it says is "I cannot do 1/0, the division operation a/b does not apply when b is 0". So 1/0 is not a thing in itself in mathematics; it's something which cannot be…

Except that 0 could actually be the result of a valid computation. NaN, undefined, or Infinity can not.

And you mean that as saying that it is then better? Or that it is not?

(Sorry, I'm not sure which way you mean it)

Re: 1/0 = 0

#173

This thread is showing once again that reading comprehension is not our strong-suit here on HN. The author does not once say that Pony's choice is a good one, only that whether it is a good or bad one should be settled by engineering consequences, and that there is no purely mathematical argument that precludes it. I can't help but think it _is_ a bad idea, because it's easier to overlook a 0 appearing than a NaN. Th…

The Pony devs did chime in and mentioned that they do define division by zero to be NaN (or positive infinity) where the underlying type supports it (e.g. IEEE 754 floats).

Most integer representations have no space for such a value, so the only choices available to language developers are:

1. Throw an exception or otherwise consider it an error

2. Define the result to be 0 or 1 or some other integer value (0 being the only good choice)

3. Use a non-standard integer representation

Most languages opt for option 1, Pony chose 2, and I've never seen 3, perhaps due to it requiring so much software interference and precluding inter-operation with other languages.

Re: 1/0 = 0

#174
post #105

Earlier quoted context omitted.

IMHO I think the problem here is that most people focus on the "wrong side" of 1/0. I mean, what the mathematical definition of division says is not that 1/0 is indeed something and that that something is "undefined" or "NaN" or anything else really. What it says is "I cannot do 1/0, the division operation a/b does not apply when b is 0". So 1/0 is not a thing in itself in mathematics; it's something which cannot be…

The practical downside is that it might make equations go slightly wonky, rather than completely wonky if a non-number is returned. For example, say if a zero divide happens with normalized values. Meaning the immediate result is only off by one at most. Odds of catching that are probably low. Meanwhile, a NaN will infect all numbers that come into contact with it, bubbling up faster... Under this system, programs ar…

I agree with that; in general I'd rather be told too.

But I don't know anything about Pony or it's goals. So it may be preferable for them, I don't know.

Re: 1/0 = 0

#175
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 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 zero in Pony. Because, I can as a programmer prove that I won't divide by zero, but having a type system or compiler where I can prove it to it that is a computation engine that takes user input is a very non-trivial problem.

The solution in Pony is going to be a combination of "safe math operators" and adding value dependent typing to the compiler.

"safe math operations" would be: *?, /?, -?, +? that will error on division by zero as well as integer overflow and underflow (and have slower performance as well)

Re: 1/0 = 0

#176

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

> But similarly frequently, I end up crapping out annoying little bits of code Isn't this reason the the point of having a utils library with commonly used pieces of code?

Some utilities libraries can be reflections of deficiencies in the language itself and not simply about common code reuse.

Re: 1/0 = 0

#177
Oh sure, there are infinite numbers of matrices without inverses and no one cares.

But you try to slide one little real number without an inverse by and everyone freaks out.

Re: 1/0 = 0

#178
post #70

What proportion of the time will a programmer intend and expect 1/0 = 0? What proportion of the time will a divide-by-zero operation be a symptom of a bug, where evaluating 1/0 as any valid number will make it harder to identify that bug? There might be a mathematical justification for 1/0 = 0, but the computer science justification seems tenuous at best. The overwhelming majority of the time, I want divide-by-zero t…

We’re talking here about integer math. Integer math on CPUs is usually fast at the expense of having coherent semantics. It isn’t even really “integer” math in any mathematical sense. It’s just “the fastest math that the CPU is capable of doing, which happens to look a lot like integer math most of the time.” If you’re dividing floats, you will get NaN or Infinity as expected. Just like how, if you overfloat a float,…

Thanks for this explanation.

Re: 1/0 = 0

#179
post #161

Earlier quoted context omitted.

You're right. It really would've been nice for the author to offer a direct proof. However, while I'm a bit rusty, I think it basically has to be true. For there to be an inconsistency, 1/0 = 0 must either a) imply the negation of some previous theorem of arithmetic or b) imply that 1/0 = x, for x != 0. I think a) can only be true by way of b), since no existing theorem of arithmetic involves the expression y/0 for a…

You have to add extra "except when"s to every theorem involving division. E.g.: (a+b)/c = a/c + b/c (in particular, for C != 1, as the author claimed it would work not just for 0 for for any real number) Now to say this is true you have to say "unless c = 0", whereas before that was automatic from the definition of division.

The same theorem

forall c != 0, (a+b)/c = a/c + b/c

is true before and after.

It may be helpful to observe that while using the same symbol '/' in both cases is confusing, mathematical theorems are not about symbols, but about particular mathematical objects. The old theorem is about the division relation defined for real numbers != 0, the new one is a relation defined for all real numbers, that just happens to coincide.

Re: 1/0 = 0

#180
I remember that 1/n is saying 1 with respect to n increments. 1/4 is 1 out of 4 buckets (of 1 integer). If you have 1/no buckets, it is an amount, but it is impossible to know how much. It's measuring a caterpillar without a unit of measure. "He's 7" "Ok, Im sure he is, but 7 what?" 1/0 may approach 0, but it is not 0.
Post reply on HN