Live data from Hacker News

1/0 = 0 (2018)

hillelwayne.com

221–230 of 245 posts

Re: 1/0 = 0 (2018)

#221
post #15

Earlier quoted context omitted.

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.

You seem to have your axes confused. The value of y can’t be “the y-axis”, which is the line x = 0 (for all values of y).

Re: 1/0 = 0 (2018)

#222

Maybe division by zero should just not exist. If you actually write 1/0 in a manner that can be discovered through static analysis, that could just be a compile time error. If you compute a zero, and then divide by it… I dunno. Probably what happened was the denominator rounded or truncated to zero. So, you actually have 1/(0+-e), for some type-dependent e. You have an interval which contains a ton of valid values, w…

I think it would be possible and practical to use refinement types to statically prevent all divisions by 0. I think you could also do this to detect and prevent integer overflow.

Not really. You could divide by the subtraction result of two positive integers.

Re: 1/0 = 0 (2018)

#223
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 remember my junior high maths well enough, allowing division by zero is an essential step in proving that 1 == 2, which we _definitely_ don't want.

Re: 1/0 = 0 (2018)

#224

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…

This is, in some sense, calculus. Look at 0z, which is 0/0, which calculus treats with l'hopitals rule. Another way of looking at it is to say that 0 is dt, then z is 1/dt. Clearly we can have different 0s, so we might name another dx, then take dx/dt, which is an arbitrary derivative.

Re: 1/0 = 0 (2018)

#225

Earlier quoted context omitted.

Strongly agree here. IMO libraries should try hard to return sensible error codes (within reason, eg null pointer access is unrecoverable imo) but application code should just crash. And when a library returns an error code, default to just crashing if it fails until you have a compelling reason to do something more complicated.

Yes but here's the conflict. You design a typed language, you want the primary operators to be type stable so you can compose them. Then there's no room to return an error from a basic operation. So if your language also makes it a priority to NEVER CRASH, you are stuck.

Right, for arithmetic operations, you must have one of:

1. Might crash.

2. Result may not be what you’d expect from conventional math.

3. Inputs and outputs are different types.

4. Nonlinear control flow i.e. exceptions.

Division isn’t even particularly special here. If you have fixed-width integer types (as most languages seem to) then this is a problem for all the basic operators.

3 and 4 are attractive solutions but can get annoying or cause more bugs. (How many catch blocks out there have zero test coverage?) Between 1 and 2, 1 is usually much better.

For cases where the programmer wants 2, you can provide alternate operators. For example, Swift crashes on overflow or with the standard operators, but has variants like &+ for modular arithmetic.

Re: 1/0 = 0 (2018)

#226
post #168

Earlier quoted context omitted.

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.

It's probably due to how division is implemented, by shifting the divisor and subtracting it from the remainder. Subtracting (0 Intel's 80186 produced a result like that in one special case, because of a missing check in the microcode. This could be called a bug or an optimization: the "AAM" instruction was only documented as dividing by 10, but in fact takes a divisor as part of its opcode (D4 0A = divide by 10, as…

> It's probably due to how division is implemented, [...]

Or rather how division could be implemented. Risc-V is an abstract instruction set architecture not born from a concrete chip, like x86 was; but they are trying to make things easy on the hardware.

Re: 1/0 = 0 (2018)

#227
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

You have never met Steve Chow, the BlackPenRedPen bloke on YouTube, then. (-:

https://youtube.com/watch?v=n1ZLag56sAo

Re: 1/0 = 0 (2018)

#228
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.

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.

Re: 1/0 = 0 (2018)

#229
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.

The OP uses finite fields and fields are basically harmonic structures (think modular math). Assume the field is the numbers 0..n-1 MOD n. At (n-1) + 1 you will get n MOD n which is equivalent to 0 MOD n which is 0. Now assume n-1 approaches infinity; is 0 not ∞ ?

Re: 1/0 = 0 (2018)

#230

Earlier quoted context omitted.

on computers you can have negative zeros

Negative zero is equal to zero, so it's not really a distinct number, just another representation of the same value.

-0 is a notation for 1 / -infinity, so it is distinct. For addition it is not.
Post reply on HN