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

1/0 = 0 (2018)

hillelwayne.com

Post reply on HN
Print view View original

111–120 of 245 posts

Re: 1/0 = 0 (2018)

#111

Post by oDot »

throwawaymaths wrote: post #99

Yes, it's all good and nice that your types are sound and you don't have panics, but I feel like this could get you in trouble in the real world (gleam also uses this division convention, and people very much use gleam for "real world" things). Suppose you took an average over an unintentionally empty list (maybe your streaming data source just didn't send anything over the last minute due to a backhoe hitting a fibe…

I use Gleam in production[0][1], and that is not really an issue.

Gleam offers division functions that return an error type, and you can use those if you need that check.

They fit a list-length use case well as they work better with a piping syntax which is popular in Gleam.

[0] https://nestful.app

[1] https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam

Re: 1/0 = 0 (2018)

#113

Post by ncruces »

throwawaymaths wrote: post #101
sethev wrote: post #18

I debated this with my boss at my first programming job (this was 20+ years ago). He thought 1/0 should be 0 rather than an error because "that's what people expect". My argument was from mathematical definitions (the argument which this blog post picks apart). In retrospect, I see his point better - practical use trumps theory in most language design decisions. I haven't changed my mind but the reason has shifted mo…

1/0 = 0 is usually not a practical thing, it's to satisfy that the output of the division operator stays in the type and you don't want crashes (a "feature" of ponylang and gleam, e.g.). Its kind of a PL wonk thing. It's not at all a good idea for very important practical reasons as I outline in a reply to parent.

I don't want to handle errors after every division and division doesn't crash, both sound rather practical, though.

Re: 1/0 = 0 (2018)

#114

Post by numpad0 »

v4vvdq wrote: post #15
CharlieDigital wrote: post #9

Earlier quoted context omitted.

There's a great Radiolab episode[0] that talks about divide by zero in perhaps more conceptual terms. KARIM ANI: If you take 10 and divide it by 10, you get one. 10 divided by five is two. 10 divided by half is 20. The smaller the number on the bottom, the number that you're dividing by, the larger the result. And so by that reasoning ... LULU: If you divide by zero, the smallest nothingness number we can conceive of…

Then take 10 and divide it by -10 = -1. 10 / -5 = -2. 10 / -0.5 = -20. So from the other side of the y-axis it behaves the exact opposite. It goes to minus infinity. So at x=0 we would have infinity and minus infinity at the same time. Imho that is why it is undefined.

I always thought the answer to verbal query "let y=1/x, x=0, find y" was "Well, the answer is the Y axis of the plot". Surprising that people have to be reminded that X can be signed. I've had similar conversation IRL.

Re: 1/0 = 0 (2018)

#115

Post by ncruces »

ilius2 wrote: post #89
clipsy wrote: post #54

Earlier quoted context omitted.

> even in other languages a/b gets closer to it's actual value as a and b get bigger (the "limit", which is the basis of Algebra) This is not generally true. 5/2 = 2, 50/20 = 2, 500/200 = 2, and so on no matter how big the numbers get.

Yes, I meant when the result gets bigger. You get the idea.

What's the output of this Go program, without going to the playground link?

  print(math.MinInt / -1)
https://go.dev/play/p/Vy1kj0dEsqP

Re: 1/0 = 0 (2018)

#116

Post by giraffe_lady »

jsnedjdn wrote: post #108
sethev wrote: post #18

I debated this with my boss at my first programming job (this was 20+ years ago). He thought 1/0 should be 0 rather than an error because "that's what people expect". My argument was from mathematical definitions (the argument which this blog post picks apart). In retrospect, I see his point better - practical use trumps theory in most language design decisions. I haven't changed my mind but the reason has shifted mo…

Never have I ever met anybody who would think dividing by zero yields zero O_o If anything it feels natural to yield +/-infinity

It's not about what I think zero division yields I've taken a math class before. It's just about representation within the type system. If division can return infinities we can't safely combine division with other functions that are expecting ints and floats.

Most languages throw an error instead, but there are tradeoffs there too. If you've decided not to throw an error you should at least return a usable number and zero makes more sense than -1 or 7 or a billion or whatever.

You could also build the number stack from the ground up to accommodate this edge case, and make it so all arithmetic functions can handle infinities, infinitesimals and limits. I've come across a racket sublang like that but it's nearly unusable for the normal common things you want to do with numbers in code.

Re: 1/0 = 0 (2018)

#117

Post by IshKebab »

tmtvl wrote: post #32
IshKebab wrote: post #13

> It’s saying that Pony is mathematically wrong. This is objectively false. Pff. The author wants to show off their knowledge of fields by defining a "division" operator where 1/0 = 0. Absolutely fine. I could define "addition" where 1 + 2 = 7. Totally fine. What I can't do is write a programming language where I use the universally recognised "+" symbols for this operation, call it "addition" and claim that it's tot…

> What I can't do is write a programming language where I use the universally recognised "+" symbols for this operation, call it "addition" and claim that it's totally reasonable. As a programmer, you're right: we have standard expectations around how computers do mathematics. As a pedant: Why not? Commonly considered 'reasonable' things surrounding addition in programming languages are: * (Particularly for older pro…

> I haven't yet encountered a language which solves this issue:

Well, Python supports arbitrary precision integers. And some other niche languages (Sail is one I know).

I don't think "running out of memory" counts as a caveat because it still won't give the wrong answer.

For floats, I don't think it's actually unreasonable to use different operators there. I vaguely recall some languages use +. or .+ or something for float addition.

Fair point about wrapping.

Re: 1/0 = 0 (2018)

#118

Post by iforgotpassword »

pasquinelli wrote: post #97
sethev wrote: post #18

I debated this with my boss at my first programming job (this was 20+ years ago). He thought 1/0 should be 0 rather than an error because "that's what people expect". My argument was from mathematical definitions (the argument which this blog post picks apart). In retrospect, I see his point better - practical use trumps theory in most language design decisions. I haven't changed my mind but the reason has shifted mo…

i would not expect 1/0 to be zero. as you divide by smaller numbers, the quotient gets bigger, so i can't understand why someone would expect /0 to be zero.

If I have five apples and were to divide them among 0 people then nobody gets anything and I can eat them all, so the proper solution would be 5.

Re: 1/0 = 0 (2018)

#119

Post by d--b »

The only thing that truly matters is this:

When software engineers make mistakes dividing by 0 and end up with Exceptions being raised or NaNs being output, they'll usually blame themselves.

When the results are wrong numbers all over the place, they'll blame the language.

There are 2 cases when people are going to "use" x/0:

1. They made a mistake.

2. They KNOW that x/0 returns 0 and they take it as a shortcut for (y == 0 ? 0 : x/y)

Is that shortcut useful? No. Is it dangerous? Yes. Hence, this is a bad idea.

Re: 1/0 = 0 (2018)

#120

Post by AlotOfReading »

snickerbockers wrote: post #91
lilyball wrote: post #87

Earlier quoted context omitted.

(a/b)*b=a isn't true, but that's also not true for the math that you're thinking of. What is true is IF b≠0 THEN (a/b)*b=a. And this definition works just fine even if you define division by zero. Also just to point out, the statement here really is a*b‾*b=a, which might make it more clear why b≠0.

There's no "if" in the division operation. Division is not defined for b=0. a/0 is a nonsensical quantity because the zero directly contradicts the definition of division. maybe someday there will be a revelation where somebody proposes that it's a new class of numbers we've never considered before like how (1-1), (0-1) and sqrt(-1) used to be nonsensical values to past mathematicians. For now it's not defined.

Division by zero is perfectly well defined in floating point. x/0 = INF and INF*0 = NaN. That means b*(a/b) != a if b = 0.

It's true that it's not defined for integer types, but that wouldn't make a = b*(a/b) true for them either.

It's also common to define x/0 = infinity in the extended real numbers that floating point models.

Post reply on HN