24 ms·

1/0 = 0 (2018)

135 points by revskill 2y ago

enriquto 2y ago
I'd agree to some kind of 1//0=0 for ints; but for floats you'll take 1/0=inf from my cold, dead hands.
rsp1984 2y ago
As long as lim(1/x)_x->0 = inf, 1/0 = 0 doesn't make a whole lot of sense, mathematically speaking. I might be wrong but I don't think it was addressed in the article either.
- lupire 2y ago
  It's fine. Infinity isn't a real number, so 1/x isn't continuous at 0, so it doesn't matter what the value of 1/0 is. All your open sets still behave the way you expect. Whether you choose "this function is undefined here" vs "it's impossible to ever reach the value of this function at this value, under any assumptions I'll ever care about" is purely a matter of convenience.
  - rsp1984 2y ago
    Yea, but conceptually it's a bit smelly to have f(x) get larger and larger the closer x is to 0 and then suddenly have it be 0 once x reaches 0.
    - renewiltord 2y ago
      But once you go behind, it flips suddenly anyway so you could just as well have it be intuitively “halfway between the positive and negative infinities” which is at least fun and could spawn a few “Why is 1/x suddenly go to zero” articles on HN in 2053
    - _carbyau_ 2y ago
      As others have pointed out "larger and larger" is the same when it is negative too. So I think people are just going: positive infinity + negative infinity = 0. Intuitively nice in a sense but I honestly think '0' is misrepresenting what is going on here. I'm ok with it being ' "+ and/or -" infinity' as a new definition. Programmatically I think it should result in a NULL or VOID or similar. I mean, by definition it has no definition.
      - rsp1984 2y ago
        Good point.
  - Turneyboy 2y ago
    Well if you consider 1/z as a function of a complex coordinate it definitely makes a lot of sense to set it to infty. That identifies +infty and -infty if you restrict yourself to the real numbers.
- CharlieDigital 2y ago
  There's a great Radiolab episode[0] that talks about divide by zero in perhaps more conceptual terms. KARIM ANI: If you take 10 and divide it by 10, you get one. 10 divided by five is two. 10 divided by half is 20. The smaller the number on the bottom, the number that you're dividing by, the larger the result. And so by that reasoning ... LULU: If you divide by zero, the smallest nothingness number we can conceive of, then your answer ... KARIM ANI: Would be infinity. LULU: Why isn't it infinity? Infinity feels like a great answer. KARIM ANI: Because infinity in mathematics isn't actually a number, it's a direction. It's a direction that we can move towards, but it isn't a destination that we can get to. And the reason is because if you allow for infinity then you get really weird results. For instance, infinity plus zero is ... LATIF: Infinity. KARIM ANI: Infinity plus two is infinity. Infinity plus three is infinity. And what that would suggest is zero is equal to one, is equal to two, is equal to three, is equal to four ... STEVE STROGATZ: And that would break math as we know it. Because then, as your friend says, all numbers would become the same number. [0] https://radiolab.org/podcast/zeroworld https://radiolab.org/podcast/zeroworld
  - v4vvdq 2y ago
    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.
    - WithinReason 2y ago
      on computers you can have negative zeros
      - recursive 2y ago
        Negative zero is equal to zero, so it's not really a distinct number, just another representation of the same value.
        2y ago
- v4vvdq 2y ago
  I was also looking for this. And would like to add: lim(-1/x)_x -> 0 = -inf That is (in my opinion) the whole point why it is actually undefined. On one side of the y-axis it goes to infinity, on the other to minus infinity. I don't see a solution to this and therefore always have accepted that it is undefined.
  - lupire 2y ago
    No. 1/x^2 is undefined at 0 but has the same limit behavior, because limit behavior is not a function from "pairs of (functions from R to R, R)" to R Infinity is not a real number.
    - ganzuul 2y ago
      Can limit behavior be defined as Cauchy sequences?
- deleted 2y ago
  [deleted]
- judofyr 2y ago
  The arguments around limits are addressed towards the end (under "Update 8/12/2018"): > > If 0/0 = 0 then lim_(x -> 0) sin(x) / x = sin(0) / 0 = 0, but by L’Hospitals’ Rule lim_(x -> 0) sin(x) / x = lim_(x -> 0) cos(x) / 1 = 1. So we have 0 = 1. > This was a really clever one. The issue is that the counterargument assumes that if the limit exists and f(0) is defined, then lim_(x -> 0) f(x) = f(0). This isn’t always true: take a continuous function and add a point discontinuity. The limit of sin(x) / x is not sin(0) / 0, because sin(x) / x is discontinuous at 0. For the unextended division it’s because sin(0) / 0 is undefined, while for our extended division it’s a point discontinuity. Funnily enough if we instead picked x/0 = 1 then sin(x) / x would be continuous everywhere. Similar examples can be constructed for any regular function which is discontinuous (e.g. Heaviside step function).
lupire 2y ago
https://xenaproject.wordpress.com/2020/07/05/division-by-zero-in-type-theory-a-faq/ https://xenaproject.wordpress.com/2020/07/05/division-by-zer... explains Lean's behavior. Basically, you use a goofy alternate definition of division (and sqrt, and more), and to compensate you have to assume (or prove based on assumptions) that the things you will divide by are never zero. Hillel's pedantry is ill-taken, though, because he starts off with a false accusation that the headline tweet was insulting anyone. Also, 1/0=0" is sound only if you change the field axiom.of division, which is fine, but quite rather hiding the ball. If you add " 1/0=0" as an axiom to the usual field axioms, you do get an unsound system.
moomin 2y ago
Honestly this hurts my head but Hillel is inevitably correct. You can define an explicitly undefined operation to do whatever you like. But what’s the point? There’s no new mathematics you can do with it, no existing behaviours you can extend like this. Normally, when you divide by a small number, you get a large number. Now for some reason it goes through zero. Why not five? Why not seven? Just because it’s formally consistent doesn’t mean it isn’t dumb.
- lupire 2y ago
  Because exceptions are expensive, and functions with holes are dumb. "Dumb" is purely a matter of aesthetic preference. Calling things "dumb" is dumb. > Normally, when you divide by a small number, you get a large number. Now for some reason it goes through zero. Zero is not a "small" number. Zero is the zero number. There is no number that is better result than 0 when dividing by 0; "Infinity" is not a real (or complex) number. This itself is GREAT reason to set 1/0 = 0. It only ever bothers people who conflate open sets with closed sets, or conflate Infinity with real numbers, so it's good have this pop up to force people to think about the difference.
  - recursive 2y ago
    > Zero is not a "small" number. Zero is the zero number. What do you mean by this? Zero is certainly a zero number, but it seems that it might also be a small number simultaneously.
    - thaumasiotes 2y ago
      For example, zero is the only real infinitesimal value.
  - akira2501 2y ago
    Sure.. but there are infinite series that sum to a finite value. Perhaps a pertinent example would be summing all the distances between each successive reciprocal of 1: Sum[1/x - 1/(x+1), {x, 1, ∞}] == 1 You do actually need infinity to arrive at that 1.
croes 2y ago
It’s unexpected and that makes it dangerous.
jvanderbot 2y ago
Q on this post: Is the field rule "Every element Except Zero has ... " (the 9th rule) defined with respect to the additive identity "zero" or the magical other undefined "Zero" that is the number we're all familiar with? If so, how weirdly arbitrary that the additive zero is omitted for all multiplicative inverse definitions. (At least it seems to me). I always figured this was a consequence of our number systems, not of all fields.
- lupire 2y ago
  I am not familiar with any "magical other undefined Zero". Please familiarize me :-) What is your, uh, definition of this undefined* number you are familiar with?
  - jvanderbot 2y ago
    > Every element EXCEPT 0 has a multiplicative inverse, a⁻, such that a*a⁻ = 1. What is "0"? It's not defined in the axioms other than additive zero. Or is it multiplicative zero? (1?). Is it the number zero? If it is the additive zero defined in axiom (3), then it just seems weird to me that additive zero is undefined for multiplicative inverse for all fields always and forever. If it is the number zero, then how does that generalize to other fields? If the answer is "Numbers are the first field and all fields generalize that", then I suppose we are referring to the number (0), and that's fine, as other fields are welcome to define their own larger definition of zero that includes the number (0) ... ?
    - kaoD 2y ago
      "Zero" is just a specific element of the field which satisfies being the additive identity as well as the rest of the properties of a field where 0 is mentioned. When the rest of the axioms refer to "zero" they refer to the exact same element of the set that is also the additive identity. It's not the "number zero" because a field does not care about numbers, it's just elements of a set (which might be numbers like in R's case). 1 is not "multiplicative zero", it's the "multiplicative identity". 0 and 1 are just the shorthand we give for those elements. because those are the symbols we use in R which is the most common field we deal with in everyday life. Or am I misunderstanding your question?
jmclnx 2y ago
I set this to zero and print a warning/error about divide by zero on the log with data that caused it. That log would be sent to the business person worry about. If they ignore it, I do not care, it is the business problem anyway. Worked for me for decades :)
codeflo 2y ago
This article invents a new binary operation, calls it "division" and uses the "/" operator to denote it. But the article repeats multiple times that this new operation isn't a multiplicative inverse, so it's not actually division. For example, (a/b)*b=a isn't true for this new operation.
- tux3 2y ago
  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!
  - ilius2 2y ago
    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?
    - ilius2 2y ago
      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.
      - sidpatil 2y ago
        What if a is negative?
