Reusing symbols like +, *, or / to define operations that aren't the + or the / you're used to is pretty common in math. It's just notation.

At the end of the day, the / that we have in programming has the same problem as this article's /, almost all programming languages will return 5/2 = 2 when dividing integers, even though 2 * 2 is not 5! Division is not defined for all integers, but it's just convenient to extend it when programming.

So if some languages want to define 1/0 = 0, we really shouldn't be surprised that 0*0 is not 1, we already had the (a/b)*b != a problem all along!

That's nonsense. a/b is float in Python 3, and even in other languages a/b gets closer to it's actual value as a and b get bigger (the "limit", which is the basis of Algebra). So four operations in programming generally do agree with foundations of Algebra. But a/0=0 is %100 against Algebra. And it's very unintuitive. It's basically saying zero is the same as infinity, and therefore all numbers are the same, so why bother having any numbers at all?

> even in other languages a/b gets closer to it's actual value as a and b get bigger (the "limit", which is the basis of Algebra)

This is not generally true. 5/2 = 2, 50/20 = 2, 500/200 = 2, and so on no matter how big the numbers get.

Yes, I meant when the result gets bigger. You get the idea.

What's the output of this Go program, without going to the playground link?

  print(math.MinInt / -1)

https://go.dev/play/p/Vy1kj0dEsqP

Floats don't have multiplicative inverses, and the floating point operations don't give us any of the mathematical structures we expect of numbers. Floating point division already abandons algebra for the sake of usefulness.

Knuth vol 2 has a nice discussion of floating point operations and shows how to reason about them. Wilkinson's classic "Rounding Errors in Algebraic Processes" (1966) also has a good discussion.

If you were to define a/0 the most logical choice would be a new special value "Infinity". The second best choice would be the maximum supported value of the type of a (int, int64 etc). Anything else would be stupid.

What if a is negative?

Same. Unless you want to differentiate -0 and +0 (which make it more complicated), you can not distinguish infinity from negative infinity.

IEEE floating point representation does both

John Conway can

> Reusing symbols like +, *, or / to define operations that aren't the + or the / you're used to is pretty common in math. It's just notation.

Reusing symbols in a different context is pretty common; taking a symbol that is already broadly used in a specific way (in this case, that `a/b` is defined for elements in a field as multiplying `a` by the multiplicative inverse of `b`) is poor form and, frankly, a disingenuous argument.

I am a professor for algebra at a research university. I make a point out of teaching my students that `a/b` is NOT the same as multiplying `a` by the multiplicative inverse of `b`.

The standard example is that we have a well-defined and useful notion of division in the ring Z/nZ for n any positive integer even in cases were we "divide" by an element that has no multiplicative inverse. Easy example: take n=8 then you can "divide" 4+nZ by 2+nZ just fine (and in fact turn Z/nZ into a Euclidean ring), even though 2+nZ is not a unit, i.e. admits no multiplicative inverse.

Multiplicative inverse happens to be a convenient way to define division in the reals, but there are cases when multiplicative inverses do not correspond to any notion of division. E.g. take a finite ring of integers, like what you’d use for cryptography or heck any operation on an `int`!

It’s all just definitions. Always has been.

Under what definition of division is (a/b)*b=a true for all values?

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.

When we say "is not an allowable value", we are speaking about the domain [1]: all the values for which the function is defined. When we say "for all values", we implicitly mean for all values of the domain.

The parallel in programming would be the contract : you provide a function that works on a given set of values. Or the type: the function would "crash" if you passed a value not of the type of its parameter, but it is admitted it won't be done.

(In the remaining I'm referring to 1/x instead of a/b to simplify things a bit)

Another way of saying it is that the function is undefined for 0. (Or on {0}). Then the property is true for all values (on which the function is defined, but saying it is redundant, the function can't be called outside its domain, it is an error to try to do this).

The domain is often left out / implicit, but it is always part of the definition of a function.

0 is not in the domain, so it's not to be considered at all when studying the function (except maybe when studying limits, but the function will still not be called with it).

[1] https://en.m.wikipedia.org/wiki/Domain_of_a_function

If "0 is not an allowable value for b", then (a/b)*b=a is not defined when b=0, so it is neither true nor false, since you had previously agreed that b=0 is not allowed (regardless of what "/" and "*" are meaning in this context).

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?

The one that excludes 0. It's not a terribly complicated thing to restrict domain: you don't expect, for example, complex values in real-valued functions.

(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.

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.

The definitions in the floating point standard make much more sense when you look to 0/INF as "something so close to/far from 0 we cannot represent it", rather than the actual concepts of 0 and infinity.

The limit 1/x as x goes to zero diverges to plus or minus infinity depending on whether you approach from the right or the left. IEEE 754 uses a signed zero, so defining 1/+0 = +INF and 1/-0 = -INF makes sense. If you do not have a signed zero, arbitrarily picking either plus or minus infinity makes much less sense and picking their "average" zero seems more sensible. So x/0 is not actually +INF - even if you meant +0 and we forget about -0 - it is +INF or -INF depending on the sign of x and NaN if x is +0 or -0.

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.

TFA was about mathematics, not computer programs. Mathematically, the limit as b approaches 0 of a/b is defined to be +/- INF depending whether a and b have matching signs. The limit represents the value that a/b asymptotically approaches as b approaches 0. a/b for b=0 is still undefined.

For a good example of why this needs to be undefined, consider that limit as b approaches zero of a/b is both +INF and -INF depending on whether b is "approaching" from the side that matches a's sign or the opposite side. At the exact singularity where b=0 +INF and -INF are both equally valid answers, which is a contradiction.

also in case you weren't aware, "NaN" stands for "not a number".

You might have noticed that TFA was discussing a programming language, Pony, that uses floating point. The behavior of the reals isn't relevant.

In the extended reals case I mentioned, it's a definition used when working on the positives. Didn't think I needed to state the obvious.

Pony is what prompted TFA to consider whether or not 1/0 should be defined. It's not what the article is about. Obviously anybody who writes a compiler can define / to have a specified behavior for a zero divisor; TFA is about whether that's correct. There's nothing significant about IEEE 754 choosing to define an operation that's nominally undefined, as it does not have any bearing on whether or not that behavior is correct.