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

151–160 of 245 posts

Re: 1/0 = 0 (2018)

#151

Post by MereInterest »

morningsam wrote: post #134
giraffe_lady wrote: post #125

Earlier quoted context omitted.

They're valid according to a spec that doesn't mean I want one showing up when I'm trying to calculate the area of a semicircle or whatever. In the context of getting one by surprise in simple arithmetic they are approximately as bad as zero. Either way you have to decide how to handle it and there are tradeoffs of different approaches, as the article discusses. It's not about someone just being ignorant of basic mat…

>In the context of getting one by surprise in simple arithmetic they are approximately as bad as zero. I don't think so, because getting 0 in a larger expression might yield a result that looks plausible, leading to hidden bugs. Inf and NaN both are good because they necessarily propagate all the way up to the end result, making it obvious that something went wrong.

Technically, it is possible for floating-point Inf to stop propagating prior to the final result, depending on the operation. For example, 1/Inf produces zero, as does exp(-Inf).

But those are cases where the larger a value is, the less is contributes to the final value.

Re: 1/0 = 0 (2018)

#152

Post by rsp1984 »

_carbyau_ wrote: post #103
rsp1984 wrote: post #31

Earlier quoted context omitted.

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…

Good point.

Re: 1/0 = 0 (2018)

#153

Post by movpasd »

This is all well and fine, but feels like a lot of words to say "it's a matter of definition".

The question is what definitions will be useful and what properties you gain or give up. Being a partial function is a perfectly acceptable trade-off for mathematics, but perhaps it makes it difficult to reason about programs in some cases.

I suppose the aim of the article is to point out the issue is not one of soundness, which is useful — but I wish more emphasis had been put on the fact that it doesn't solve the question of what 1/0 should do and produced arguments with regards to that.

Re: 1/0 = 0 (2018)

#154

Post by zokier »

amavect wrote: post #69
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?

Saying 1/0=∞ means creating a new number system with ∞ as a number. Now you have to figure out all operations with ∞, like -1*∞, 0*∞, ∞*∞, ∞/∞, or ∞-∞. Making wrong definitions creates contradictions. With 1*x=x, ∞/∞=1, the associative property x*(y/z)=(x*y)/z, and ∞*∞=∞: ∞ = ∞*1 = ∞*(∞/∞) = (∞*∞)/∞ = ∞/∞ = 1

that's largely solved problem. ieee758 defines consistent rules for dealing with infinities. even if don't use the floating-point parts and made a new integer format, it almost certainly would make sense to lift ieee754 rules as-is.

Re: 1/0 = 0 (2018)

#155

Post by TapamN »

thaumasiotes wrote: post #43
Asooka wrote: post #35

Earlier quoted context omitted.

Those are all integers. https://en.wikipedia.org/wiki/Modular_arithmetic - "The modern approach to modular arithmetic was developed by Carl Friedrich Gauss in his book Disquisitiones Arithmeticae, published in 1801." They have been integers for over 200 years now.

Wrapping around is correct integer behavior; clamping ("5 + 1 = 5") isn't. Clamping implies immediately that all positive numbers are equal to zero.

True correct behavior would have that if a > b, then a + c > b + c also holds true for all integers, but that isn't guaranteed for wrapping (or clamping.) (e.g. if 250 > 1, then 250 + 10 > 1 + 10 should be true, but with 8-bit wrapping you would get 4 > 11, which is false.)

Re: 1/0 = 0 (2018)

#157

Post by JumpCrisscross »

oDot wrote: post #111
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

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.

Re: 1/0 = 0 (2018)

#160

Post by red_admiral »

EDIT: markup broke my operators

In combinatorics and discrete probability, `0**0 = 1` is a useful convention, to the point that some books define a new version of the operator - let's call it `***` - and define `a***b = a**b` except that `0***0 = 1` and then use the new operator instead of exponentiation everywhere. (To be clear, `**` is exponentiation, I could write `a^b` but that is already XOR in my mind.)

So one might as well overload the old one: tinyurl.com/zeropowerzero

This causes no problems unless you're trying to do real (or complex) analysis.

1/0 can cause a few more problems, but if you know you're doing something where it's safe, it's like putting the Rust `unsafe` keyword in front of your proof and so promising you know what you're doing.

Post reply on HN