IshKebab 2y ago
> It’s saying that Pony is mathematically wrong. This is objectively false. Pff. The author wants to show off their knowledge of fields by defining a "division" operator where 1/0 = 0. Absolutely fine. I could define "addition" where 1 + 2 = 7. Totally fine. 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. Under the standard definition of division implied by '/' it is mathematically wrong. What they obviously should have done is use a different symbol, say `/!`. Obviously now they've done the classic thing and made the obvious choice unsafe and the safe choice unobvious (`/?`).
- tmtvl 2y ago
  > 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 programming languages): If we let Z = X + Y, where X > 0 and Y > 0, any of the following can be true: Z < X, Z < Y, (Z - X) < Y. Which we commonly know as 'wrap around'. * I haven't yet encountered a language which solves this issue: X + Y has no result for sufficiently large values for X and Y (any integer whose binary representation exceeds the storage capacity of the machine the code runs on will do). Depending on whether or not the language supports integer promotion and arbitrary precision integers the values of X and Y don't even have to be particularly large. * Non-integer addition. You're lucky if 0.3 = 0.1 + 0.2, good luck trying to to get anything sensible out of X + 0.2, where X = (2 ^ 128) + 0.1.
  - IshKebab 2y ago
    > 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 float addition. Fair point about wrapping.
sethev 2y ago
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 more toward because "it's what a larger set of people expect in more situations" rather than mathematical purity.
- riwsky 2y ago
  Huh? The article shows why 1/0=0 is mathematically sound, and then considers an error preferable in a programming context anyway, because practicality. It’s the opposite of the reasoning you’re describing.
  - deleted 2y ago
    [deleted]
  - petesergeant 2y ago
    > The article shows why 1/0=0 is mathematically sound It does not, because it is not. And the “real mathematicians” that he quotes aren’t supporting his case either, they’re just saying that there are cases where it’s convenient to pretend. If you look at the Wikipedia page for division by zero you may find “it is possible to define the result of division by zero in other ways, resulting in different number systems”: in short, if it’s convenient, you can make up your own rules.
    - worik 2y ago
      > in short, if it’s convenient, you can make up your own rules. Yes. People find it confusing that there is no simple model that encapsulates arithmetic. Fields do not capture it in its entirety. The models of arithmetic that describe it end up being extremely complex. Arithmetic is ubiquitous in proofs of other things, and people like the author of this blog cannot get over it. Reality is weird, inconsistent, and weirdly incomplete. Get used to it!
eqvinox 2y ago
Note 1/0 (or x/0 with x>0) isn't undefined or an exception in 754 FP math, it's +infinity. It's 0/0 that's the problem. Defining 1/0=0 isn't really helpful imho.
- yarg 2y ago
  > Defining 1/0=0 isn't really helpful imho But it's quite a nice way to mask program bugs.
blueblimp 2y ago
This sort of convenient semi-arbitrary extension of a partial function is ubiquitous in Lean 4 mathlib, the most active mathematics formalization project today. It turns out that the most convenient way to do informal math and formal math differ in this aspect.
d_tr 2y ago
Whatever as long as the name does not imply that these are integers, because then it is just wrong. The same holds for overflowing results being clamped or resulting in smaller or negative values due to wraparound. These are not integers. There is only one correct behavior for something named "int". Give the correct result or throw an error.
- Asooka 2y ago
  Those are all integers. https://en.wikipedia.org/wiki/Modular_arithmetic https://en.wikipedia.org/wiki/Modular_arithmetic - "The modern approach to modular arithmetic was developed by Carl Friedrich Gauss in his book Disquisitiones Arithmeticae, published in 1801." They have been integers for over 200 years now.
  - thaumasiotes 2y ago
    Wrapping around is correct integer behavior; clamping ("5 + 1 = 5") isn't. Clamping implies immediately that all positive numbers are equal to zero.
    - TapamN 2y ago
      True correct behavior would have that if a > b, then a + c > b + c also holds true for all integers, but that isn't guaranteed for wrapping (or clamping.) (e.g. if 250 > 1, then 250 + 10 > 1 + 10 should be true, but with 8-bit wrapping you would get 4 > 11, which is false.)
  - d_tr 2y ago
    But if you write a + b and the result is wrapped around or saturated, it's not integer addition. It's something else and should be written in another way in code and have a different name. I am aware of modular arithmetic. If you have a type named "int" with an operation called "addition", and that operation is not actually integer addition... it's wrong.
