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

191–200 of 593 posts

Re: 1/0 = 0

#191

Post by spooneybarger »

thanatos_dem wrote: post #156
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…

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

Here's another good one for you...

What does your favorite programming language return for 3/2 as compared to 3.0/2.0? Many will return different values.

EDIT:

for clarity of my point: integer math that uses machine types is pretty surprising compared to what we would expect from "math" in general for division.

Re: 1/0 = 0

#192

Post by sgt101 »

Julia gives "Inf" and Inf+Inf =Inf and 1/Inf = 0.0

I prefer this because if you have a function converging on 0 then you will see growth towards Inf - then Inf - rather than growth followed by a cliff; which could then propagate into all your other calculations and move you from the very small to the very large in an instant.

Re: 1/0 = 0

#193

Post by madrox »

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…

You're absolutely right. Not only that, but it's impossible to distinguish a bad result like 1/0 vs a good result like 0/1.

Even Javascript is better with "NaN"

Re: 1/0 = 0

#194

Post by dilap »

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

Re: 1/0 = 0

#195

Post by tlb »

luso_brazilian wrote: post #7

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks It actually does break something, the symmetry between division and multiplication and the many pieces of code that assume that (x / y) * y equals x. Here is a naive and non practical example, but it is not impossible to find a real world example where this simplified code manifests itself accidentally or by de…

It's talking about integer arithmetic, so it's already not true that (x / y) * y == x. For example, (5 / 2) * 2 == 4.

Re: 1/0 = 0

#196

Post by spooneybarger »

skybrian wrote: post #181
spooneybarger wrote: post #152

Earlier quoted context omitted.

Hi, I'm on the Pony core team and I generally agree with you. The problem is, if you want to allow people to write high performance code, you are penalizing them becaues, for floating point: 1.0/0.0 is infinity. That's not C# being clever. That's C# following the floating point standard and using the math that the computer provides. To not use that standard means that you make every use of division slower, even if th…

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 how the computer does math more closely approximate what we expect from doing math.

I think that following my above reasoning that only having floating point math can also make sense. That is... in most programming languages 3 and 3.0 are different. Such that 3/ 2 = 1 and 3.0/2.0 = 1.5.

We allow for 3/2=1 because, integer math is faster than floating point math and we want to allow folks to go as fast as possible when doing things like addition, subtraction and multiplication and accept that we can't represent all the numbers that come from division and give an approximation.

Re: 1/0 = 0

#197

Post by Y_Y »

LoSboccacc wrote: post #74
ggggtez wrote: post #57

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks a=x/N b=y/N If a==b, then x==y No longer true, with this change. Essentially a variety of mathematical properties of numbers in the Real space don't hold when you allow division by 0.

well, as long as you aren't doing calculus

I think this is the crucial bit. Division by zero in fields means nothing, but if you want to tack on calculus (part of pretending that doubles are reals) then zero is a perfectly good limit for division and it turns out that defining it as anything at all breaks your system.

I didn't like the blogpost, because it's smug, and doesn't even mention this obvious objection.

Re: 1/0 = 0

#198

Post by phyzome »

tigershark wrote: post #182
MereInterest wrote: post #113

Earlier quoted context omitted.

Take the limit as x goes to 0 of (17*x)/(x). Both numerator and denominator go to 0, so this is a representation of 0/0. The limit is then equal to 17.

This just means that 0/0 = 1. It doesn’t mean that any number / 0 tends to 17.

Right, it just means the limit of that path tends to 17. It's not a well-defined limit.

In a function of one-variable, there's a distinction between one-sided and two-sided limits. I don't know what the terminology would be for multivariable functions, but this is closer in nature to a one-sided limit.

Re: 1/0 = 0

#199

Post by zokier »

ballenf wrote: post #28
luso_brazilian wrote: post #7

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks It actually does break something, the symmetry between division and multiplication and the many pieces of code that assume that (x / y) * y equals x. Here is a naive and non practical example, but it is not impossible to find a real world example where this simplified code manifests itself accidentally or by de…

What if number types were Optionals after any operation that could result in any kind of unusual number (sqrt(-1), Infinity, NaN)? Or maybe after every operation, since any operation could overflow the type. Do any languages do that? Seems more consistent (if way more hassle) than giving a mathematically false result out of pragmatism. At least in a strictly typed language.

Isn't that essentially what floats already are? A sum type of numbers, infinities, and NaN(s).

Re: 1/0 = 0

#200

Post by sclv »

imh wrote: post #85
pmiller2 wrote: post #19

Earlier quoted context omitted.

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

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.
Post reply on HN