Live data from Hacker News

1/0 = 0 (2018)

hillelwayne.com

241–245 of 245 posts

Re: 1/0 = 0 (2018)

#241
post #3

As long as lim(1/x)_x->0 = inf, 1/0 = 0 doesn't make a whole lot of sense, mathematically speaking. I might be wrong but I don't think it was addressed in the article either.

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…

There's no real problem here. Infinity - Infinity is not 0; it's probably best to simply call it Infinity as well.

[ok] 1. Infinity + 1 == Infinity + 2

[ok] 2. Infinity + 1 - Infinity == Infinity + 2 - Infinity

[wrong] 3a. 1 == 2 (assumes Infinity - Infinity == 0, which is false)

[ok] 3b. Infinity == Infinity

So starting from Infinity + 1 == Infinity + 2 gets you nowhere interesting.

And that quote is a great example of what I hate about every pop-sci treatment of mathematics:

> Because infinity in mathematics isn't actually a number, it's a direction

Any time someone says "actually, in mathematics, ..." they're talking out of their ass. No matter what comes after, there is a different system of math that makes their statement false. There are plenty of branches of mathematics that are perfectly happy with infinity being a "number", not a "direction". What even is a "number" anyway?

Re: 1/0 = 0 (2018)

#242
post #231
post #202

Earlier quoted context omitted.

I assert stopping immediately is much more practical. In many cases, you waste considerable amounts of processing power to reach a conclusion you often won't be able to use.

It depends on your use case.

Sure but what should be the default?

Re: 1/0 = 0 (2018)

#243

Earlier quoted context omitted.

One intuition could be: As you divide 1 by negative numbers of smaller and smaller magnitude, you get negative numbers of increasing magnitude. At 0, the positive infinity of 1/0 is met by the negative infinity of 1/-0 and their average is 0.

why take averages?

Well, it would be simultaneously at both extremes.

Re: 1/0 = 0 (2018)

#244
post #231

Earlier quoted context omitted.

It depends on your use case.

Sure but what should be the default ?

Rust and Haskell can solve this fairly well: both styles of dealing with errors are easily accessible.

Go solves this really badly.

As for specifically what to do about division: the right default depends on your application. Either way is defensible, and I would rather work on making it easy to pick either style in the language of your choice, than to worry too much about what the default should be.

Re: 1/0 = 0 (2018)

#245
post #235

Earlier quoted context omitted.

Rather than removing 0 from a numeric type, we can avoid including it at all. For example, we can have a bunch of numeric types like: Positive = One | Succ Positive Nat = Zero | Positive NonZeroInt = Positive | Neg Positive Int = Zero | NonZeroInt Rational = Ratio Int Positive etc. Depending on the language, these could be implemented with little or no runtime overhead.

I'm trying to have fun continuing this with the reals, and I'm feeling dizzy.

Remember that "almost all" of the Reals are unrepresentable using finite sequences of symbols, since the latter are "only" countably infinite. The next logical step is probably the Radicals (i.e. nth roots, or fractional powers).

I know that nested radicals can't always be un-nested, so I don't think larger sets (like the Algebraic numbers) can be reduced to a unique normal form. That makes comparing them for equality harder, since we can't just compare them syntactically. For large sets like the Computable numbers, many of their operations become undecidable. For example, say we represent Computable numbers as functions from N -> Q, where calling such a function with argument x will return a rational approximation with error smaller than 1/x. We can write an addition function for these numbers (which, given some precision argument, calls the two summand functions with ever-smaller arguments until they're within the requested bound), but we can't write an equality function or even a comparison function, since we don't know when to "give up" comparing numbers like 0.000... == 0.000....

FYI I'm currently playing around with numerical representations at http://www.chriswarbo.net/blog/2024-11-03-rationalising_deno...

Post reply on HN