- itishappy 2y ago
  Agree `int` is the problem. This implies we're doing math over all integers, when in most languages what we're actually working with are bounded integers. (There's some counter-examples, Python and Haskell come to mind.) Calling them sane names like `i32` and `i64` makes it clear that overflow exists.
TrianguloY 2y ago
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 that with 'i' and never went far. Still intrigued if this is somewhat interesting or a total time loss though.
- deleted 2y ago
  [deleted]
- thaumasiotes 2y ago
  It's just a waste of time. The reason no value is conventionally assigned for division by zero is that assigning a consistent value doesn't help. When you want a value for that kind of expression at all, you'll want different values in different expressions.
- alganet 2y ago
  In SQL, if you divide by zero, you get a NULL. If you divide by NULL, you get NULL (any operation involving a NULL yields NULL, even GROUP BY). I call it "a black hole zero", if it touches anything, that thing becomes a black hole zero. Some languages will wrap division by zero in a special type, a NaN (not a number). You can then reason on top if that NaN if you want to. So, in a sense, there are some people already doing practical stuff with substituting /0 for a new symbol.
  - kaoD 2y ago
    Does it? Under SQL standard or what engine? At least Postgres raises when dividing by zero.
    - alganet 2y ago
      You're right about division by zero. From SQL92: 4) The dyadic arithmetic operators <plus sign>, <minus sign>, <as- terisk>, and <solidus> (+, -, *, and /, respectively) specify addition, subtraction, multiplication, and division, respec- tively. If the value of a divisor is zero, then an exception condition is raised: data exception-division by zero. However, the "any operation involving NULL yields NULL" is standard: 1) If the value of any <numeric primary> simply contained in a <numeric value expression> is the null value, then the result of the <numeric value expression> is the null value. https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt So, dividing by NULL is allowed and yields NULL. Dividing by zero yielding NULL is non-standard (I used it though).
_Sycamore 2y ago
My head-canon with dividing by zero is that 1/0 = undefined and 1/-0 = -undefined, and that's where I leave it because anything less funny than that seems like an impractical answer.
- maxk42 2y ago
  0 / 0 = Any number non-zero / 0 = No number
  - hgomersall 2y ago
    0/0 might be a specific number. You have to go and use l'hopitals rule to work out what it might be.
- jansan 2y ago
  I am fine if isFinite(1/0) returns false.
hans_castorp 2y ago
MySQL has ignored math rules for ages as well. 1/0 yields NULL there
- Minor49er 2y ago
  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
  - sbuttgereit 2y ago
    If all the inputs to the expression are not null, you should get some not null result so long as your well defined inputs meet other criteria of the expression (in bounds, etc.); I'd consider this a validation question and, failing validation, I'd want an exception. By simply returning NULL, you're really saying something else... that the inputs to the expression are valid, but result in something that cannot be determined. I don't think this is the case in 1/0; an exception is the proper signal since the construction of the expression itself is wrong (or the inputs invalid). "SQL dialects typically return NULL for erroneous operations." I disagree with this. NULL does not mean erroneous, it simply means the definition is not yet known and therefore cannot be discussed beyond saying you don't know. That could be erroneous, but you don't know yet, all you have is a NULL. If it's any comfort, I do agree that NULL is better than 0 or some other non-null result. I just don't think it's best and clouds the nature of the expression, the inputs to the expression, and ultimately is an incorrect result. Also to be fair, MySQL had many more grievous foot-gun data quality issues in the past than this... though these things certainly did make it easier for a non-expert database developer to get something working without blow-up-everything errors.
  - hans_castorp 2y ago
    My understanding was that it's "not allowed" rather than "undefined". 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.
ganzuul 2y ago
In the computational domain we hold entropy in high esteem. Arbitrarily assigning a value of 0 does not preserve entropy. We could return a promise that eventually we will not overflow if we get to be very very clever (arbitrary time) so that we can maintain purity.
tbrownaw 2y ago
So, how often do devs actually want a `/` that isn't the inverse of multiplication? Trying to calculate... I don't know, how many 2-disk raid6 groups I need to hold some amount of data is an error, not "lol you don't need any". If my queue consumer can handle 0 concurrent tasks, it will take literally forever to finish, not finish instantly.
- nlitened 2y ago
  To be fair, if my queue consumer can handle 0 concurrent tasks, I’d rather it finishes instantly than never.
  - agos 2y ago
    the other option is not infinite, it's undefined
benlivengood 2y ago
Most definitions of division that I have seen use q * d + r = n if q is unique and abs(r)<abs(d), which doesn't require the definition of an inverse. Rather, d that exist for n = 1 and r = 0 can be labelled q's inverse but it doesn't require a new definition. Additionally, if inverses are defined as separate objects then what is 2 plus the inverse of 2? It doesn't simplify to 2.5 because there's no addition axiom for numbers and multiplicative inverses, or for that matter any rules for inverses with inverses. So you might have 1/2 and 5/10 but they're not equal and can't be multiplied together.
daft_pink 2y ago
Wouldn’t the logical value when dividing by zero be infinity, because zero can go into any number an infinite number of times?
- amavect 2y ago
  Saying 1/0=∞ means creating a new number system with ∞ as a number. Now you have to figure out all operations with ∞, like -1*∞, 0*∞, ∞*∞, ∞/∞, or ∞-∞. Making wrong definitions creates contradictions. With 1*x=x, ∞/∞=1, the associative property x*(y/z)=(x*y)/z, and ∞*∞=∞: ∞ = ∞*1 = ∞*(∞/∞) = (∞*∞)/∞ = ∞/∞ = 1
  - zokier 2y ago
    that's largely solved problem. ieee758 defines consistent rules for dealing with infinities. even if don't use the floating-point parts and made a new integer format, it almost certainly would make sense to lift ieee754 rules as-is.
    - amavect 2y ago
      A IEEE754-like arithmetic (transrational arithmetic, or transreal arithmetic) creates new problems due to adding new values. 0*x=0 now requires x≠∞, x≠-∞, and x≠NaN. (x/x)=1 now requires x≠0, x≠∞, x≠-∞, and x≠NaN, so this system doesn't satisfy the field axioms. NaN lacks ordering, so we lose a total order relation. However, you get cool new results, like x/x=1+(0/x). Definitely some upsides.
  - daft_pink 2y ago
    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.
    - amavect 2y ago
      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 x≠0, x≠∞, x≠-∞, and x≠NaN. Adding more conditions changes the multiplicative inverse field axiom, and thus doesn't extend field theory. Also, now x*0=0 requires x≠∞, x≠-∞, and x≠NaN. What a mess.
dang 2y ago
One megathread and a couple small ones. Others? 1 / 0 = 0 (2018) - https://news.ycombinator.com/item?id=42167875 https://news.ycombinator.com/item?id=42167875 - Nov 2024 (8 comments) What is the best answer to divide by 0 - https://news.ycombinator.com/item?id=40210775 https://news.ycombinator.com/item?id=40210775 - April 2024 (3 comments) 1/0 = 0 - https://news.ycombinator.com/item?id=17736046 https://news.ycombinator.com/item?id=17736046 - Aug 2018 (570 comments)
dccsillag 2y ago
I find it odd that all of the mathematicians cited at the end are actually pretty much CS people, working on proof assistants. Kinda renders that section pointless, IMO (though the comment by Isabelle's author was interesting). IMO, whether something like this makes sense is a separate matter. Personally I always just think of division in terms of multiplicative inverses, so I don't see how defining division by zero helps other than perhaps making implementation easier in a proof assistant. But I've seen people say that there are some cases where having a/0 = 0 works out nicely. I'm curious to know what these cases are, though.
MathMonkeyMan 2y ago
Not that anybody asked me, but I think about it like this: You have a field (a set of "numbers"). Multiplication is defined over the field. You want to invent a notion of division. Let's introduce the notation "a/b" to refer to some member of a field such that "a/b" * b = a. As Hillel points out, you can identify "a/b" with a*inverse(b), where "inverse" is the multiplicative inverse. And yes, there is no inverse(0). But really let's just stick with the previous definition: "a/b" * b = a. Now consider "a/0". If "a/0" is in the field, then "a/0" * 0 = a. Let's consider the case where a != 0. Then we have "a/0" * 0 != 0. But this cannot be true if "a/0" is in the field, because for every x we have x * 0 = 0. Thus "a/0" is not in the field. Consider "a/0" with a=0. Then "a/0" * 0 = 0. Any member of the field satisfies this equation, because for every x we have x * 0 = 0. So, "a/0" could be any member of the field. Our definition of division does not determine "0/0". Whether you can assign "1/0" to a member of the field (such as 0) depends on how you define division.
bee_rider 2y ago
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, why pick the one very specific invalid value?
- worik 2y ago
  > Maybe division by zero should just not exist. It does not. It is undefined
- ChadNauseam 2y ago
  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.
  - throwawaymaths 2y ago
    Not really. You could divide by the subtraction result of two positive integers.
    - ChadNauseam 2y ago
      You would just have to prove that the integers are not equal, right?
kstrauser 2y ago
I despise that answer because it’s so context-dependent. What’s? 10/10? 1. 5/5? 1. .3/.3? 1. .0000000578/.0000000578? 1. Ergo, x/x=1, so 0/0=1. You can use the same logic for x/0=any rational number. Defining x/0=0 is impossibly arbitrary.
worik 2y ago
Division has an intuitive meaning: A divided by B is the number of Bs in A. That is an intuition why division by zero is undefined. Defining it arbitrarily is uninteresting. Disapointing
zzo38computer 2y ago
In uxn, the result of division of anything by zero is defined as zero (there are no error conditions in uxn). I did not know that Pony is also doing that. This is not a proper "division" (since it is not always a multiplicative inverse operation), but it does not necessarily have to be (and, as another comment mentions, the integer division operator in many programming languages is not a proper "division" either); it is something else which might use a "/" sign or the instruction name "DIV" or whatever.
throwawaymaths 2y ago
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 fiber in your external data source's data center) and took some downstream action based off of what you think is the rolling average. You could get royally fucked if money is involved. Crashing would have been preferable. 1/0 = 0 is unsuitable and dangerous for anyone doing anything in the real world.
- gregschlom 2y ago
  It's funny, I hold the exact opposite opinion, but from the same example: In the course of my programming career, I've had at least 3 different instances where I crashed stuff in production because I was computing an average and forgot to handle the case of the empty list. Everything would have been just fine if dividing by zero yielded zero. I've learned my lesson since, but still.
  - throwawaymaths 2y ago
    What was the problem with crashing? Surely you had Kubernetes/GCP/ECS restart your container, or if you're using a BEAM based language, it would have just restarted > Everything would have been just fine if dividing by zero yielded zero perhaps you weren't making business decisions based on the reported average, just logging it for metrics or something, in which case I can see how a crash/restart would be annoying.
    - Joker_vD 2y ago
      > What was the problem with crashing? I imagine the problem was that it crashed the whole process, and so the processing of other, completely fine data that was happening in parallel, was aborted as well. Did that lead to that data being dropped on the floor? Who knows — but probably yes. And process restarts are not instantaneous, just so you know, and that's even without talking about bringing the application into the "stable stream processing" state, which includes establishing streaming connections with other up- and downstream services.
ashoeafoot 2y ago
So,it gives you a infinite list with binary system digit values, that produces a ranked infinity?
d--b 2y ago
The only thing that truly matters is this: When software engineers make mistakes dividing by 0 and end up with Exceptions being raised or NaNs being output, they'll usually blame themselves. When the results are wrong numbers all over the place, they'll blame the language. There are 2 cases when people are going to "use" x/0: 1. They made a mistake. 2. They KNOW that x/0 returns 0 and they take it as a shortcut for (y == 0 ? 0 : x/y) Is that shortcut useful? No. Is it dangerous? Yes. Hence, this is a bad idea.
_7acn 2y ago
Not zero. Infinity
bubblyworld 2y ago
Consistency depends on your set of axioms. If you are willing to give up various nice properties of division, then you can obviously extend it however you like. My gripe with arbitrary choices like this is that it pushes complexity from your proof's initial conditions ("we assume x != 0") into the body of your proof (every time you use division now you've split your proof into two cases). The former is a linear addition of complexity to a proof, whereas the latter can grow exponentially. Of course, nothing is stopping you from using an initial condition anyway to avoid the case splitting, but if you were going to do that why mess with division in the first place?
mrfinn 2y ago
Disagreed. 1/0 should be infinity, and computers should be able to handle these concepts. Just look into what is 1/0.00000000000[etc]1. And no is not an error, you find out with a very real and tangible example, when you are developing a 3D engine and you want to make the camera to look at vector [ 0, 0, 0 ]. Quick resume: You can't, you need to force add a slight displacement so you can skip this silly error.
blablabla123 2y ago
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 precision numerics and functions which aren't explicit about corner cases it's always a simplification. However performance-/code-wise this is usually not feasible.
- eru 2y ago
  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.
- DarkNova6 2y ago
  Hilbert's Hotel shows nicely that infinity can't be singular.
  - blablabla123 2y ago
    Yeah but this is basically about countable and uncountable sets. It's rather counter-intuitive that the rational numbers are countable. So it's possible to create even a bijective mapping between rational numbers and natural numbers. On the other hand real numbers (which number types in programming languages try to approximate) are uncountable
  - knappa 2y ago
    Pretty sure this person meant singular as in singularity, not singular as in one.
movpasd 2y ago
This is all well and fine, but feels like a lot of words to say "it's a matter of definition". The question is what definitions will be useful and what properties you gain or give up. Being a partial function is a perfectly acceptable trade-off for mathematics, but perhaps it makes it difficult to reason about programs in some cases. I suppose the aim of the article is to point out the issue is not one of soundness, which is useful — but I wish more emphasis had been put on the fact that it doesn't solve the question of what 1/0 should do and produced arguments with regards to that.
- deleted 2y ago
  [deleted]
hoseja 2y ago
1/0 = (−∞, ∞) 0 ∈ (−∞, ∞)
est 2y ago
I might be wrong but this looks a lot like an re-implementation of Riemann sphere?
anthk 2y ago
1/0 = NOP in assembly. You just don't divide, you skip that operation.
red_admiral 2y ago
EDIT: markup broke my operators In combinatorics and discrete probability, `0**0 = 1` is a useful convention, to the point that some books define a new version of the operator - let's call it `***` - and define `a***b = a**b` except that `0***0 = 1` and then use the new operator instead of exponentiation everywhere. (To be clear, `**` is exponentiation, I could write `a^b` but that is already XOR in my mind.) So one might as well overload the old one: tinyurl.com/zeropowerzero This causes no problems unless you're trying to do real (or complex) analysis. 1/0 can cause a few more problems, but if you know you're doing something where it's safe, it's like putting the Rust `unsafe` keyword in front of your proof and so promising you know what you're doing.
- Skeime 2y ago
  In analysis, you also use 0**0 = 1 all the time. It's the only sensible convention for power series. It's really just a bit unfortunate that (x, y) -> x**y is not continuous at (0, 0).
deleted 2y ago
[deleted]
freddealmeida 2y ago
God. No.
amai 2y ago
But 0/1 = 0. So 1/0 must be the inverse/opposite of zero. And I think if you look at the Riemann sphere, the inverse of zero is the point where +infinity and -infinity meet. I would call that 0^(-1).
- amai 2y ago
  Actually this is what Mathematica does: https://math.stackexchange.com/questions/1294852/why-does-wolfram-alpha-say-that-n-0-is-complex-infinity https://math.stackexchange.com/questions/1294852/why-does-wo... Mathematica calls this point on the Riemann sphere "complex infinity".
  - amai 2y ago
    See also https://en.wikipedia.org/wiki/Projectively_extended_real_line#Dividing_by_zero https://en.wikipedia.org/wiki/Projectively_extended_real_lin...
ChrisMarshallNY 2y ago
> one rule I try to follow is do not mock other programmers. I like that. I try to live by a similar protocol. On topic: Each context has the right to establish their own rules. If the rules work, the context survives. If not, then the context dies.
ne38 2y ago
Letting 1/0 = 0 it's fine. but it is an isolated formula (from other field formulas). Mathematics is not about isolated facts.
jbverschoor 2y ago
-0
red_admiral 2y ago
Another version of this: P(A|B) is not defined for P(B)=0, but you can safely let P(A|B)P(B)=0 when P(B)=0. Half the time, these two terms appear as a pair anyway. It's a version of "you can't divide by zero, but you can multiply the divisor on both sides of the equation and then use 0*a=0."
dswilkerson 2y ago
Math major here: this is wrong. The expression 1/0 is NOT A NUMBER, even if you allow positive infinity or negative infinity. In particular, it is most certainly not 0. Note that infinity would be a fine answer IF MATHEMATICS COULD BE CONSISTENTLY EXTENDED to define it to be so, but this cannot be done (see below). Note that using infinity does not "break" mathematics (as some have suggested below) otherwise mathematicians would not use infinity at all. If we have an expression that is not a number, such as 1/0, you can sometimes consistently define it to be something, such as a number or positive infinity or negative infinity, IF THAT WOULD BE CONSISTENT with the rest of mathematics. Let's see an example of the standard means of getting a consistent definition of exponentiation starting with its definition on positive integers and extending eventually to a definition for on a much bigger set, the rationals (ratios of signed integers). We define 2 ^ N (exponentiation, "two raised to the power of N") for N a positive integer to be 2 multiplied by itself N times. For example: 2 ^ 1 = 2; 2 ^ 2 = 4; 2 ^ 3 = 8. Ok, what is 2 ^ N where N is a negative integer? Well we did not define it, so it is nothing. However there is a way to CONSISTENTLY EXTEND the definition to include negative exponents: just define it to preserve the algebraic properties of exponentiation. For exponents we have: (2 ^ A) * (2 ^ B) ("two raised to the power of A times two raised to the power of B") = 2 ^ (A+B) ("two raised to the power of A plus B"). That is, when you multiply, the exponents add. You can spot check it: (2 ^ 2) * (2 ^ 3) = 4 * 8 = 32 = 2 ^ 5 = 2 ^ (2 + 3). So we can EXTEND THE DEFINITION of exponentiation to define 2 ^ -N for positive integer N (so a negative integer exponent) to be something that would BE CONSISTENT WITH the algebraic property above as follows. Define 2 ^ -N ("two raised to the power of negative N") to be (1/2) ^ N ("one half raised to the power N"). Check: (2 ^ -1) * (2 ^ 2) = ((1/2) ^ 1) * (2 ^ 2) = 1/2 * 4 = 2 = 2 ^ 1 = 2 ^ (-1 + 2). Ok, what is 2 ^ 0 ("two raised to the power of zero")? Again, we have not defined it, so it is nothing. However, again, we can CONSISTENTLY EXTEND the definition of exponentiation to give it a value. 2 ^ 0 = (2 ^ -1) * (2 ^ 1) = 1/2 * 2 = 1. This always works out no matter how you look at it. So we say 2 ^ 0 = 1. I struggled with this for days when I was a kid, literally yelling in disbelief at my parents until the would run away from me. I mean 2 ^ 0 means multiplying 2 times itself 0 times, which means doing nothing, so I thought it should be 0. After 3 days I finally realized that doing nothing IN THE CONTEXT OF MULTIPLICATION is multiplying by ONE, not multiplying by zero, so 2 ^ 0 should be 1. Ok, is there a way to CONSISTENTLY EXTEND the definition of exponentiation to include non-integer exponents? Yes, we can define 2 ^ X for X = P / Q, where P and Q are integers (a "rational number"), to be 2 ^ (P/Q) = (2 ^ P) * (2 ^ -Q). All the properties of exponentials work out. Notice how we can keep EXTENDING the definition of exponentiation starting from positive integers, to integers, to rationals, as long as we do so CONSISTENT with the properties of the previous definition of exponentials. I will not do go into the details, but we can CONSISTENTLY EXTEND the definition of exponentiation to real numbers by taking limits. For example, we can have a consistent definition of 2 ^ pi ("two raised to the power of pi") by taking the limit of 2 ^ (P/Q) as P/Q approaches pi. HOWEVER, IN CONTRAST to the above extension of the definition of exponentiation, there is NO SUCH SIMILAR CONSISTENT EXTENSION to division that allows us to define 1/0 as ANY NUMBER AT ALL, even if we allow extending to include positive infinity and negative infinity. The limit of 1/x as x goes to zero FROM THE POSITIVE DIRECTION = positive infinity. Some example points of this sequence: 1/1 = 1; 1/0.5 = 2; 1/0.1 = 10; 1/0.01 = 100, etc. As you can see the limit is going to positive infinity. However, the limit of 1/x as x goes to zero FROM THE NEGATIVE DIRECTION = NEGATIVE infinity. Some example points from this sequence: 1/-1 = -1; 1/-0.5 = -2; 1/-0.1 = -10; 1/-0.01 = -100, etc. As you can see the limit is going to NEGATIVE infinity. Therefore, since positive infinity does not equal negative infinity, there is NO DEFINITION of 1/0 that is consistent with BOTH of these limits at the same time. The expression 1/0 is NOT A NUMBER, even if you include positive and negative infinity, and mathematics cannot be consistently extended to make it into a number. Q.E.D.
gweinberg 2y ago
The article goes way too long to say 1/0 = 0 isn't exactly wrong because slash can mean anything you want it to mean. As the article points out, it isn't really "right" either, you could equally validly say it's a wreath of pretty flowers which smell bad.

1/0 = 0 (2018)

135 points by revskill 2y ago

I'd agree to some kind of 1//0=0 for ints; but for floats you'll take 1/0=inf from my cold, dead hands.

rsp1984 2y ago

As long as lim(1/x)_x->0 = inf, 1/0 = 0 doesn't make a whole lot of sense, mathematically speaking. I might be wrong but I don't think it was addressed in the article either.

lupire 2y ago
It's fine. Infinity isn't a real number, so 1/x isn't continuous at 0, so it doesn't matter what the value of 1/0 is. All your open sets still behave the way you expect. Whether you choose "this function is undefined here" vs "it's impossible to ever reach the value of this function at this value, under any assumptions I'll ever care about" is purely a matter of convenience.
- rsp1984 2y ago
  Yea, but conceptually it's a bit smelly to have f(x) get larger and larger the closer x is to 0 and then suddenly have it be 0 once x reaches 0.
  - renewiltord 2y ago
    But once you go behind, it flips suddenly anyway so you could just as well have it be intuitively “halfway between the positive and negative infinities” which is at least fun and could spawn a few “Why is 1/x suddenly go to zero” articles on HN in 2053
  - _carbyau_ 2y ago
    As others have pointed out "larger and larger" is the same when it is negative too. So I think people are just going: positive infinity + negative infinity = 0. Intuitively nice in a sense but I honestly think '0' is misrepresenting what is going on here. I'm ok with it being ' "+ and/or -" infinity' as a new definition. Programmatically I think it should result in a NULL or VOID or similar. I mean, by definition it has no definition.
    - rsp1984 2y ago
      Good point.
- Turneyboy 2y ago
  Well if you consider 1/z as a function of a complex coordinate it definitely makes a lot of sense to set it to infty. That identifies +infty and -infty if you restrict yourself to the real numbers.
CharlieDigital 2y ago
There's a great Radiolab episode[0] that talks about divide by zero in perhaps more conceptual terms. KARIM ANI: If you take 10 and divide it by 10, you get one. 10 divided by five is two. 10 divided by half is 20. The smaller the number on the bottom, the number that you're dividing by, the larger the result. And so by that reasoning ... LULU: If you divide by zero, the smallest nothingness number we can conceive of, then your answer ... KARIM ANI: Would be infinity. LULU: Why isn't it infinity? Infinity feels like a great answer. KARIM ANI: Because infinity in mathematics isn't actually a number, it's a direction. It's a direction that we can move towards, but it isn't a destination that we can get to. And the reason is because if you allow for infinity then you get really weird results. For instance, infinity plus zero is ... LATIF: Infinity. KARIM ANI: Infinity plus two is infinity. Infinity plus three is infinity. And what that would suggest is zero is equal to one, is equal to two, is equal to three, is equal to four ... STEVE STROGATZ: And that would break math as we know it. Because then, as your friend says, all numbers would become the same number. [0] https://radiolab.org/podcast/zeroworld https://radiolab.org/podcast/zeroworld
- v4vvdq 2y ago
  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.
  - WithinReason 2y ago
    on computers you can have negative zeros
    - recursive 2y ago
      Negative zero is equal to zero, so it's not really a distinct number, just another representation of the same value.
      - 2y ago
v4vvdq 2y ago
I was also looking for this. And would like to add: lim(-1/x)_x -> 0 = -inf That is (in my opinion) the whole point why it is actually undefined. On one side of the y-axis it goes to infinity, on the other to minus infinity. I don't see a solution to this and therefore always have accepted that it is undefined.
- lupire 2y ago
  No. 1/x^2 is undefined at 0 but has the same limit behavior, because limit behavior is not a function from "pairs of (functions from R to R, R)" to R Infinity is not a real number.
  - ganzuul 2y ago
    Can limit behavior be defined as Cauchy sequences?
deleted 2y ago
[deleted]
judofyr 2y ago
The arguments around limits are addressed towards the end (under "Update 8/12/2018"): > > If 0/0 = 0 then lim_(x -> 0) sin(x) / x = sin(0) / 0 = 0, but by L’Hospitals’ Rule lim_(x -> 0) sin(x) / x = lim_(x -> 0) cos(x) / 1 = 1. So we have 0 = 1. > This was a really clever one. The issue is that the counterargument assumes that if the limit exists and f(0) is defined, then lim_(x -> 0) f(x) = f(0). This isn’t always true: take a continuous function and add a point discontinuity. The limit of sin(x) / x is not sin(0) / 0, because sin(x) / x is discontinuous at 0. For the unextended division it’s because sin(0) / 0 is undefined, while for our extended division it’s a point discontinuity. Funnily enough if we instead picked x/0 = 1 then sin(x) / x would be continuous everywhere. Similar examples can be constructed for any regular function which is discontinuous (e.g. Heaviside step function).

lupire 2y ago

https://xenaproject.wordpress.com/2020/07/05/division-by-zero-in-type-theory-a-faq/ https://xenaproject.wordpress.com/2020/07/05/division-by-zer... explains Lean's behavior. Basically, you use a goofy alternate definition of division (and sqrt, and more), and to compensate you have to assume (or prove based on assumptions) that the things you will divide by are never zero. Hillel's pedantry is ill-taken, though, because he starts off with a false accusation that the headline tweet was insulting anyone. Also, 1/0=0" is sound only if you change the field axiom.of division, which is fine, but quite rather hiding the ball. If you add " 1/0=0" as an axiom to the usual field axioms, you do get an unsound system.

moomin 2y ago

Honestly this hurts my head but Hillel is inevitably correct. You can define an explicitly undefined operation to do whatever you like. But what’s the point? There’s no new mathematics you can do with it, no existing behaviours you can extend like this. Normally, when you divide by a small number, you get a large number. Now for some reason it goes through zero. Why not five? Why not seven? Just because it’s formally consistent doesn’t mean it isn’t dumb.

lupire 2y ago
Because exceptions are expensive, and functions with holes are dumb. "Dumb" is purely a matter of aesthetic preference. Calling things "dumb" is dumb. > Normally, when you divide by a small number, you get a large number. Now for some reason it goes through zero. Zero is not a "small" number. Zero is the zero number. There is no number that is better result than 0 when dividing by 0; "Infinity" is not a real (or complex) number. This itself is GREAT reason to set 1/0 = 0. It only ever bothers people who conflate open sets with closed sets, or conflate Infinity with real numbers, so it's good have this pop up to force people to think about the difference.
- recursive 2y ago
  > Zero is not a "small" number. Zero is the zero number. What do you mean by this? Zero is certainly a zero number, but it seems that it might also be a small number simultaneously.
  - thaumasiotes 2y ago
    For example, zero is the only real infinitesimal value.
- akira2501 2y ago
  Sure.. but there are infinite series that sum to a finite value. Perhaps a pertinent example would be summing all the distances between each successive reciprocal of 1: Sum[1/x - 1/(x+1), {x, 1, ∞}] == 1 You do actually need infinity to arrive at that 1.

croes 2y ago

It’s unexpected and that makes it dangerous.

jvanderbot 2y ago

Q on this post: Is the field rule "Every element Except Zero has ... " (the 9th rule) defined with respect to the additive identity "zero" or the magical other undefined "Zero" that is the number we're all familiar with? If so, how weirdly arbitrary that the additive zero is omitted for all multiplicative inverse definitions. (At least it seems to me). I always figured this was a consequence of our number systems, not of all fields.

lupire 2y ago
I am not familiar with any "magical other undefined Zero". Please familiarize me :-) What is your, uh, definition of this undefined* number you are familiar with?
- jvanderbot 2y ago
  > Every element EXCEPT 0 has a multiplicative inverse, a⁻, such that a*a⁻ = 1. What is "0"? It's not defined in the axioms other than additive zero. Or is it multiplicative zero? (1?). Is it the number zero? If it is the additive zero defined in axiom (3), then it just seems weird to me that additive zero is undefined for multiplicative inverse for all fields always and forever. If it is the number zero, then how does that generalize to other fields? If the answer is "Numbers are the first field and all fields generalize that", then I suppose we are referring to the number (0), and that's fine, as other fields are welcome to define their own larger definition of zero that includes the number (0) ... ?
  - kaoD 2y ago
    "Zero" is just a specific element of the field which satisfies being the additive identity as well as the rest of the properties of a field where 0 is mentioned. When the rest of the axioms refer to "zero" they refer to the exact same element of the set that is also the additive identity. It's not the "number zero" because a field does not care about numbers, it's just elements of a set (which might be numbers like in R's case). 1 is not "multiplicative zero", it's the "multiplicative identity". 0 and 1 are just the shorthand we give for those elements. because those are the symbols we use in R which is the most common field we deal with in everyday life. Or am I misunderstanding your question?

jmclnx 2y ago

I set this to zero and print a warning/error about divide by zero on the log with data that caused it. That log would be sent to the business person worry about. If they ignore it, I do not care, it is the business problem anyway. Worked for me for decades :)

