231–240 of 245 posts
Earlier quoted context omitted.
Throwing an exception in a function normally stops the rest of the work that function would do. That is not the case when using Inf and similar > const f = (x) => [x/2, x/0] undefined > f(10) [ 5, Infinity ]
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.
Earlier quoted context omitted.
If you want to do all the work at the end, 'exceptions' do exactly that, too.
Throwing an exception in a function normally stops the rest of the work that function would do. That is not the case when using Inf and similar > const f = (x) => [x/2, x/0] undefined > f(10) [ 5, Infinity ]
Earlier quoted context omitted.
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.
MySQL has ignored math rules for ages as well. 1/0 yields NULL there
What's wrong with that? It's mathematicaly undefined. SQL dialects typically return NULL for erroneous operations. Plus, it's not like it's returning 0 or some other numeric-typed value
SQL returns NULL if any input value into an expression is NULL, not if an invalid operation is attempted. If the expression contains an error, SQL throws an error, it doesn't return NULL.
The SQL standard requires to error out in this case.
Also: I don't know of any system that would not result in an error when you try to divide something by zero.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
If I have five apples and were to divide them among 0 people then nobody gets anything and I can eat them all, so the proper solution would be 5.
It's more like you had five apples and divided them among zero people, which means not even you get to keep them. They were thrown in the trash instead. The answer is zero.
Which would be infinite, since ghosts occupy no space and can't interact with physical reality.
As a proportion, compared to nonexistence, any quantity of something is infinitely greater than nothing, so if not n/0, how would you express you expect not the absence of a thing, but its nonexistence?
Earlier quoted context omitted.
But why would we go from what obviously should be a very large boundless number and just replace it with 0. Our few comment discussion is why it’s undefined in a nutshell.
The main issue lies in weakening the field axioms to accommodate any strange new numbers. Instead, defining division by 0 to 0 adds no new numbers, so the field axioms don't change (x/x=1 still requires x≠0). I hope you see the value in extending field theory instead of changing field theory. If we add new numbers like ∞, -∞, and NaN (as the neighbor comment suggests with IEEE754-like arithmetic), now x/x=1 requires…
I’m not suggesting that we add numbers or change the definition from undefined. I think undefined is a more accurate description of x/0, because x/0 is clearly far greater than 0.
Earlier quoted context omitted.
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 depend…
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.
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…
1/0 = 0 is usually not a practical thing, it's to satisfy that the output of the division operator stays in the type and you don't want crashes (a "feature" of ponylang and gleam, e.g.). Its kind of a PL wonk thing. It's not at all a good idea for very important practical reasons as I outline in a reply to parent.
https://en.wikipedia.org/wiki/Projectively_extended_real_lin...
Earlier quoted context omitted.
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.