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

101–110 of 245 posts

Re: 1/0 = 0 (2018)

#101

Post by throwawaymaths »

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.

Re: 1/0 = 0 (2018)

#102

Post by acjohnson55 »

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.

Did you fully read the article?

In modern math, the concept of a field establishes addition and multiplication within its structure. We are not free to redefine those without abandoning a boatload of things that depend on their definition.

Division is not inherent to field theory, but rather an operation defined by convention.

It seems like you're fixating on the most common convention, but as Hilel points out, there is no reason we have to adopt this convention in all situations.

Re: 1/0 = 0 (2018)

#103

Post by _carbyau_ »

rsp1984 wrote: post #31
lupire wrote: post #8

Earlier quoted context omitted.

It's fine. Infinity isn't a real number, so 1/x isn't continuous at 0, so it doesn't matter what the value of 1/0 is. All your open sets still behave the way you expect. Whether you choose "this function is undefined here" vs "it's impossible to ever reach the value of this function at this value, under any assumptions I'll ever care about" is purely a matter of convenience.

Yea, but conceptually it's a bit smelly to have f(x) get larger and larger the closer x is to 0 and then suddenly have it be 0 once x reaches 0.

As others have pointed out "larger and larger" is the same when it is negative too. So I think people are just going: positive infinity + negative infinity = 0.

Intuitively nice in a sense but I honestly think '0' is misrepresenting what is going on here. I'm ok with it being ' "+ and/or -" infinity' as a new definition.

Programmatically I think it should result in a NULL or VOID or similar. I mean, by definition it has no definition.

Re: 1/0 = 0 (2018)

#104

Post by gregschlom »

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…

It's funny, I hold the exact opposite opinion, but from the same example: In the course of my programming career, I've had at least 3 different instances where I crashed stuff in production because I was computing an average and forgot to handle the case of the empty list. Everything would have been just fine if dividing by zero yielded zero.

I've learned my lesson since, but still.

Re: 1/0 = 0 (2018)

#105

Post by thaumasiotes »

sgentle wrote: post #79
TrianguloY wrote: post #33

I've always wondered what would happen if we defined /0 as a new symbol, for example 'z'. The same as we define sqrt(-1) as 'i'. So if you can do 4*sqrt(-1)=4i, you could also do 4/0 = 4z. These two seems similar, as in taking something that should not exist, and just letting it exists in a totally different and orthogonal domain. I tried once to investigate the implications, but it quickly became far more complex th…

You might be interested in the hyperreal numbers, which sound a bit like the avenue you were exploring.

You can't divide by zero in the hyperreals any more than you can in the reals.

Re: 1/0 = 0 (2018)

#106

Post by thaumasiotes »

daft_pink wrote: post #66

Wouldn’t the logical value when dividing by zero be infinity, because zero can go into any number an infinite number of times?

> Wouldn’t the logical value when dividing by zero be infinity, because zero can go into any number an infinite number of times?

No, just look at the graph of f(x) = 1/x. +inf can't work.

It can work if you assume that no numbers are ever negative.

Re: 1/0 = 0 (2018)

#107

Post by [deleted] »

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…

[deleted]

Re: 1/0 = 0 (2018)

#108

Post by jsnedjdn »

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

Re: 1/0 = 0 (2018)

#109

Post by throwawaymaths »

gregschlom wrote: post #104
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…

It's funny, I hold the exact opposite opinion, but from the same example: In the course of my programming career, I've had at least 3 different instances where I crashed stuff in production because I was computing an average and forgot to handle the case of the empty list. Everything would have been just fine if dividing by zero yielded zero. I've learned my lesson since, but still.

What was the problem with crashing? Surely you had Kubernetes/GCP/ECS restart your container, or if you're using a BEAM based language, it would have just restarted

> Everything would have been just fine if dividing by zero yielded zero

perhaps you weren't making business decisions based on the reported average, just logging it for metrics or something, in which case I can see how a crash/restart would be annoying.

Post reply on HN