codeflo 2y ago

This article invents a new binary operation, calls it "division" and uses the "/" operator to denote it. But the article repeats multiple times that this new operation isn't a multiplicative inverse, so it's not actually division. For example, (a/b)*b=a isn't true for this new operation.

tux3 2y ago
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!
- ilius2 2y ago
  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?
  - ilius2 2y ago
    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.
    - sidpatil 2y ago
      What if a is negative?

IshKebab 2y ago

> It’s saying that Pony is mathematically wrong. This is objectively false. Pff. The author wants to show off their knowledge of fields by defining a "division" operator where 1/0 = 0. Absolutely fine. I could define "addition" where 1 + 2 = 7. Totally fine. 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. Under the standard definition of division implied by '/' it is mathematically wrong. What they obviously should have done is use a different symbol, say `/!`. Obviously now they've done the classic thing and made the obvious choice unsafe and the safe choice unobvious (`/?`).

tmtvl 2y ago
> 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 programming languages): If we let Z = X + Y, where X > 0 and Y > 0, any of the following can be true: Z < X, Z < Y, (Z - X) < Y. Which we commonly know as 'wrap around'. * I haven't yet encountered a language which solves this issue: X + Y has no result for sufficiently large values for X and Y (any integer whose binary representation exceeds the storage capacity of the machine the code runs on will do). Depending on whether or not the language supports integer promotion and arbitrary precision integers the values of X and Y don't even have to be particularly large. * Non-integer addition. You're lucky if 0.3 = 0.1 + 0.2, good luck trying to to get anything sensible out of X + 0.2, where X = (2 ^ 128) + 0.1.
- IshKebab 2y ago
  > 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 float addition. Fair point about wrapping.

