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

161–170 of 245 posts

Re: 1/0 = 0 (2018)

#161

Post by VMG »

williamdclt wrote: post #144
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…

as so often, the really preferable solution would be to make it impossible to code the wrong thing from the start: - a sum type (or some wrapper type) `number | DIVISION_BY_ZERO` forces you to explicitly handle the case of having divided by zero - alternatively, if the division operator only accepted the set `number - 0` as type for the denominator you'd have to explicitly handle it ahead of the division. Probably be…

galaxy brain: `number` already includes `NaN`

Re: 1/0 = 0 (2018)

#162

Post by JumpCrisscross »

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…

> He thought 1/0 should be 0 rather than an error because "that's what people expect"

So I saw this in action once, and it created a mess. Private company had a stupid stock dividend mechanism: every shareholder received some fraction, dependent on fundraising, of a recurring floating pool of shares, quantity dependent on operating performance. (TL; DR Capital was supposed to fundraise, management was supposed to operate. It was stupid.)

One quarter, the divisor was zero for reasons I can't remember. This should have resulted in no stock dividend. Instead, the cap-table manager issued zero-share certificates to everyone. By Murphy's Law, this occured on the last quarter of the company's fiscal year.

Zero-share certificates are used for one purpose: to help a shareholder prove to an authority that they no longer own any shares. Unlike normal share certificates, which are additive, a zero-share certificate doesn't add zero shares to your existing shares; it ambiguously negates them. In essence, on that day, the cap-table manager sent every shareholder a notice that looked like their shares had been cancelled. Because their system thought 1 / 0 = 0.

If you're dividing by zero in a low-impact system, it really doesn't matter what you output. Zero. Infinity. Bagel. If you're doing so in a physical or financial or other high-impact system, the appropriate output is confused puppy.

Re: 1/0 = 0 (2018)

#164

Post by wat10000 »

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…

People are too scared of crashes. Sure, crashing is not ideal. Best is to do what the program is supposed to do, and if you can’t, then it’s better to produce a friendly error message than to crash. But there are far worse outcomes than crashing. Avoiding a crash by assigning some arbitrary behavior to an edge case is not the right approach.

Re: 1/0 = 0 (2018)

#165

Post by oDot »

JumpCrisscross wrote: post #157
oDot wrote: post #111

Earlier quoted context omitted.

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

OP didn’t say Gleam is dangerous in general. They said it’s dangerous anywhere around physical or financial values. Your app isn’t critically dealing with either, so it’s not really a retort to their point.

You'll find that keeping my client information's integrity is as important to me as keeping the financials.

That, however, is still not enough to alleviate OP's concerns, which is why I've explained how the `1/0=0` problem can be entirely avoided.

I expect entirely avoiding the problem OP mentioned is enough to alleviate the concerns it raises.

Re: 1/0 = 0 (2018)

#166

Post by JumpCrisscross »

oDot wrote: post #165
JumpCrisscross wrote: post #157

Earlier quoted context omitted.

OP didn’t say Gleam is dangerous in general. They said it’s dangerous anywhere around physical or financial values. Your app isn’t critically dealing with either, so it’s not really a retort to their point.

You'll find that keeping my client information's integrity is as important to me as keeping the financials. That, however, is still not enough to alleviate OP's concerns, which is why I've explained how the `1/0=0` problem can be entirely avoided. I expect entirely avoiding the problem OP mentioned is enough to alleviate the concerns it raises.

> keeping my client information's integrity is as important to me as keeping the financials

Nobody is questioning your intentions. People writing apps in memory-unsafe languages don’t give fewer shits. They’re just more prone to certain classes of errors.

> how the `1/0=0` problem can be entirely avoided

1/0 problems are generally expected to be entirely avoided. This is about where the system behaves unexpectedly, whether due to human error or the computer being weird.

Re: 1/0 = 0 (2018)

#167

Post by oDot »

JumpCrisscross wrote: post #166
oDot wrote: post #165

Earlier quoted context omitted.

You'll find that keeping my client information's integrity is as important to me as keeping the financials. That, however, is still not enough to alleviate OP's concerns, which is why I've explained how the `1/0=0` problem can be entirely avoided. I expect entirely avoiding the problem OP mentioned is enough to alleviate the concerns it raises.

> keeping my client information's integrity is as important to me as keeping the financials Nobody is questioning your intentions. People writing apps in memory-unsafe languages don’t give fewer shits. They’re just more prone to certain classes of errors. > how the `1/0=0` problem can be entirely avoided 1/0 problems are generally expected to be entirely avoided. This is about where the system behaves unexpectedly, w…

Correct, these are all trade-offs we make when building a product. Choosing between the "1/0 crashes your program" problem and the "1/0 returns 0" problem is one such tradeoff.

All I was doing was clarifying the impression OP gave.

Now that we all know the details we can make whatever tradeoff we prefer.

Re: 1/0 = 0 (2018)

#168

Post by cnity »

eru wrote: post #143
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…

Interestingly, RiscV goes with 1/0 = 0xFFFF_FFFF (in 32 bit mode). I guess that's slightly more of a warning than giving 0.

It also seems more mathematically appropriate because it is as close to the limit of the reciprocal as one can get with that representation. Now please allow me to duck before being struck by the tomatoes of mathematicians.

Re: 1/0 = 0 (2018)

#170

Post by glitchc »

iforgotpassword wrote: post #118
pasquinelli wrote: post #97

Earlier quoted context omitted.

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.

It's more like you had five apples and divided them among zero people, which means not even you get to keep them. They were thrown in the trash instead. The answer is zero.
Post reply on HN