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!
This is not generally true. 5/2 = 2, 50/20 = 2, 500/200 = 2, and so on no matter how big the numbers get.
print(math.MinInt / -1)
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.
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.
Also just to point out, the statement here really is a*b‾*b=a, which might make it more clear why b≠0.
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.
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.
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.
>>> 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
>>> a, b = 0.7959754927336106, 0.7345016612407793
>>> a == b * (a / b)
False
>>> a
0.7959754927336106
>>> b * (a / b)
0.7959754927336105
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
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".
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.
It’s all just definitions. Always has been.
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.
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).