sethev 2y ago

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 more toward because "it's what a larger set of people expect in more situations" rather than mathematical purity.

riwsky 2y ago
Huh? The article shows why 1/0=0 is mathematically sound, and then considers an error preferable in a programming context anyway, because practicality. It’s the opposite of the reasoning you’re describing.
- deleted 2y ago
  [deleted]
- petesergeant 2y ago
  > The article shows why 1/0=0 is mathematically sound It does not, because it is not. And the “real mathematicians” that he quotes aren’t supporting his case either, they’re just saying that there are cases where it’s convenient to pretend. If you look at the Wikipedia page for division by zero you may find “it is possible to define the result of division by zero in other ways, resulting in different number systems”: in short, if it’s convenient, you can make up your own rules.
  - worik 2y ago
    > in short, if it’s convenient, you can make up your own rules. Yes. People find it confusing that there is no simple model that encapsulates arithmetic. Fields do not capture it in its entirety. The models of arithmetic that describe it end up being extremely complex. Arithmetic is ubiquitous in proofs of other things, and people like the author of this blog cannot get over it. Reality is weird, inconsistent, and weirdly incomplete. Get used to it!

eqvinox 2y ago

Note 1/0 (or x/0 with x>0) isn't undefined or an exception in 754 FP math, it's +infinity. It's 0/0 that's the problem. Defining 1/0=0 isn't really helpful imho.

