Live data from Hacker News

1/0 = 0 (2018)

hillelwayne.com

141–150 of 245 posts

Re: 1/0 = 0 (2018)

#141
post #32

Earlier quoted context omitted.

> What I can't do is write a programming language where I use the universally recognised "+" symbols for this operation, call it "addition" and claim that it's totally reasonable. As a programmer, you're right: we have standard expectations around how computers do mathematics. As a pedant: Why not? Commonly considered 'reasonable' things surrounding addition in programming languages are: * (Particularly for older pro…

> I haven't yet encountered a language which solves this issue: Well, Python supports arbitrary precision integers. And some other niche languages (Sail is one I know). I don't think "running out of memory" counts as a caveat because it still won't give the wrong answer. For floats, I don't think it's actually unreasonable to use different operators there. I vaguely recall some languages use +. or .+ or something for…

> Well, Python supports arbitrary precision integers. And some other niche languages (Sail is one I know).

As a Lisper, I very carefully chose an example to account for arbitrary-precision integers (so X + X where X is, say, 8^8^8^8 (remember, exponentiation is right-associative, 8^8^8^8 = 8^(8^(8^8)))).

> I don't think "running out of memory" counts as a caveat because it still won't give the wrong answer.

Being pedantic, it doesn't give the _correct_ answer either, because in mathematics 'ran out of memory' is not the correct answer for any addition.

Re: 1/0 = 0 (2018)

#142

Earlier quoted context omitted.

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.

Division by zero is perfectly well defined in floating point. x/0 = INF and INF*0 = NaN. That means b*(a/b) != a if b = 0. It's true that it's not defined for integer types, but that wouldn't make a = b*(a/b) true for them either. It's also common to define x/0 = infinity in the extended real numbers that floating point models.

In floating point a = b * (a / b) is not always a true statement.

  >>> import random
  >>> random.random()
  0.4667867537470992
  >>> n = 0
  >>> for i in range(1_000_000):
  ...   a = random.random()
  ...   b = random.random()
  ...   if (a == b * (a / b)):
  ...     n += 1
  ...
  >>> n
  886304
For example:

  >>> a, b = 0.7959754927336106, 0.7345016612407793
  >>> a == b * (a / b)
  False
  >>> a
  0.7959754927336106
  >>> b * (a / b)
  0.7959754927336105
This is off by one ulp ("unit in the last place").

And of course the division of two finite floating point numbers may be infinite:

  >>> a, b = 2, 1.5e-323
  >>> a
  2
  >>> b
  1.5e-323
  >>> b * (a / b)
  inf
  >>> a/b
  inf
As a minor technical point, x/0 can be -INF if sgn(x) < 0, and NaN if x is a NaN.

Re: 1/0 = 0 (2018)

#143

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.

Re: 1/0 = 0 (2018)

#144

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 better as you don't even try to divide by zero, but not sure how many languages can represent `number - 0` as a type.

Re: 1/0 = 0 (2018)

#145

Sounds legit, infinity is singular and so is 0. I think one problem is also that division isn't the only mathematical operation which can produce dubious results. E.g. sqrt(x), arctan(x) which have multiple branches which is why there is often a separate arctan2(x, y) to select the correct branch. Oh well and then there's just addition which silently overflows in almost every programming language. Without arbitrary p…

Why is infinity singular? There's at least positive and negative infinity.

And why do you bring up infinity? In regular math, 1/0 is literally undefined. It's not infinity.

Re: 1/0 = 0 (2018)

#146
post #72
post #68

Earlier quoted context omitted.

If 0 is not an allowable value for b is necessary but not generally sufficient.

Can you say more? If "0 is not an allowable value for b", then it seems to me that (a/b)*b=a isn't true for all values. Specifically, it's false when b=0. IIUC, codeflo is arguing that the division operation defined in the article isn't "actual division" because (a/b)*b=a isn't true for all values. But I can't think of a definition of division that satisfies that criteria.

We don't allow division of apples and oranges, either. So why is excluding 0 weird, but excluding ice cream as an argument is not?

Re: 1/0 = 0 (2018)

#147

Earlier quoted context omitted.

I don't want to handle errors after every division and division doesn't crash, both sound rather practical, though.

The original purpose of defining it to be Nan/INF in floating point was exactly that. You'd do all the work and then check if it was Nan/INF at the end without having to check every intermediate result.

If you want to do all the work at the end, 'exceptions' do exactly that, too.

Re: 1/0 = 0 (2018)

#148

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…

All Rust's primitive integer types have a corresponding non-zero variant, NonZeroU8, NonZeroI32, NonZeroU64, NonZeroI128 etc. and indeed NonZero is the corresponding type, for any primitive type T if that's useful in your generic code.

Re: 1/0 = 0 (2018)

#149

Earlier quoted context omitted.

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

It's equal (as in, comparing them with == is true), but they are not the same value. At least in IEEE 754 floats, which is what most languages with floating point numbers use. E.g., in JS: > 1 / 0 Infinity > 1 / -0 -Infinity > 0 === -0 true > Object.is(0, -0) false

Yes.

In a language like C or Rust, you can cast your +0.0 and -0.0 to an integer, and print out the bit pattern. They are different.

Re: 1/0 = 0 (2018)

#150

Sounds legit, infinity is singular and so is 0. I think one problem is also that division isn't the only mathematical operation which can produce dubious results. E.g. sqrt(x), arctan(x) which have multiple branches which is why there is often a separate arctan2(x, y) to select the correct branch. Oh well and then there's just addition which silently overflows in almost every programming language. Without arbitrary p…

Hilbert's Hotel shows nicely that infinity can't be singular.
Post reply on HN