yarg 2y ago
> Defining 1/0=0 isn't really helpful imho But it's quite a nice way to mask program bugs.

blueblimp 2y ago

This sort of convenient semi-arbitrary extension of a partial function is ubiquitous in Lean 4 mathlib, the most active mathematics formalization project today. It turns out that the most convenient way to do informal math and formal math differ in this aspect.

d_tr 2y ago

Whatever as long as the name does not imply that these are integers, because then it is just wrong. The same holds for overflowing results being clamped or resulting in smaller or negative values due to wraparound. These are not integers. There is only one correct behavior for something named "int". Give the correct result or throw an error.

Asooka 2y ago
Those are all integers. https://en.wikipedia.org/wiki/Modular_arithmetic https://en.wikipedia.org/wiki/Modular_arithmetic - "The modern approach to modular arithmetic was developed by Carl Friedrich Gauss in his book Disquisitiones Arithmeticae, published in 1801." They have been integers for over 200 years now.
- thaumasiotes 2y ago
  Wrapping around is correct integer behavior; clamping ("5 + 1 = 5") isn't. Clamping implies immediately that all positive numbers are equal to zero.
  - TapamN 2y ago
    True correct behavior would have that if a > b, then a + c > b + c also holds true for all integers, but that isn't guaranteed for wrapping (or clamping.) (e.g. if 250 > 1, then 250 + 10 > 1 + 10 should be true, but with 8-bit wrapping you would get 4 > 11, which is false.)
- d_tr 2y ago
  But if you write a + b and the result is wrapped around or saturated, it's not integer addition. It's something else and should be written in another way in code and have a different name. I am aware of modular arithmetic. If you have a type named "int" with an operation called "addition", and that operation is not actually integer addition... it's wrong.
itishappy 2y ago
Agree `int` is the problem. This implies we're doing math over all integers, when in most languages what we're actually working with are bounded integers. (There's some counter-examples, Python and Haskell come to mind.) Calling them sane names like `i32` and `i64` makes it clear that overflow exists.

TrianguloY 2y ago

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 that with 'i' and never went far. Still intrigued if this is somewhat interesting or a total time loss though.

deleted 2y ago
[deleted]
thaumasiotes 2y ago
It's just a waste of time. The reason no value is conventionally assigned for division by zero is that assigning a consistent value doesn't help. When you want a value for that kind of expression at all, you'll want different values in different expressions.
alganet 2y ago
In SQL, if you divide by zero, you get a NULL. If you divide by NULL, you get NULL (any operation involving a NULL yields NULL, even GROUP BY). I call it "a black hole zero", if it touches anything, that thing becomes a black hole zero. Some languages will wrap division by zero in a special type, a NaN (not a number). You can then reason on top if that NaN if you want to. So, in a sense, there are some people already doing practical stuff with substituting /0 for a new symbol.
- kaoD 2y ago
  Does it? Under SQL standard or what engine? At least Postgres raises when dividing by zero.
  - alganet 2y ago
    You're right about division by zero. From SQL92: 4) The dyadic arithmetic operators <plus sign>, <minus sign>, <as- terisk>, and <solidus> (+, -, *, and /, respectively) specify addition, subtraction, multiplication, and division, respec- tively. If the value of a divisor is zero, then an exception condition is raised: data exception-division by zero. However, the "any operation involving NULL yields NULL" is standard: 1) If the value of any <numeric primary> simply contained in a <numeric value expression> is the null value, then the result of the <numeric value expression> is the null value. https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt So, dividing by NULL is allowed and yields NULL. Dividing by zero yielding NULL is non-standard (I used it though).

_Sycamore 2y ago

My head-canon with dividing by zero is that 1/0 = undefined and 1/-0 = -undefined, and that's where I leave it because anything less funny than that seems like an impractical answer.

maxk42 2y ago
0 / 0 = Any number non-zero / 0 = No number
- hgomersall 2y ago
  0/0 might be a specific number. You have to go and use l'hopitals rule to work out what it might be.
jansan 2y ago
I am fine if isFinite(1/0) returns false.

hans_castorp 2y ago

MySQL has ignored math rules for ages as well. 1/0 yields NULL there

Minor49er 2y ago
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
- sbuttgereit 2y ago
  If all the inputs to the expression are not null, you should get some not null result so long as your well defined inputs meet other criteria of the expression (in bounds, etc.); I'd consider this a validation question and, failing validation, I'd want an exception. By simply returning NULL, you're really saying something else... that the inputs to the expression are valid, but result in something that cannot be determined. I don't think this is the case in 1/0; an exception is the proper signal since the construction of the expression itself is wrong (or the inputs invalid). "SQL dialects typically return NULL for erroneous operations." I disagree with this. NULL does not mean erroneous, it simply means the definition is not yet known and therefore cannot be discussed beyond saying you don't know. That could be erroneous, but you don't know yet, all you have is a NULL. If it's any comfort, I do agree that NULL is better than 0 or some other non-null result. I just don't think it's best and clouds the nature of the expression, the inputs to the expression, and ultimately is an incorrect result. Also to be fair, MySQL had many more grievous foot-gun data quality issues in the past than this... though these things certainly did make it easier for a non-expert database developer to get something working without blow-up-everything errors.
- hans_castorp 2y ago
  My understanding was that it's "not allowed" rather than "undefined". 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.

ganzuul 2y ago

In the computational domain we hold entropy in high esteem. Arbitrarily assigning a value of 0 does not preserve entropy. We could return a promise that eventually we will not overflow if we get to be very very clever (arbitrary time) so that we can maintain purity.

tbrownaw 2y ago

So, how often do devs actually want a `/` that isn't the inverse of multiplication? Trying to calculate... I don't know, how many 2-disk raid6 groups I need to hold some amount of data is an error, not "lol you don't need any". If my queue consumer can handle 0 concurrent tasks, it will take literally forever to finish, not finish instantly.

nlitened 2y ago
To be fair, if my queue consumer can handle 0 concurrent tasks, I’d rather it finishes instantly than never.
- agos 2y ago
  the other option is not infinite, it's undefined

benlivengood 2y ago

Most definitions of division that I have seen use q * d + r = n if q is unique and abs(r)<abs(d), which doesn't require the definition of an inverse. Rather, d that exist for n = 1 and r = 0 can be labelled q's inverse but it doesn't require a new definition. Additionally, if inverses are defined as separate objects then what is 2 plus the inverse of 2? It doesn't simplify to 2.5 because there's no addition axiom for numbers and multiplicative inverses, or for that matter any rules for inverses with inverses. So you might have 1/2 and 5/10 but they're not equal and can't be multiplied together.

daft_pink 2y ago

Wouldn’t the logical value when dividing by zero be infinity, because zero can go into any number an infinite number of times?

amavect 2y ago
Saying 1/0=∞ means creating a new number system with ∞ as a number. Now you have to figure out all operations with ∞, like -1*∞, 0*∞, ∞*∞, ∞/∞, or ∞-∞. Making wrong definitions creates contradictions. With 1*x=x, ∞/∞=1, the associative property x*(y/z)=(x*y)/z, and ∞*∞=∞: ∞ = ∞*1 = ∞*(∞/∞) = (∞*∞)/∞ = ∞/∞ = 1
- zokier 2y ago
  that's largely solved problem. ieee758 defines consistent rules for dealing with infinities. even if don't use the floating-point parts and made a new integer format, it almost certainly would make sense to lift ieee754 rules as-is.
  - amavect 2y ago
    A IEEE754-like arithmetic (transrational arithmetic, or transreal arithmetic) creates new problems due to adding new values. 0*x=0 now requires x≠∞, x≠-∞, and x≠NaN. (x/x)=1 now requires x≠0, x≠∞, x≠-∞, and x≠NaN, so this system doesn't satisfy the field axioms. NaN lacks ordering, so we lose a total order relation. However, you get cool new results, like x/x=1+(0/x). Definitely some upsides.
- daft_pink 2y ago
  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.
  - amavect 2y ago
    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 x≠0, x≠∞, x≠-∞, and x≠NaN. Adding more conditions changes the multiplicative inverse field axiom, and thus doesn't extend field theory. Also, now x*0=0 requires x≠∞, x≠-∞, and x≠NaN. What a mess.

dang 2y ago

One megathread and a couple small ones. Others? 1 / 0 = 0 (2018) - https://news.ycombinator.com/item?id=42167875 https://news.ycombinator.com/item?id=42167875 - Nov 2024 (8 comments) What is the best answer to divide by 0 - https://news.ycombinator.com/item?id=40210775 https://news.ycombinator.com/item?id=40210775 - April 2024 (3 comments) 1/0 = 0 - https://news.ycombinator.com/item?id=17736046 https://news.ycombinator.com/item?id=17736046 - Aug 2018 (570 comments)

dccsillag 2y ago

I find it odd that all of the mathematicians cited at the end are actually pretty much CS people, working on proof assistants. Kinda renders that section pointless, IMO (though the comment by Isabelle's author was interesting). IMO, whether something like this makes sense is a separate matter. Personally I always just think of division in terms of multiplicative inverses, so I don't see how defining division by zero helps other than perhaps making implementation easier in a proof assistant. But I've seen people say that there are some cases where having a/0 = 0 works out nicely. I'm curious to know what these cases are, though.

MathMonkeyMan 2y ago

Not that anybody asked me, but I think about it like this: You have a field (a set of "numbers"). Multiplication is defined over the field. You want to invent a notion of division. Let's introduce the notation "a/b" to refer to some member of a field such that "a/b" * b = a. As Hillel points out, you can identify "a/b" with a*inverse(b), where "inverse" is the multiplicative inverse. And yes, there is no inverse(0). But really let's just stick with the previous definition: "a/b" * b = a. Now consider "a/0". If "a/0" is in the field, then "a/0" * 0 = a. Let's consider the case where a != 0. Then we have "a/0" * 0 != 0. But this cannot be true if "a/0" is in the field, because for every x we have x * 0 = 0. Thus "a/0" is not in the field. Consider "a/0" with a=0. Then "a/0" * 0 = 0. Any member of the field satisfies this equation, because for every x we have x * 0 = 0. So, "a/0" could be any member of the field. Our definition of division does not determine "0/0". Whether you can assign "1/0" to a member of the field (such as 0) depends on how you define division.

bee_rider 2y ago

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, why pick the one very specific invalid value?

worik 2y ago
> Maybe division by zero should just not exist. It does not. It is undefined
ChadNauseam 2y ago
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.
- throwawaymaths 2y ago
  Not really. You could divide by the subtraction result of two positive integers.
  - ChadNauseam 2y ago
    You would just have to prove that the integers are not equal, right?

kstrauser 2y ago

I despise that answer because it’s so context-dependent. What’s? 10/10? 1. 5/5? 1. .3/.3? 1. .0000000578/.0000000578? 1. Ergo, x/x=1, so 0/0=1. You can use the same logic for x/0=any rational number. Defining x/0=0 is impossibly arbitrary.

worik 2y ago

Division has an intuitive meaning: A divided by B is the number of Bs in A. That is an intuition why division by zero is undefined. Defining it arbitrarily is uninteresting. Disapointing

zzo38computer 2y ago

In uxn, the result of division of anything by zero is defined as zero (there are no error conditions in uxn). I did not know that Pony is also doing that. This is not a proper "division" (since it is not always a multiplicative inverse operation), but it does not necessarily have to be (and, as another comment mentions, the integer division operator in many programming languages is not a proper "division" either); it is something else which might use a "/" sign or the instruction name "DIV" or whatever.

throwawaymaths 2y ago

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 fiber in your external data source's data center) and took some downstream action based off of what you think is the rolling average. You could get royally fucked if money is involved. Crashing would have been preferable. 1/0 = 0 is unsuitable and dangerous for anyone doing anything in the real world.

gregschlom 2y ago
It's funny, I hold the exact opposite opinion, but from the same example: In the course of my programming career, I've had at least 3 different instances where I crashed stuff in production because I was computing an average and forgot to handle the case of the empty list. Everything would have been just fine if dividing by zero yielded zero. I've learned my lesson since, but still.
- throwawaymaths 2y ago
  What was the problem with crashing? Surely you had Kubernetes/GCP/ECS restart your container, or if you're using a BEAM based language, it would have just restarted > Everything would have been just fine if dividing by zero yielded zero perhaps you weren't making business decisions based on the reported average, just logging it for metrics or something, in which case I can see how a crash/restart would be annoying.
  - Joker_vD 2y ago
    > What was the problem with crashing? I imagine the problem was that it crashed the whole process, and so the processing of other, completely fine data that was happening in parallel, was aborted as well. Did that lead to that data being dropped on the floor? Who knows — but probably yes. And process restarts are not instantaneous, just so you know, and that's even without talking about bringing the application into the "stable stream processing" state, which includes establishing streaming connections with other up- and downstream services.

ashoeafoot 2y ago

So,it gives you a infinite list with binary system digit values, that produces a ranked infinity?

d--b 2y ago

The only thing that truly matters is this: When software engineers make mistakes dividing by 0 and end up with Exceptions being raised or NaNs being output, they'll usually blame themselves. When the results are wrong numbers all over the place, they'll blame the language. There are 2 cases when people are going to "use" x/0: 1. They made a mistake. 2. They KNOW that x/0 returns 0 and they take it as a shortcut for (y == 0 ? 0 : x/y) Is that shortcut useful? No. Is it dangerous? Yes. Hence, this is a bad idea.

_7acn 2y ago

Not zero. Infinity

bubblyworld 2y ago

Consistency depends on your set of axioms. If you are willing to give up various nice properties of division, then you can obviously extend it however you like. My gripe with arbitrary choices like this is that it pushes complexity from your proof's initial conditions ("we assume x != 0") into the body of your proof (every time you use division now you've split your proof into two cases). The former is a linear addition of complexity to a proof, whereas the latter can grow exponentially. Of course, nothing is stopping you from using an initial condition anyway to avoid the case splitting, but if you were going to do that why mess with division in the first place?

mrfinn 2y ago

Disagreed. 1/0 should be infinity, and computers should be able to handle these concepts. Just look into what is 1/0.00000000000[etc]1. And no is not an error, you find out with a very real and tangible example, when you are developing a 3D engine and you want to make the camera to look at vector [ 0, 0, 0 ]. Quick resume: You can't, you need to force add a slight displacement so you can skip this silly error.

blablabla123 2y ago

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 precision numerics and functions which aren't explicit about corner cases it's always a simplification. However performance-/code-wise this is usually not feasible.

eru 2y ago
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.
DarkNova6 2y ago
Hilbert's Hotel shows nicely that infinity can't be singular.
- blablabla123 2y ago
  Yeah but this is basically about countable and uncountable sets. It's rather counter-intuitive that the rational numbers are countable. So it's possible to create even a bijective mapping between rational numbers and natural numbers. On the other hand real numbers (which number types in programming languages try to approximate) are uncountable
- knappa 2y ago
  Pretty sure this person meant singular as in singularity, not singular as in one.

movpasd 2y ago

This is all well and fine, but feels like a lot of words to say "it's a matter of definition". The question is what definitions will be useful and what properties you gain or give up. Being a partial function is a perfectly acceptable trade-off for mathematics, but perhaps it makes it difficult to reason about programs in some cases. I suppose the aim of the article is to point out the issue is not one of soundness, which is useful — but I wish more emphasis had been put on the fact that it doesn't solve the question of what 1/0 should do and produced arguments with regards to that.

deleted 2y ago
[deleted]

hoseja 2y ago

1/0 = (−∞, ∞) 0 ∈ (−∞, ∞)

est 2y ago

I might be wrong but this looks a lot like an re-implementation of Riemann sphere?

anthk 2y ago

1/0 = NOP in assembly. You just don't divide, you skip that operation.

red_admiral 2y ago

EDIT: markup broke my operators In combinatorics and discrete probability, `0**0 = 1` is a useful convention, to the point that some books define a new version of the operator - let's call it `***` - and define `a***b = a**b` except that `0***0 = 1` and then use the new operator instead of exponentiation everywhere. (To be clear, `**` is exponentiation, I could write `a^b` but that is already XOR in my mind.) So one might as well overload the old one: tinyurl.com/zeropowerzero This causes no problems unless you're trying to do real (or complex) analysis. 1/0 can cause a few more problems, but if you know you're doing something where it's safe, it's like putting the Rust `unsafe` keyword in front of your proof and so promising you know what you're doing.

Skeime 2y ago
In analysis, you also use 0**0 = 1 all the time. It's the only sensible convention for power series. It's really just a bit unfortunate that (x, y) -> x**y is not continuous at (0, 0).

deleted 2y ago

[deleted]

freddealmeida 2y ago

God. No.

amai 2y ago

But 0/1 = 0. So 1/0 must be the inverse/opposite of zero. And I think if you look at the Riemann sphere, the inverse of zero is the point where +infinity and -infinity meet. I would call that 0^(-1).

amai 2y ago
Actually this is what Mathematica does: https://math.stackexchange.com/questions/1294852/why-does-wolfram-alpha-say-that-n-0-is-complex-infinity https://math.stackexchange.com/questions/1294852/why-does-wo... Mathematica calls this point on the Riemann sphere "complex infinity".
- amai 2y ago
  See also https://en.wikipedia.org/wiki/Projectively_extended_real_line#Dividing_by_zero https://en.wikipedia.org/wiki/Projectively_extended_real_lin...

ChrisMarshallNY 2y ago

> one rule I try to follow is do not mock other programmers. I like that. I try to live by a similar protocol. On topic: Each context has the right to establish their own rules. If the rules work, the context survives. If not, then the context dies.

ne38 2y ago

Letting 1/0 = 0 it's fine. but it is an isolated formula (from other field formulas). Mathematics is not about isolated facts.

jbverschoor 2y ago

-0

red_admiral 2y ago

Another version of this: P(A|B) is not defined for P(B)=0, but you can safely let P(A|B)P(B)=0 when P(B)=0. Half the time, these two terms appear as a pair anyway. It's a version of "you can't divide by zero, but you can multiply the divisor on both sides of the equation and then use 0*a=0."

dswilkerson 2y ago

Math major here: this is wrong. The expression 1/0 is NOT A NUMBER, even if you allow positive infinity or negative infinity. In particular, it is most certainly not 0. Note that infinity would be a fine answer IF MATHEMATICS COULD BE CONSISTENTLY EXTENDED to define it to be so, but this cannot be done (see below). Note that using infinity does not "break" mathematics (as some have suggested below) otherwise mathematicians would not use infinity at all. If we have an expression that is not a number, such as 1/0, you can sometimes consistently define it to be something, such as a number or positive infinity or negative infinity, IF THAT WOULD BE CONSISTENT with the rest of mathematics. Let's see an example of the standard means of getting a consistent definition of exponentiation starting with its definition on positive integers and extending eventually to a definition for on a much bigger set, the rationals (ratios of signed integers). We define 2 ^ N (exponentiation, "two raised to the power of N") for N a positive integer to be 2 multiplied by itself N times. For example: 2 ^ 1 = 2; 2 ^ 2 = 4; 2 ^ 3 = 8. Ok, what is 2 ^ N where N is a negative integer? Well we did not define it, so it is nothing. However there is a way to CONSISTENTLY EXTEND the definition to include negative exponents: just define it to preserve the algebraic properties of exponentiation. For exponents we have: (2 ^ A) * (2 ^ B) ("two raised to the power of A times two raised to the power of B") = 2 ^ (A+B) ("two raised to the power of A plus B"). That is, when you multiply, the exponents add. You can spot check it: (2 ^ 2) * (2 ^ 3) = 4 * 8 = 32 = 2 ^ 5 = 2 ^ (2 + 3). So we can EXTEND THE DEFINITION of exponentiation to define 2 ^ -N for positive integer N (so a negative integer exponent) to be something that would BE CONSISTENT WITH the algebraic property above as follows. Define 2 ^ -N ("two raised to the power of negative N") to be (1/2) ^ N ("one half raised to the power N"). Check: (2 ^ -1) * (2 ^ 2) = ((1/2) ^ 1) * (2 ^ 2) = 1/2 * 4 = 2 = 2 ^ 1 = 2 ^ (-1 + 2). Ok, what is 2 ^ 0 ("two raised to the power of zero")? Again, we have not defined it, so it is nothing. However, again, we can CONSISTENTLY EXTEND the definition of exponentiation to give it a value. 2 ^ 0 = (2 ^ -1) * (2 ^ 1) = 1/2 * 2 = 1. This always works out no matter how you look at it. So we say 2 ^ 0 = 1. I struggled with this for days when I was a kid, literally yelling in disbelief at my parents until the would run away from me. I mean 2 ^ 0 means multiplying 2 times itself 0 times, which means doing nothing, so I thought it should be 0. After 3 days I finally realized that doing nothing IN THE CONTEXT OF MULTIPLICATION is multiplying by ONE, not multiplying by zero, so 2 ^ 0 should be 1. Ok, is there a way to CONSISTENTLY EXTEND the definition of exponentiation to include non-integer exponents? Yes, we can define 2 ^ X for X = P / Q, where P and Q are integers (a "rational number"), to be 2 ^ (P/Q) = (2 ^ P) * (2 ^ -Q). All the properties of exponentials work out. Notice how we can keep EXTENDING the definition of exponentiation starting from positive integers, to integers, to rationals, as long as we do so CONSISTENT with the properties of the previous definition of exponentials. I will not do go into the details, but we can CONSISTENTLY EXTEND the definition of exponentiation to real numbers by taking limits. For example, we can have a consistent definition of 2 ^ pi ("two raised to the power of pi") by taking the limit of 2 ^ (P/Q) as P/Q approaches pi. HOWEVER, IN CONTRAST to the above extension of the definition of exponentiation, there is NO SUCH SIMILAR CONSISTENT EXTENSION to division that allows us to define 1/0 as ANY NUMBER AT ALL, even if we allow extending to include positive infinity and negative infinity. The limit of 1/x as x goes to zero FROM THE POSITIVE DIRECTION = positive infinity. Some example points of this sequence: 1/1 = 1; 1/0.5 = 2; 1/0.1 = 10; 1/0.01 = 100, etc. As you can see the limit is going to positive infinity. However, the limit of 1/x as x goes to zero FROM THE NEGATIVE DIRECTION = NEGATIVE infinity. Some example points from this sequence: 1/-1 = -1; 1/-0.5 = -2; 1/-0.1 = -10; 1/-0.01 = -100, etc. As you can see the limit is going to NEGATIVE infinity. Therefore, since positive infinity does not equal negative infinity, there is NO DEFINITION of 1/0 that is consistent with BOTH of these limits at the same time. The expression 1/0 is NOT A NUMBER, even if you include positive and negative infinity, and mathematics cannot be consistently extended to make it into a number. Q.E.D.

gweinberg 2y ago

The article goes way too long to say 1/0 = 0 isn't exactly wrong because slash can mean anything you want it to mean. As the article points out, it isn't really "right" either, you could equally validly say it's a wreath of pretty flowers which smell bad.