1/0 = 0 | Hacker News Reader

1/0 = 0

hillelwayne.com

650 pointsingve570 comments

My problem with "1/0 = 0" is that it's essentially masking what's almost always a bug in your program. If you have a program that's performing divide-by-zeroes, that's almost surely something you did not intend for. It's a corner case that you failed to anticipate and plan for. And because you didn't plan for it, whatever result you get for 1/0 is almost surely a result that you wouldn't want to have returned to the user.

When encountering such unanticipated corner cases, it's almost always better to throw an error. That prevents any further data/state corruption from happening. It prevents your user from getting back a bad result which she thinks she can trust and rely on. It highlights the problem very clearly, so that you know you have a problem, and that you have to fix it. Simply returning a 0 does the exact opposite.

If you're one of the 0.1% who did anticipate all this, and correctly intended for your program to treat 1/0 as 0, then just check for this case explicitly and make it behave the way you wanted. The authors of pony are welcome to design their language any way they want. But in this case, they are hurting their users far more than they are helping.

An issue with D that has repeatedly engendered heated debate is what should happen when a programming bug is detected at runtime. The two camps are:

1. The program should "soldier on" if it can.

2. The program should go immediately to jail, it must not pass Go, and must not collect $200.

I'm solidly in the latter camp. If a program has entered a state unanticipated by the programmer, then there is no way to know how it entered that state (until it is debugged), and hence no way to know what the program might do next (such as load malware).

1/0 is a bug, and the program should immediately halt.

> If a program has entered a state unanticipated by the programmer, then there is no way to know how it entered that state [...] and hence no way to know what the program might do next (such as load malware).

... or kill the patient ( https://en.wikipedia.org/wiki/Therac-25 ) or set the company bankrupt overnight ( https://en.wikipedia.org/wiki/Knight_Capital_Group ), or simply delete all your data (happened to me with some buggy media player that though my $HOME directory belonged to its download cache).

Programming languages don't generally allow us to "handle", from inside the faulty process, stuff like NULL-pointer dereference, double-free, or segmentation faults. And that's a good thing, because as you said, at this point, there's a very high probability the program is in some rogue state.

(Making special cases for NullPointerException or OutOfBoundsException, like some languages do, is, IMHO, a bad idea, that spreads the confusion between programming mistakes (i.e coming from the source code) and invalid runtime conditions (coming from environment). (I'm avoiding the ambiguous terms "errors" or "bugs" here)).

Making "divide by zero" non-fatal belongs to the same family than making "((int)0)" return zero, or making "((int)0) = x" a no-op. At first, it seems like this will only hide programming mistakes ; but this impression comes from my current programming habits, which are tailored to avoid these situations.

But maybe there are advantages in being able to write these things on purpose (at the cost of losing the runtime detection of some programming mistakes). After all, I'm perfectly happy with "free(NULL)".

Great analysis! I think that summarizes a lot of dev arguments. That said, Erlang appears to agree with both camps. If an error occurs, the _process_ immediately crashes (not OS process, it's Erlang Kingo for an actor or a green thread), but the _program_ soldiers on as if nothing happened. The idea behind the design, I believe, is that programmer errors are unavoidable, but that eg a bug in some edge case triggered by uncommon data shouldn't crash the entire server.

I don't know much about Pony, but given that it is also actor based, I'd imagine this would be a great opportunity to crash early and eagerly. It gives you all the advantages of catching a bug early while not crippling a production app under what might be a pretty low-impact, low-frequency bug.

Adopting this policy was what destroyed the first Ariane 5.[0] IIRC, a conversion from floating-point to a 16-bit integer overflowed, raising an exception which reset the flight control system. The flight control system was redundant, but both copies experienced the same error. The result that was being computed would not have been used.

The lesson I took from this is that neither of these two options is acceptable in software that has to work all the time, like much real-time software. Instead, we should detect all the bugs in such software before runtime, which is only feasible for small systems such as seL4[1]. So we should diligently minimize this software.

For other programs, the best way to handle an error is context-dependent. If a rendering bug will result in a glitch showing in a texture onscreen, that's preferable to exiting the game in the middle of a raid. If a PID motor control system for a robot arm has a division by zero, halting the program without first slowing the motors to a stop could be catastrophic, even causing fatalities. And of course there are numerous cases where continuing execution in the face of such an error is far worse.

[0]: https://web.archive.org/web/20000815230639/http://www.esrin.... [1]: http://sel4.systems/

To say that either (1) or (2) is always the right choice is unreasonable. It depends on context.

If a program is running under a supervisor, it makes sense to bail, as a new clean instance will become available.

If it was the code of the life support machine that displays data on the LEDs that I was connected to, I prefer that it solder on rather than stop functioning altogether because data for one of the digits was out of 0-9 range.

I'm sure there's been many instances where spacecraft had partially malfunctioning software that was remotely corrected because it didn't entirely give up but rather continued to accept input.

If the program is designed to "soldier on", then why not? The question is how is the program designed to react in face of failure: should it fail safe? And is it safe to crash on any error?

My point of view is that a program should abort if it encounters an irrecoverable error, such as imminent memory corruption. However, if it's designed to fail functional, then it could continue to work, either by reinitialising itself, or by aborting the current operation. However, it must be said that it's hard to design such programs, so the option of bailing out is very attractive.

Example: an out of bounds access is a typical programmer error. This should probably result in an abort during development, so that it can be fixed. However, it is possible to not want to abort just because something is not accessible when in production. The program could instead raise an exception and clean up the call stack up to its initialisation point, then notify the surrounding system that a problem was encountered and resume service. The surrounding system could then keep track of the encountered issues and try to perform a recovery after a threshold is reached: this is how Android recovery works for e.g. crashing system services, if I recall correctly, it first cleans some application settings, then system settings, then does an OS reinstall. Now in this example the trigger condition is a crash, but it doesn't necessarily have to be like that.

I can't say that I'm firmly in either camp.

What seems much more important to me is that the behavior is well documented. If I am working with a system where 1 / 0 is defined to be zero, I will deal with that just as I deal with other peculiarities like 1 / 3 being 0 and 1.0 / 3.0 only approximately being a third in some systems. It's a practical concern like many others in programming.

My comment from when this came up on Reddit, slightly edited for context:

`/`-by-0 is just an operation and it tautologically has the semantics assigned to it. The question is whether the specific behaviour will cause bugs, and on glance that doesn't sound like it would be the case.

Principally, division is normally (best guess) used in cases where the divisor obviously cannot be zero; cases like division by constants are very common, for example. The second most common usage (also best guess) is to extract a property from an aggregate, like `average = sum / count` or `elem_size = total_size / count`. In these cases the result is either a seemingly sane default (`average = 0` with no elements, `matrix_width = 0` when zero-height) or a value that is never used (eg. `elem_size` only ever used inside a loop iterated zero times).

It seems unlikely to me that `/` being a natural extension of division that includes division by zero would be nontrivially error-prone. Even when it does go wrong, Pony is strongly actor-based, has no shared mutability and permits no unhandled cascading failures, so such an event would very likely be gracefully handled anyway, since even mere indexing requires visible error paths. This nothing-ever-fails aspect to Pony is fairly unique (Haskell and Rust are well known for harsh compilers, but by no means avoid throwing entirely), but it gives a lot more passive safety here. This honestly doesn't seem like a bad choice to me.

An example well-defined use case is if you want to compute a harmonic mean, e.g.

x = 2/(1/a +1/b)

This is a form of average where you are giving increased importance to the smaller number. It frequently pops up in science/engineering, e.g. in hydrology when you are computing flow of water underground.

In this case, it's "obvious" that when e.g. a is zero, you want 1/a to be zero so you simply return b. There's typically a clear, big distinction between "smallest realistic number", for instance 1e-3, and a zero, whether actual zero or 1e-34.

For instance Numpy offers a nice way of doing this:

  def safeInv(a):
    tol = 1e-16
    return np.division(1.0,a,out=np.zeros_like(a),where=np.where(a>tol))

This tells numpy to put the result of division into an array of zeros shaped like a, but only do the divide where a>tol, so it returns 0 where a<tol.

In this case, though, the programmer understands this division is somehow special and should allow div-by-zero, so it is handled specially.

> `average = 0` with no elements

Imagine a Mars lander program that looks at the average of altitude measurements to decide when it's ok to jettison the parachute, sees no measurements, and decides that altitude is zero.

Pony requires programmer to handle everything case of every function...except this one case where it will just pick an arbitrary value to handle a case the progrmammer forgot, hiding the very error Pony was designed to guarantee gets solved. Why not allow partial functions everywhere and have them default to 0 where undefined?

That's a terrible default for an average function lol. Once again in nearly all cases, taking the average of a list without elements is an error.

What happens for 0 / 0? Is this also 0?

I almost want two different division operations: One where 1/0 = 0, exclusively for use in progress bars and stuff like that, and another one for everything else.

Because frequently division by zero indicates a bug. But similarly frequently, I end up crapping out annoying little bits of code like

  if (foo == 0):
    return 0
  else:
    return bar / foo

I'm reading the "Pony" tweet quoted in TFA and your comment and I'm left very puzzled: is that really that common to want x / 0 == 0 ? In practice where does that crop up?

You say that you frequently have to write your little shim but honestly I don't remember writing code like that in recent memory.

You talk about progress bars, I suppose it makes sense if you somehow try to copy 0 elements for instance, and you end up dividing by zero when computing the progress, like:

    pos_percent = (copied_elems * 100) / total_elems

And both copied_elems and total_elems are zero. But in this case wouldn't you want the computation to return 100% instead of zero?

It's also a bit odd because it introduces a discontinuity: as the divisor goes towards zero the result of the operation gets greater until it reaches exactly zero and it yields 0. Wouldn't it make more sense to return INT_MAX (for integers) or +inf for floats? If you're writing a game for instance it might work better.

I guess it just goes to show that it probably makes a lot of sense to leave it undefined and let people write their own wrapper if necessary to do what works best for them in their given scenario.

Rust has your back:

pub fn checked_div(self, rhs: u8) -> Option<u8>

Checked integer division. Computes self / rhs, returning None if rhs == 0.

You would use this as lhs.checked_div(rhs).unwrap_or(your sane default)

This is dramatically better than always returning zero silently, as doing so is bound to be wrong in certain cases. If you run into a situation where you are afraid your RHS may be 0 but still want to do the right thing, this is what you'd use.

This is actually included in the IEEE754 floating point standard - there's a concept of "trapping" vs. "non-trapping" exceptions, where implementations are allowed to decide which exceptions should trap.

Unfortunately, GCC only lets you enable this globally (within a program): see http://www.gnu.org/software/libc/manual/html_node/FP-Excepti....

We will be introducing two sets of integer math operators in Pony. The current which are non-partial and can over/underflow + division by zero == 0 AND new ones that will be partial functions that cause an error on under/overflow and division by zero.

Isn't a ternary here nicer?

  return (foo == 0) ? 0 : bar / foo

or even

  return bar / max(1, foo)

in the case where foo is integer or tiny foo would overflow your range anyway

I've run into this a lot, but I'm also not sure what I really want to happen. Even for progress bars, the behavior can be different depending on how exactly you're obtaining the denominator -- does it increase dynamically or is it known from the beginning? Is it one of those fake progress bars that just ignores the fact that it'll stay at 100% for the next hour, or would it filling up genuinely mean that the work is actually done? After all, if you have 0 operations total and you've finished 0 of them, are you really 0% done? Wouldn't it make more sense to say you're 100% done? At the end of the day the user is trying to figure out how long they should keep waiting, to which the answer would be "you don't need to wait, there's no more work left to do".

> But similarly frequently, I end up crapping out annoying little bits of code

Isn't this reason the the point of having a utils library with commonly used pieces of code?

Most of the time when I have to think about what to do with a 0 divisor, I come to the conclusion that

  if (foo == 0):
    return MAX_FLOAT
  else:
    return bar / foo

is more sound for the given algorithm than "return 0" (still crappy, but more sound).

Then use MAX_FLOAT as an error flag instead of 0, which could have been the result of a legal operation (with bar==0).

Wait, when creating a progress Duke you divide in other direction: (things already done) / (all things). Can you give a specific example when it causes problems? My experience of writing code like that is that there a clearer way or I made a mistake somewhere.

Honest question. What is so annoying about that code? It's handling (in an application-specific manner) the special case of dividing by zero (which the `/` operator doesn't handle). I'm not sure of any other way to handle this.

Actually, bar/foo STILL has a gotcha which can throw exception, many developers doesn't think of this.

Just try INT_MIN/-1, can blow most "foolproof" divide logic away.

> But in this case, they are hurting their users far more than they are helping.

How could you possibly make an assertion like this without knowing why they made said choice[1]? Per the article, they didn't do it for fun, or to avoid exceptions (as you point out, more like defer exceptions). FTA:

> As I understand it, it’s because Pony forces you to handle all partial functions. Defining 1/0 is a “lesser evil” consequence of that.

Do you know enough about Pony's language design and decision process to support your claim that this decision (and all its second-order consequences) is hurting users far more than helping them?

[1] On the off chance that you are familiar with the tradeoffs Pony made and do know what you're talking about: care to clarify?

Hi I'm on the Pony core team and spent some time explaining the reasoning to Hillel. He hasn't written any Pony but I did walk him through how we ended up where we currently are.

I will be writing up a post about why we made this decision.

The real issue is that Pony doesn't have the concept of an unrecoverable error. All exceptions in Pony are checked, but sometimes if an error happens there's nothing your program can do and it should just crash.

Edit: Although Pony claims that programs should never crash, the language designers clearly understand the pragmatism of an unrecoverable error because it happens on OOM and stack overflow

It happens in scientific computing with zero bounded signals fairly regularly. Sometimes values hover close enough to zero that the computation results in a/0. It's not desired but the only alternative is a guard that invariably adds a performance penalty. There are other ways around it, such as normalization, but they're not trivial depending on the problem and can actually add other sources of bugs/errors. I understand the author's intent even though I disagree with the result.

1/a when a is close to zero is very large. 1/0 == 0 violates the limit and is just bad math.

Totally agree, in a mathematical proof you wouldn't ignore the edge case just because you think it might work the same way it has for some of your other proofs. It would invalidate everytihng, and in sequential processing, you could really mess up some of the data with one iteration with a 1/0 assumption that completely changes every iteration after it. Bad news.

What the world really needs: "1/0 = 0" in production build, "1/0 throws error" in development build...

That makes your bugs invisible in production. You could be failing every single transaction in the real world, and never know if your tests don't tickle the unhappy case.

Fairly straightforward in some languages (Ruby for instance).

The authors covers this at the end:

[1] The author has a dislike of the notion that 1/0 = 0 in a programming language. The author identifies this as a personal preference; I'm sure that preference is based on falsiable notions, but the author doesn't elaborate. The author _DOES_ elaborate their motivation for writing the post: The post debunks the notion that 1/0 = 0 is 'bad math'.

[2] Pony chose 1/0 = 0 because the language of Pony is set up to enforce the coder to complete all functions; if you go with the strict definition of division, which is an operation which has no definition if the second operand is 0, it's not complete anymore. I agree with your sentiment; this feels like the wrong answer, but it's definitely not as simple as just saying: Why don't the pony folks redefine things such that dividing by 0 raises some sort of error condition?

Does Pony have some analogous dodge for logarithms and square roots of reals, or for the gamma function?

Yep. Having had a couple divide-by-zero errors in a complicated simulation, I'm immensely grateful that it fails hard.

> If you have a program that's performing divide-by-zeroes, that's almost surely something you did not intend for

It's such a common case to consider, I don't think that's compelling. Knowing that a division by zero throws an exception or casts to zero, is similarly considered.

> they are hurting their users far more than they are helping.

There's no evidence of this.

Is this different than integer division or integer over/underflow? I mean, besides that the integer behavior is status quo and 1/0 is not. Genuine question.

Integer over/underflow is arguably less arbitrary. Sometimes Z mod 2^k is really where you want to be working, and the rest of the time at least it's the fastest answer. Whether that's enough of a justification to be a difference? shrug

OK but that doesn't have a lot to do with what TFA is actually talking about.

You're absolutely right. Not only that, but it's impossible to distinguish a bad result like 1/0 vs a good result like 0/1.

Even Javascript is better with "NaN"

To clarify, in Javascript 1/0 is Infinity, not NaN.

It’s common for 1/0 = 0 to be exactly what you want. Array average for example. That said raising exception would be the only consistent behavior if a language supports that.

It is not valid to extrapolate an average of 0 from no data at all.

For example, if we examine a sample of zero elephants, then we end up estimating the average elephantine mass as being zero.

This shows to be wildly off as soon as we upgrade our statistical wherewithal to work with a sample size of one.

A center of mass is a kind of average. If we have an empty object made of no particles of matter at all, can we arbitrarily pin its center of mass to the (0, 0, 0) origin of the coordinate system we are using?

And in other cases you really do want the infinities. For example fast ray-AABB tests like https://tavianator.com/fast-branchless-raybounding-box-inter...

Common compared to what? Taking an average of an empty array is nonsensical.

> It’s common for 1/0 = 0 to be exactly what you want. Array average for example.

Wouldn’t that be a (potentially very different) case of 0/0? If there are 0 elements, you wouldn’t have a nonzero numerator, right?

Hi,

I'm on the Pony core team. I will be writing in more detail about this decision. A few short notes until then:

1) no one on the team has ever been happy with ending up here, understanding why the decision was made involved understand how partial functions (one that can produce errors like division by zero) are handled in Pony and interesting ergonomic issues that can result that is a large part of what my post will be about.

2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value.

3) Partial function math is coming to Pony that includes 1/0 as partial (ie error producing) as well as handling integer overflow and underflow for operations: `+`, `-`, and `*`.

4) It's very straightforward even without that those operations to define your own division that will be partial (ie return an error) for division by zero.

Edit to include link to the comment below because it contains a good bit of the decisions that have to make when dealing with integer math:

https://news.ycombinator.com/item?id=17736637

Which is part of what I will touch on in my post about the decision process that Pony went through to reach to state we are currently at (which I want to highlight, is one we intend to improve- see #3 above).

> 2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value.

Oh jeeze... to me that almost nullifies all of the points in the article. It does an alright job explaining how 1/0 = 0 is at least consistent with other notions in the language, but to hear that the same logic can’t be applied to floats is just... well, objectively it’s a mess.

Hillel is talking about math. Unfortunately computers don't really do "math". For example, math doesn't have overflow and underflow to deal with.

The floating point standard says that division by 0.0 should be Infinity and provides a value for it. The integer math, all possible values are used for numbers, so division by zero is undefined behavior.

And from there, every language is potentially going to have a mess of inconsistency to deal with.

You can make 1/0 = Infinity so long as you box all your integers. That is, its not using the machine type, but I type that is a wrapper that can be the machine type or Infinity. And every user takes a large performance hit even if they will never divide by zero.

For some languages boxing integers is not a bad thing because they already do it. Why do they do it? Usually, because of another not math problem. Overflow and underflow:

What is 0 - 1? Well, its -1 right? Except of course if you have an unsigned integer, then its the max value of the integer. And what if you had 1 to the max value that the computer can represent? You wrap around. Some languages make all integers protect you from this and take a performance hit to be able to box and be able to represent numbers better as we expect them to work. In return, you can not do integer math as fast as you could.

Computers and numbers... its an inconsistent mess and a series of tradeoffs for any language of performance and various possible errors.

I'm going to talk about this and more in my post.

Here's another good one for you...

What does your favorite programming language return for 3/2 as compared to 3.0/2.0? Many will return different values.

EDIT:

for clarity of my point: integer math that uses machine types is pretty surprising compared to what we would expect from "math" in general for division.

In the mathematical sense, a Field is a Commutative Ring with the added constraint that the multiplicative operation has inverses for every non-zero element.

Floating point doesn't even form a Ring, because the operation is not associative[0]. Coq, for instance, defines the operation for QArith, which are the rational numbers. The representation is a pair (Z, positive), where Z is an integer and positive is a positive number (i.e., 1,2,...). QArith does form a field in the usual sense.

Integers are not a Field (unless you pick Z/p for some prime p), and machine words, signed or unsigned are even less of a mathematical object with the usual operations. So you can do almost anything you want to them from a programming perspective, including 1/0 = 0.

As Hillel writes, what to do will make sense in some settings, but not in others. You may want MAX_INT in some situations, and 0 in others. And this requires a check, partiality or not. Rejection of the case x/0 has more to do with the notion that it is usually a corner case where you want the programmer to think about what the result should be.

[0] The reason is that any addition can incur information loss, and the further away from 0 you are, the more information is lost. Thus, the order in which you add values matter.

As pointed out by others, floats work differently from ints in programming languages. Division in ints is usually defined such that if x = d * y + m, x / y = d and x % y = m. You can make this work by choosing the right m for every d, but when y is not 0, there are a few conventions you can choose to pick a sensible d and m. When y = 0, the m = a and d is completely free, so there really isn't a right answer from how division works.

Division with floats doesn't usually have a definition like that, so you don't end up in a similar situation. Plus, floating point math can have denominators get really close to 0 and have the result of the division tend toward the infinity value. Ints don't have values close to 0 or an infinity to represent what that division would tend toward.

As an aside, I have thought recently that integers should also have NaN value, just like floating point values have. It's useful in statistics to differentiate between not having a value and value of 0.

And I was thinking that perhaps 0x80000000 (in two's complement arithmetic) would be a good value for integer NaN. This value is already fixed point with respect to negation, so why not make it into an exception on its own right?

But it would mean to rethink all the hardware which I don't think is an option.

In any case, I think to set 1/0 to 0 is a bad idea, but I could imagine setting x/0 to 0x80000000 (interpreted as NaN) to make more sense.

I like the idea of having integer NaN but I think unsigned numbers are problematic as there isn't any convenient way to encode it.

>2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value.

Ah, that seems rather reasonable. For whatever reason, the OP had me thinking that Pony was replacing the ordinary semantics of IEEE 754 floating point division (probably because he talked about fields and multiplicative inverses).

Having 1/0 = 0 seems like a very reasonable choice, especially if you have 1%0 = 1 as well. Of course, if anyone thinks they will actually encounter division by 0 in their code, and needs to treat it as an error, they can always test for it.

Having 1/0 = 0 and 1.0f / 0.0f = +inf makes sense in two applications I can think of. The first would be currency systems in which prices down to the pre-determined fractional component are represented as unsigned integers. In calculating margin requirements division by zero equating to zero would be the correct answer. And two, for double precision continuous variables, any application involving 3D geometrical transforms. An aspect ratio approaching zero in one axis, would approach positive infinity in the other.

So you may be saving some developers time in operator overloading, etc. More important than the actual binary decision itself is having well-documented behavior. Have not tried Pony yet, but will take a look. Good discussion, keep it up!

We are over in #ponylang on freenode if you ever want to stop by and chat.

This should be the top comment. INTEGERS are not a field. But that kind of makes the 0 choice worse? Even cpus always throw on integer divide by 0, so i don't really see the low level optimization. Does it enable some higher level optimization? Why not x/0 = x?

What about I64.min_value() / (-1)? Why does that give 0? If you're doing wrap-around arithmetic it should give I64.min_value().

https://tio.run/##K8jPq/z/PzG5JL9IwTcxM49LAQjyUssVkotSE0tSNV...

That might be an LLVM bug.

`I64.max_value() + 1` gives the expected result.

I'm going to have to look into that.

Thanks.

I'd like to jump in here and point out that Pony ergonomics are unlike that if any other language; it is significantly different from any other language.

If 1/0 = 0 sounds unusable to you, Pony's garbage collection scheme (which is brilliant, by the way) is going to make you think the language is insane.

1/0 is not infinity either...

If we assume that we got to 0 because of a rounding error we do know that it should be some positive integer. I think that 1/0 = infinity is a reasonable substitute for an actual value. 1/0 = 0 seems absurd. 1/(a number approaching 0) produces ever increasing integers.

I don't know, does it even matter? What happens when you try to divide a physical object into 0 parts? It doesn't create infinite pieces. It doesn't make the object disappear. Seems like nothing happened. Maybe when we divide by 0 in a program it should halt and catch fire?

I hate logical arguments, I get sucked in and start arguing all the positions.

but with floating point units, 1.0/0.0 is infinity.

thanks for such a ginuwine response

Some people say "oh, that's easy, 1/0 is +Infinity". So the real fun is at 0/0.

The limit of x/y as x and y go to zero depends on which path across the xy plane you take towards the singularity. Along one approach, the limit is 0, along another approach the limit diverges to infinity, along yet another the limit is 17.

I'm not kidding! Go to https://www.geogebra.org/3d and enter "x/y" and spin the graph around. The "value" at x=0 y=0 is the entirety of the z-axis.

For another perspective, try http://www.wolframalpha.com/input/?i=z%3Dx%2Fy and turn on contour mode for the 3D plot. Notice how the contour lines radiate out from the z-axis; each of those is an "approach" to the singularity at a different z-value, and taking the limit along each line leads to a different value.

I always thought division by zero was, at best, + and - infinity, depending on the path, which is why we leave it undefined.

How would a path lead to 17?

  x=170, y=10
  x=17, y=1
  x=1.7, y=0.1
  x=0.17, y=0.01

The answer keeps being 17, even as x and y both get vanishingly close to zero.

I encourage you to play around with a 3D graphing calculator and see all the different paths you can take along that surface to reach the singularity. They all "reach" it at different heights.

In calculus you're supposed to learn that y/0 with y != 0 is "undefined" (±Inf with limit expressions), while 0/0 is "indeterminate" (can construct any value using a limit expression that contains x/x with x -> 0).

Take the limit as x goes to 0 of (17*x)/(x). Both numerator and denominator go to 0, so this is a representation of 0/0. The limit is then equal to 17.

24 / 2

17 / 1

1.7 / 0.1

0.17 / 0.01

0.017 / 0.001

...

0 / 0

Take the path (x,y)=(17a,a) as a goes to zero one dimensionally.

I like your point here. I think 1/0 = Infinity+ is a satisfying expression. Its a clear concept which can be visualized in a simple graph.

I think 0/0 is a different concept than 1/0. It's a different expression. 0/0 doesn't explicitly express a particular "path" on the graph.

We can call it (0/0) different names if we want. They can say 0/0 = "undefined". I am currently satisfied with 0/0 simply equals to 0/0, or simply "undefined".

If we all agree it is "undefined" we ironically defined it.

>I like your point here. I think 1/0 = Infinity+ is a satisfying expression. Its a clear concept which can be visualized in a simple graph.

Except it isn't. It still depends on which side you take the path from - from the positive denominator or the negative denominator side. (This is why IEEE 754 has a single signless infinity).

> I think 1/0 = Infinity+ is a satisfying expression. Its a clear concept which can be visualized in a simple graph.

Not for integers.

Since the "1/0 = 0" is only defined for integer division then I'd argue that the chosen constant should be MAX_INT. (or MIN_INT in case of signe values and negative numerator)

That's a wonderful graphing website from the look of it!

Limits aren't the only thing broken by division by zero, though. For integers it's mainly algebraic stuff.

I would argue 1/0 is infinity. Not with mathematics, just logically. By using the wording "how many times does 0 go into 1?"

You bring up 0/0. But 0/<anything> is already defined, it's 0. So 0/infinity = 0

Programmatically, I think I've always wanted X/0 to be 0. For example: progress bars, currency, or damage in a video game. It wouldn't be very helpful to have infinity be an answer there.

Your argument is flawed because your zero is positively biased.

Why infinity and why not negative infinity.

I encourage you to look at the graphs. Yes, the value along the y-axis is 0, and the value along the x-axis approaches positive and negative infinity. It's path-dependent. Take a look.

In float yes. In int there's no Inf. There's only MAX_INT or 0 or throw an exception.

Normal langs throw. That what the checked int div will do. But the unchecked int div has no return type which allows throwing an error. And pony is strongly typed, unlike most other langs. That's why it can guarantee much more safeties and performance than all other languages.

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks

It actually does break something, the symmetry between division and multiplication and the many pieces of code that assume that (x / y) * y equals x. Here is a naive and non practical example, but it is not impossible to find a real world example where this simplified code manifests itself accidentally or by design

  function do_something_with_x(x, y) {
    let ratio = x / y;
    if (do_something_with_ratio(ratio)) {
      return x * y;
    }
    else return null;
  }

Again, this is a naive example but one that could manifest itself with a very imprecise result when y = 0

I think OP means that nothing breaks mathematically. It is not inconsistent and not false, so you can work with it. The only issue is to deal specially with the case of division by zero, which you have to do anyways. Code that assumes that (x/y) * y = x is wrong if you don't check for y = 0, independently of what you define x/0 to be.

> the many pieces of code that assume that (x / y) * y equals x

The same issue if division by zero throws an exception. This is simply a more practical approach that dispenses with the exception handling (ie becomes a less irregular test case). Edit: Not buggy behavior, when expected.

> (x / y) * y equals x

Even without Pony's assumption, that's only true when y != 0.

It's talking about integer arithmetic, so it's already not true that (x / y) * y == x. For example, (5 / 2) * 2 == 4.

> …any pieces of code that assume that (x / y) * y equals x…

What? If you’re using integers or floating-point numbers, that has never been true in general. Consider x=1, y=49 in the realm of IEEE doubles. Addition isn’t even associative, consider 1e-50 + 1 - 1.

Also just defining division to be whatever you want in the moment is not actually pragmatic, it's stupid and trivial. There's a reason we define a symplectic manifold the way we do. There's not a reason to say `1/0 = 0`, aside from the fact that the Pony designers didn't care to find a good solution to the problem.

What if number types were Optionals after any operation that could result in any kind of unusual number (sqrt(-1), Infinity, NaN)? Or maybe after every operation, since any operation could overflow the type.

Do any languages do that? Seems more consistent (if way more hassle) than giving a mathematically false result out of pragmatism. At least in a strictly typed language.

This thread is showing once again that reading comprehension is not our strong-suit here on HN.

The author does not once say that Pony's choice is a good one, only that whether it is a good or bad one should be settled by engineering consequences, and that there is no purely mathematical argument that precludes it.

I can't help but think it _is_ a bad idea, because it's easier to overlook a 0 appearing than a NaN. That argument isn't math, though.

The Pony devs did chime in and mentioned that they do define division by zero to be NaN (or positive infinity) where the underlying type supports it (e.g. IEEE 754 floats).

Most integer representations have no space for such a value, so the only choices available to language developers are:

1. Throw an exception or otherwise consider it an error

2. Define the result to be 0 or 1 or some other integer value (0 being the only good choice)

3. Use a non-standard integer representation

Most languages opt for option 1, Pony chose 2, and I've never seen 3, perhaps due to it requiring so much software interference and precluding inter-operation with other languages.

It sounds like from what I have learned elsewhere on here that Julia is doing something interesting here.

https://news.ycombinator.com/item?id=17737308

https://news.ycombinator.com/item?id=17737158

> 0 being the only good choice

Devil's advocate: why not a maximum integer like 18446744073709551615 or 9223372036854775807?

0 looks like a valid number, while 18446744073709551615 is an obvious NaN for any programmer looking at the output.

Pony requires special handling of partial functions. Option 1 means all integer divisions by other than constants would be partial.

That seems sub-optimal.

> We’ve now established that if we choose some constant C, then defining division such that x/0 = C does not lead to any inconsistencies.

No, you haven't. You've merely failed to locate any. You've said "I'm not going to prove that this works. I'm going to assume that it does and act as if it did, and place the burden on you to prove otherwise."

Absolutely correct. That said, proof assistants are being used. Here's a quote from TFA:

> Lawrence Paulson, professor of computational logic and inventor of Isabelle: > > [...] This identity holds in quite a few different proof assistants now.

Wrong. Division is not part of the field axioms, it is a defined function, and changing its definition has absolutely no bearing on the consistency of your equational theory.

> No, you haven't. You've merely failed to locate any. You've said "I'm not going to prove that this works. I'm going to assume that it does and act as if it did, and place the burden on you to prove otherwise."

Excellent point. It's not even known if we can get any inconsistencies without making this definition; and it's known that, if it's true that we can't get any inconsistencies without it, then we can't prove that it's true. Building on such possibly shaky foundations can't make them stronger.

(That's not mathematical maundering, by the way; it is a correct if informal statement of part of the incompleteness theorems. I appreciated excalibur (https://news.ycombinator.com/item?id=17736486 )'s point, and wanted to underline the significant, and mathematically precise, difference between "one apparent inconsistency is not present" and "there is no inconsistency.")

It's painful how dumb this blog post is. It's clear that the multiplication is no longer associative with this definition.

This article grinds my gears. He quotes a number of mathematicians that correctly state the undefined nature of 1/0. Then proceeds to interpret that this means that we can choose any specific value to represent as 1/0 that we want. NO. We have "NaN" for a reason and it is an important signal to the programmer that a mistake was made. The language that assigns it to 0 silently is bunk as is this article.

> correctly state the undefined nature of 1/0

Erm, when we say it's "undefined" we mean it literally -- standard mathematical systems of arithmetic do not define a value for that division.

If you make another system of arithmetic you can define it how you want and be consistent with "regular maths" for the operations in which things are defined. It's an extension.

> We have "NaN" for a reason

Funnily enough, IEEE754 defines 1/0 as positive infinity, not Nan. But none of these things are "the truth" in any reasonable sense of the word, just "useful systems".

Defining it as 0 at least means floating point numbers are (presumably) closed under arithmetic operations, which could be handy.

> Defining it as 0 at least means floating point numbers are (presumably) closed under arithmetic operations, which could be handy.

They already are closed. Floating point includes Inf and Nan for that reason. :-)

Standard mathematical systems of arithmetic do not permit a reasonable definition of 1/0.

Mathematicians define equality of fractions by stating that a/b = c/d if and only if a·d = b·c. This means that if we define 1/0 = 1 then 0 = 1.

To be fair, this is perfectly consistent, except everything in our system is equal to zero.

IMHO I think the problem here is that most people focus on the "wrong side" of 1/0.

I mean, what the mathematical definition of division says is not that 1/0 is indeed something and that that something is "undefined" or "NaN" or anything else really. What it says is "I cannot do 1/0, the division operation a/b does not apply when b is 0".

So 1/0 is not a thing in itself in mathematics; it's something which cannot be operated.

Now, back some time ago, "division by zero" simply threw an error. It signaled "this is not something that can be done". undefined, NaN, anything else, including 0, is not really something that has a mathematical justification. It's merely a practical approach to encapsulate that error into some form of pseudo-value to control it to some extent.

Personally, I don't really see how 1/0 = 0 is better than 1/0 = NaN or "undefined" or "Infinity".

The practical downside is that it might make equations go slightly wonky, rather than completely wonky if a non-number is returned.

For example, say if a zero divide happens with normalized values. Meaning the immediate result is only off by one at most. Odds of catching that are probably low. Meanwhile, a NaN will infect all numbers that come into contact with it, bubbling up faster...

Under this system, programs are easier to debug if they use bigger numbers... That property does not seem like a win to me.

If I attempt to open a file, but an access fault occurs, I'd rather be told the fault and given a chance to recover than receive an empty file.

Except that 0 could actually be the result of a valid computation. NaN, undefined, or Infinity can not.

Are we reading the same FA? In the section titled "The Real Mathematicians" the author has quotes of mathematicians saying that defining division by zero as zero is OK.

Not all of them, though.

I find particularly interesting Leslie Lamport's comment that "Since 0 is not in the domain of recip, we know nothing about the value of 1 / 0", which I think is the most correct mathematical stance.

Then again, I think it is all a red herring. This (Pony's decision) is not about the mathematical definition of division. This is about the trade-offs computational systems do to manage the situation.

"defining division by zero as zero is OK" And those mathematicians should be classed as wrong. If you treat zero as nothing, a value divided nothing does not make it magically disappear, it should just cancel out the mathematical operation. So 1/0 should be 1, 42/0=42 and so on. Otherwise to apply their logic, a*0=0 would have to be applied. Again if you take a value and multiply it with nothing, it should cancel out the maths operation. It is possible for whole areas of a science to follow down the wrong rabbit whole, medical science best shows this over the last 100-200yrs since scientific equipment has improved and the current thinking about something in the body has changed when new discoveries appear that contradict. Maths is not untouchable either, especially considering the fact Big G and the speed of light varies. Check out Rupert Sheldrakes of Cambridge Uni talks on this subject. The official bodies response was to mandate G and speed of light is now constant when its not.

My two issue with this is it totally relies on a specially constructed definition, and it leads to unintuitive results.

The issue with special definitions is you can use them to say anything you want, turning regular, common operations into weirdness.

What does it mean to take a factorial on the real numbers, or to add only on the even integers? In both cases, we're twisting what are generally accepted mechanics and domains into something else to get a funny result, like 1/0 = 0.

He gets to that point here:

" We can say that division’s domain is all the real numbers except zero. This is what we do in our day-to-day lives, and the way that Agda and Idris handle division. We can choose some value that isn’t a real number, such as “undefined” or infinity, and say x/0 = <whatever>. This is what some mathematicians do with the Riemann sphere. We could choose some real number, like 19, and say that x/0 = 19. This is what Isabelle, Lean and Coq do.

So, tiny change in definition --> big change in outcome.

*I'm an undergrad

You may not be familiar but a "factorial on the real numbers" is the gamma function and it has all sorts of useful applications. (it works on real and complex numbers except for non-positive integers)

The concerned reader might wonder how it is possible to assert that there is _one_ correct definition of an extension of the factorial function to the real/complex numbers. Why is the gamma function better than any other extension?

The answer is that the gamma function is the unique logarithmically convex extension of the factorial function.

> What does it mean to take a factorial on the real numbers, or to add only on the even integers?

I don't think that's exactly the same problem.

It is perfectly valid to define an operation on a particular domain. Defining an add operation on even numbers is perfectly fine (If you had said odd, well...). Factorial on real numbers is more or less the Gamma function. The problem here is that the operation is defined on one domain...

> We can say that division’s domain is all the real numbers except zero.

...but then, for some reason, it is decided that will will be applied on a different domain. That is, that we're going to apply on all real numbers including zero. So now we need to modify the definition of the operation. And the thing is that, the new definition, created to accommodate the new domain, usually tends to produce friction precisely on the new elements added to the domain. We excluded zero initially because that way the operation was defined in a simpler way. Now, having to consider zero implies that our definition becomes more "complex".

Now, we can change the definition in different ways. Is any one of those objectively "better" or "worse" than the rest? Well, that's what the discussion is all about.

Just wanted to share: C++ allows you to overload operators, so you can certainly create your own universe of mathematics if desired.

Edit: I guess there's a reason I'm not a language designer.

I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible with the type-checker.

Setting your programming language to evaluate x/0 = 0 seems evil. You're taking a bug in the programmers code and then hiding the fact that something logically unsound happened and in a way that would be very difficult to debug or detect.

In fact, this is what happens when C# think it's being clever by returning infinity as the result of a division operation (which isn't even a number). It's a bug that winds up infecting every function that relies on that code without ever throwing an error.

A programming language shouldn't return NaN or Infinity or anything like that when it encounters division by zero. It should demand you use error-handling or ensure it can't happen. If it does happen, it should tell you exactly where the problem occurred and not assume that some arbitrary value will work just as well.

Hi,

I'm on the Pony core team and I generally agree with you. The problem is, if you want to allow people to write high performance code, you are penalizing them becaues, for floating point:

1.0/0.0 is infinity. That's not C# being clever. That's C# following the floating point standard and using the math that the computer provides. To not use that standard means that you make every use of division slower, even if the programmer has in some way assert and otherwise knows that that they won't be dividing by zero.

Note that 1/0 is integer math and for that there is no standard and its undefined behavior. You can't return NaN or Infinity for that without boxing numbers which is a performance hit and would be penalizing programmers who want/need to go as fast as possible.

This kind of type becomes really tedious to use unless there is some sort of viable "subtyping"—you certainly want to be able to use a non-zero number where any number works and, ideally, you want to be able to recover a non-zero number when you write a function that takes in a normal number and always returns a positive value. If you're forced to use a bunch of explicit conversion functions to achieve this you add a lot of noise to your code and, generally, the most common function is going to be along the lines of "I know this is positive, so throw an error if it's 0"—which is exactly what we get anyway.

Explicit might be better than implicit most of the times, but it is possible to be too explicit.

That said, we can achieve this, although it's probably a bit trickier than you'd think at first. The best option I know is called "refinement typing", which basically allows you to specify types as subsets (ie "the set of integers which are not 0") and automatically verifies whether your functions actually return a value in the subset.

Liquid Haskell[1] is an example of a system you can use today to play with the idea. It uses an automatic logic solver (Z3) under the hood to automatically prove that your refinements hold. (For example, I believe it should be able to automatically verify that the function f x = abs x + 1 will never be 0.)

[1]: https://ucsd-progsys.github.io/liquidhaskell-blog/

I think you’ll find that extremely annoying in programs that do ‘real’ calculations. The compiler will rarely be able to prove that a divisor is non-zero, so you will have to add lots of code to handle edge cases. That can be worth it if you are writing robust numerical code, but I doubt even those writing numerical software libraries would want to handle each edge case.

Worse, division by zero is just the tip of the iceberg. There’s overflow and underflow (which both can happen with addition, subtraction, multiplication, and division) and invalid operations (0/0, √-1, arcsin(2), etc), and you might even want to extend this to detect inexact computations (e.g. to properly report whether you are sure a later division by zero actually is a division by zero)

IEE754 ‘won’ because it is relatively simple to use and many times good enough for real use.

So what type is `integer - integer`? It might be zero, but the type system doesn't statically know whether it is or not. If the result of every arithmetic expression is possibly zero, then you're back to run-time checks for every value. I don't see how this is practically useful.

Error handling your infinite results would dramatically slow down your programs. And C# doesn't think it's being clever, it's following IEEE float behavior implemented in the hardware.

I don't think this really solves the problem. It just kicks the same problem over to addition instead.

    let a = 17
    let b = 10
    let c = 7
    let d = a - (b + c) // throws AddsToZeroException

> Make division by zero impossible with the type-checker.

Forcing programmers to consider division by zero when it occurs can be done simply by having the language compiler force handling of a divide by zero exception when division occurs.

Rust recently added nonzero number types (see https://github.com/rust-lang/rfcs/blob/master/text/2307-conc...). Though I believe the primary motivation here was the reduce memory usage in some special cases.

The complaints from tikhonj about verbosity are on point, but I think you're right about the shape of it. Other things being equal, it's much better to enable the type system to help you move checks further upstream.

You still have runtime issues if you're doing arithmetic with that type and end up getting zero.

Unlike what the author says, this is the total opposite to a practical/pragmatic solution.

He does not prove that this is a useful representation, only that given his own axioms, this can be considered mathematically correct.

Very practical issues with 1/0 == 0:

- This result is counter-intuitive, took building a custom fields and responding to the incredulity of all. - The main reason this is counter-intuitive is not mentionned in the post: division is no longer monotonous.

1/0.5 = 2 1/0.25 = 4 1/0.0001 = 10000 1/0 = 0

This is calling for an Ariane 5-type crash because an underflow error caused a value to suddenly fall from 10e6 to 0.

> This is calling for an Ariane 5-type crash because an underflow error caused a value to suddenly fall from 10e6 to 0.

That’s the opposite of what happened. A value overflowed, which triggered an exception, which caused a module to emit diagnostic information, which was misinterpreted by other systems as flight data. Interestingly, the value which overflowed was part of a system which was only used until LT+7, which had aleady passed…

In short, if the overflow had simply saturated or wrapped around to 0 or given some other garbage result, the Ariane would have not crashed.

Were are speaking of integers here not FP numbers.

Not to be pedantic, but one of the author's own examples involves pi inverse, so I think discussing FP numbers is valid.

The article mentions floating point numbers as well, and the same applies to integers anyway. Only used FP numbers for emphasis.

I think this is calling for a Pony programmer working with floating point to know how their own basic operators function. Wrapping division in a function that checks for zero will give you the proper result you would like to return.

Ah yes, the wobbly-step school of language design.

Hrm ... argumentation by reference to authority (various Ph.D. people) is a sure way to lose a scientific argument.

But that isn't my only qualm.

In the construction of the fields, there is a simple definition of the division function. It is intrinsically the solution of a = r * b, where r is the unknown. If a is nonzero, and b is zero, then r, the ratio, is said not to exist. Put another way, there is no real value of r that can be chosen that satisfies r * 0 = a. See [1] for example, as 0 is not an invertible element of the field over the reals.

So ... I can't say I agree with their choice of 1/0 == 0. They may be free to choose any value they wish, but then from an aesthetic viewpoint, do they really want to surprise the user?

[1] https://en.wikipedia.org/wiki/Multiplicative_group

>In the construction of the fields, there is a simple definition of the division function. It is intrinsically the solution of a = r * b, where r is the unknown. If a is nonzero, and b is zero, then r, the ratio, is said not to exist. Put another way, there is no real value of r that can be chosen that satisfies r * 0 = a.

Exactly. That's the definition of division. Here, he is introducing a totally different definition and claiming it isn't wrong because it is consistent. I mean, by his logic I could define division as a/b := a-b and claim it is consistent and therefore not wrong, but that is obviously not division...

"Mathematics does not give us truths, it gives us consequences."

I'd like to point out that, as I stated in another comment in this thread, the author's supposed refutation of the inconsistency inherent in division by zero within fields is incorrect. Their refutation is as follows:

The problem is in step (3): our division theorem is only valid for c ≠ 0, so you can’t go from 1/0 0 to 1 * 0/0. The “denominator is nonzero” clause prevents us from taking our definition and reaching this contradiction.*

This is a strawman, and it's not the way a formal proof that division by zero in fields is undefined would proceed. First and foremost, the conceptual purpose of the proof is to demonstrate that you cannot define division by zero while still retaining the algebraic structure of a field. Trying to refute this point by stating that the proof cannot make use of division by 0 is begging the question. The whole point is that the proof shows you any way you define division by 0 is going to compromise your definition of a field, or it's going to make fields with nonzero elements impossible.

What the author provided is a very contrived strawman for refutation that belies the actual point. You can define division by zero if you'd like, by using wheels, or extended number systems based on fields (i.e. positive and negativie infinities in the extended Real number system), but you cannot do it using fields. In fact, the modern, axiomatic definition of a field explicitly excludes the unit 0 from the otherwise sane rules of multiplicative inverses.

More generally, I'd like to make a couple of observations from both a philosophical and a practical standpoint. First, mathematics does not give us true statements about the world, it gives us consequences that must follow if we accept various axioms or definitions. You can define division by 0 if you'd like, and you can even do so in a sane and useful way. But you will not have a field. But much more importantly, it's conceptually unsound to base an argument about the practical, programmatic behavior of an undefined operation based on imperfect arguments about abstract mathematics. Technically speaking, computers don't even deal with real numbers. If you find yourself mounting a defense of your programming language's behavior by running through the first lecture of a real analysis or linear algebra course, something has gone very wrong with your enterprise.

> The whole point is that the proof shows you any way you define division by 0 is going to compromise your definition of a field, or it's going to make fields with nonzero elements impossible.

But it does neither. All field theorems pertaining to inverses/division take the form `x ≠ 0 ⇒ ... x⁻¹ ...` None of them is compromised.

> In fact, the modern, axiomatic definition of a field explicitly excludes the unit 0 from the otherwise sane rules of multiplicative inverses.

Exactly, which is why defining 1/0 = 0 (or 42) poses no problem to fields (BTW, the Lean proof assistant defines 0⁻¹ = 0 for fields, even though it's not the inverse and 0*0 = 0).

The whole problem is one of formalization. "Undefined", as it's used in mathematics, is very much informal. It is used to say that a certain expression, 1/0, while "grammatically" correct, is meaningless. Formal systems simply cannot do that: the expression 1/0 must either be ill-formed (can be done with dependent types but is often inconvenient) or it must mean something in the semantic domain of the language. Different formal system define what that something is, but whatever it is, it is no longer "undefined" in the informal sense.

It seems like he covered that in the article. There is no multiplicative inverse of zero.

But that isn't the same as defining a division operation.

First, mathematics does not give us true statements about the world, it gives us consequences that must follow if we accept various axioms or definitions.

Isn't a consequence in itself a true statement?

I'm not seeing how the tweet is mocking the Pony developers. It seems to mirror the tone and the content of of the documentation in the screenshot. It looks like an absurdist spin on the ivory tower vs industry meme, and it doesn't make anyone the butt of the joke.

The screenshot in question cut off the explaination of why. I'm one of the Pony developers and I took it to be mocking.

Thanks for replying! I took a look at the thread in question and you're totally right. In context, this is unambiguously snide. I've been fortunate that my learning and working environments have been absolutely free of this kind of mean-spirited nonsense, so it really took me by surprise.

I mean sure Pony, but as a programmer this result would surprise me quite a lot, which I tend to view as a bad thing.

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

However:

> One of developers of Pony reached out to me. They’re planning on writing a more in-depth explanation of why Pony chose 1/0 == 0, which I will linked when available. As I understand it, it’s because Pony forces you to handle all partial functions. Defining 1/0 is a “lesser evil” consequence of that.

I am looking forward to this write up.

Based on the tweet, I don't expect it to be very enlightening. Since programmers write programs to solve real problems, and real problems define 1/0=undefined... then this is only going to mask bugs in those programs.

It's quite staggering how many people have posted on this thread without reading the article. Nearly all the objections people have raised are directly addressed in the post.

For those who still object to the argument, would you object to me defining the piecewise function f:R->R defined to be 1/x for x =/= 0 and 0 for when x=0?

Nearly all the objections people have raised are directly addressed in the post.

Are they? I see nothing in the article about the negative consequences of surprising users with silent failure, for example. Or the fact that it makes little sense in real-world scenarios.

would you object to me defining the piecewise function f:R->R defined to be 1/x for x =/= 0 and 0 for when x=0?

What do you mean by objecting to you defining a function?

The post is not about whether this is a good choice for its users; the post is about whether there are nathematical objections to it. The author even writes that they don't agree with the engineering decision to define it like that, but they can't object with an appeal to mathematics. It lists three valid choices for handling division by zero and Pony picked one of them. My personal favorite is to shrink the domain but that's not supported in most languages and those that support it are often not meant for number crunching.

> "see nothing in the article about the negative consequences of surprising users with silent failure, for example."

That's because the article is purely about the mathematical consistency of using 1 / 0 = 0. It explicitly and repeatedly mentions that it's not about real-world logistics.

> "What do you mean by objecting to you defining a function?"

The author is defining the division function with this special mapping, f, which includes 0 in the domain. Damn near everyone in this thread is confusing that definition with defining the multiplicative inverse, 0⁻.

It's an understandable confusion, but also honestly getting pretty frustrating. That's what he or she is getting at.

What proportion of the time will a programmer intend and expect 1/0 = 0?

What proportion of the time will a divide-by-zero operation be a symptom of a bug, where evaluating 1/0 as any valid number will make it harder to identify that bug?

There might be a mathematical justification for 1/0 = 0, but the computer science justification seems tenuous at best. The overwhelming majority of the time, I want divide-by-zero to throw an exception or evaluate to NaN. I'd far rather deal with the edge case of intentionally dividing by zero, rather than the not-at-all-uncommon case of unintentionally dividing by zero and getting unexpected behaviour as a result.

We’re talking here about integer math. Integer math on CPUs is usually fast at the expense of having coherent semantics. It isn’t even really “integer” math in any mathematical sense. It’s just “the fastest math that the CPU is capable of doing, which happens to look a lot like integer math most of the time.”

If you’re dividing floats, you will get NaN or Infinity as expected. Just like how, if you overfloat a float, you’ll get Infinity. Floating-point has well-defined semantics, which CPUs are required to adhere to, and languages just expose.

If you divide “CPU integers” by (CPU integer) 0, the result is undefined. Just like how, if you overflow a “CPU integer”, the result is undefined. There is no standard semantics being adhered to. There is no equivalent of IEEE754 for CPU integers. There is only convention, and convention has no universal answer at these edge-cases. Thus, a language is free to do whatever it wants in response to either. There are no formal semantics to expose.

Usually, a language that calls itself “safe” will choose to make CPU integers behave a lot like real integers, by generating checks and throwing exceptions for the edge cases.

And usually, a language that calls itself “low-level” will just expose whatever semantics the CPU integers of its host platform already possess. In the case where there’s still an impedance mismatch (i.e. in the case of division by CPU-integer-0 where you don’t actually get any output into a result register), the language has to make something up. To “go with the flow” of how CPU integers work, probably it should be something fast.

Thus, 1/0=0 kinda sorta makes sense. It is an operation on the field of “CPU integers” that vaguely “fits in” with the existing ones. No mathematical relevance, but just fine from the perspective of someone e.g. seeking to create a higher-level abstract machine targeting the Pony compiler, where you’d still just insert a divisor check before doing the division op if you wanted the result to make any sense.

I very strongly object to this convention, as both a programmer and a mathematician.

A basic theorem is that for any field we must have that a/b = c/d if, and only if, ad = bc. See theorem 2 in this classic text here for a proof[1]

So if 1/0 = 0, then we also have 1/0 = 0/1, which implies 1 x 1 = 0 x 0 which is a contradiction. But then we also have 1/0 = 0/x for any x, hence we also have shown x=0 for any x, which is an infinite number of contradictions. Is this a problem which is addressed in the post that I missed?

By the way, I have spent more time than it's polite to discuss in public studying the topic of dividing by zero, and also what 0/0 means. If you are also interested in this topic, the best youtube video is by Mathologer and I highly recommend it to everyone. See here [2]

[1] https://books.google.com/books?id=3ApEDwAAQBAJ&lpg=PP1&pg=PA...

[2] https://www.youtube.com/watch?v=oc0M1o8tuPo

So... if I do:

   x = a/b + c/d + e/(f*g/h)

I need to check:

   if(b == 0 || d == 0 || f == 0 || g == 0)

rather then:

   if(isFinite(x))

Or whatever function/equality check is appropriate, or a try/catch if it throws an exception.

I have to say that using a single check on the result seems significantly less prone to bugs then having to check all the values that could produce an invalid result.

Without NaN you don't get to see that the computation "went wrong". But that's not necessarily a problem, and only if it is must you check whether those inputs are zero.

Still, I agree that a NaN value(s) is(are) preferable for this reason.

Of course, there will be cases where you need to check some of the initial values regardless, but often you just care if the result is valid. From a defensive programming stand-point, if you don't expect any of those values to be zero, you just check for NaN at the end rather then carefully reviewing your calculations for which values you have to check.

I would REALLY hate having to write a geometry library without NaN values. Both because of error checking, and the fact that NAN/INF is often the 'correct' answer when it's the result of a calculation.

The problem being that constructing isFinite(..) for machine integer types is basically impossible.

This is very bad for numerical code. When you divide by almost zero you get a big number. If it becomes a zero it should be even bigger number. Having 1/0 = +inf is a perfect solution. Setting it to 0 breaks continuity and isn't useful at all.

One of those proposals which can only be made when you don't take time to understand and appreciate use cases the current solution was created for.

> Having 1/0 = +inf is a perfect solution.

It makes sense if we have signed zeros; then +0 represents an infinitesimal positive value. IEEE 754 has signed zeros, though the signs may sometimes not match programmers' expectations, e.g. 1 - 1e-50 - 1 == +0.

Maybe 1/+0 == +inf is reasonable, but would you agree that there's no reasonable answer for 0/0? So IMO, reasonable languages must define division as a partial function, or a function that can throw an error (or return NaN, Nothing, etc).

And if division is a partial function anyway, it seems best to not allow division by zero at all, since even 1/+0 == +inf can have unexpected consequences.

> Lawrence Paulson:

> > These things are conventions, exactly the same as announcing that x^-n = 1/x^n and that x^0 = 0.

Say what? x^0 is 1, and not by convention, other than in the 0^0 = 1 case.

I was thrown by that too, maybe it was a typo?

FWIW Pypy used to share this behaviour. It was clearly a bug, as it doesn't follow CPython convention.

It's around since 2013 and was found in a unit test coverage improvement effort in Feb. 2018.

Given that pypy is mostly used for hard-core math and scientific computations, how the hell this bug wasn't found earlier by a user ?

My bet is that ZeroDivisionErrors are very rare. Do you even remember a ZeroDivisionError in production code ? I don't.

1/0 is my dirty little trick to add a breakpoint when I'm too lazy to launch a debuger. Why does this work? Here again, because nobody never catch ZeroDivisionErrors, because they don't happen.

So, what a fuss for such a tiny convention. Granted, it breaks the math correctness, as do ±Infinity. CPU integer math is broken anyway. In what world does 2^31 - 1 + 1 == -2^31 ?

I took a fairly large, used and old repository, Django and I search for ZeroDivisionError:

https://github.com/django/django/search?q=ZeroDivisionError&...

guess what:

- 4 occurrences in the tests

- 3 occurences in the issues

- last, but not least 1 occurrence in the code:

   except ZeroDivisionError:
       result = '0'

Oh sure, there are infinite numbers of matrices without inverses and no one cares.

But you try to slide one little real number without an inverse by and everyone freaks out.

> We’ve now established that if we choose some constant C, then defining division such that x/0 = C does not lead to any inconsistencies.

There is no proof in this post that 1/0 = 0 maintains consistency. Rather, it contains refutations of one or two arguments that claim inconsistency, along with appeals to authority.

You're right. It really would've been nice for the author to offer a direct proof.

However, while I'm a bit rusty, I think it basically has to be true. For there to be an inconsistency, 1/0 = 0 must either

a) imply the negation of some previous theorem of arithmetic or

b) imply that 1/0 = x, for x != 0.

I think a) can only be true by way of b), since no existing theorem of arithmetic involves the expression y/0 for any y. I confess, I don't know the right way to prove that b cannot be a consequence, but it doesn't look like one.

Edit: I think it's just trivial to take a model of the existing axioms, then add n/0 = 0 to the division relation.

You have to add extra "except when"s to every theorem involving division. E.g.:

(a+b)/c = a/c + b/c

(in particular, for C != 1, as the author claimed it would work not just for 0 for for any real number)

Now to say this is true you have to say "unless c = 0", whereas before that was automatic from the definition of division.

The explanation in the article basically boils down to the following:

let a/b mean, in my programming language's syntax, = { a divided by b when b is not zero, or 0 otherwise.

Yeah, it's not "mathematically invalid," but it punches a hole in the fidelity between numerical methods and the math that they approximate.

I knew that but my friend didn't. So thank you for explaining that for my friend.

This is "Worse is Better[1]" engineering at its most infamous. In order to make the interface consistent and simple you take the exceptional case and just make it work the same as all the other cases. It goes with the "Worse is better" credo that "it is slightly better to be simple than to be correct". Also "it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation". So throwing an exception on division by zero or returning some complex thing like NaN is too much complexity, so we just return 0.

[1] https://en.wikipedia.org/wiki/Worse_is_better

Let f(x) = 1/x, then (from a mathematician’s perspective) the limit of f(x) as x->0 doesn’t converge and is representeted as being infinite, definitely not zero.

As the denominator gets smaller, the result is bigger and bigger and bigger. The closer the denominator gets to zero the larger the result. Why would we want to pick an answer that is small when instead it should be larger than any number?

One might argue that 1/0 should be MAXINT or IEEE 754 plus infinity due to the limitations of our hardware, but I’ve never wanted 1/0 to result in zero in any program I’ve ever written.

I would prefer that it be treated as an error or possibly some reserved value that behaves like INF while still being an integer in the programming language.

Well, you have an ambiguity as to whether it should be +INF or -INF, depending on which side you take the limit from. Arguably, 0 is more reasonably because it preserves symmetry. Of course, it would be far more reasonable to define this as an exception, because you shouldn't be able to do division by 0.

First the difinition of given of a field is wrong https://en.wikipedia.org/wiki/Field_(mathematics) . But why not? the author might not know but 1/0 is by definition the inverse of 0 and that s why 1 * (1/0) = 1. What he do is extanding the definition of the division FUNCTION. And you can always do that. But by doing that you lose most of algerbaic and arithmetical propreties for numbers. But worst! There exists 1/ 0 = infinity, but also infinity * 0 = 0(in probability). So please stop creating fake controversies about stuff that really doesn t need ANY DEBATES.

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks

a=x/N

b=y/N

If a==b, then x==y

No longer true, with this change. Essentially a variety of mathematical properties of numbers in the Real space don't hold when you allow division by 0.

“Nothing breaks” in that it isn’t unsound, in that you can’t use it to prove a falsehood. Not that you can’t use the nice little shortcuts you’re used to.

In practical terms, that _does_ have an impact, because people might use those shortcuts without realising the system they’re operating under doesn’t allow it.

But you picked the wrong quote to make that point under.

This is not true if you say division by 0 is undefined or +inf either. It really is totally fine.

well, as long as you aren't doing calculus

I am not really a programmer or mathematician, so take this for what it is, but to me, the statement makes linguistic sense, if you read it out like a first grader.

If I divide one thing into zero groups, how many items do I have in each group? Zero. Edited per comment below.

If I were really pedantic, I'd say that in the above, it's almost like the input "1" is not being divided, but grouped.

The funny thing then, is that if I am grouping instead of "dividing", then if I enter 1 modulo 0, I'd expect to get 1. i.e. the modulo zero should be an identity function: 1%0 = 1, c%0 = c.

I think you mean if I divide one thing into zero groups, how many items do I have in each group

Edited, thanks!

I must admit I prefer 1/0 not to be 0 in the "Common Algebra". But that might be because I come more from an Natural Science/Engineering background where continuity is something that is expected virtually everywhere. Not even Theoretical Physics text books mention that continuity of functions is required as it is so ubiquitous. 1/0000000.1=10000000, 1/0.00000001=100000000.0, ..., 1/0=0 would break that. In fact we have even harder requirements usually we want everything at least twice differentiable...

However, nobody stops people from defining their own Algebras or Fields on languages that support it. On C++ this should be a no-brainer, if the sentiments of the article is true that consistency is no problems. Being a "man of industry" myself, 1/0 throwing or at least becoming infinity doesn't seem a problem to me. Similar to not using gotos or so.

FWIW, JavaScript an underrated language when it comes to weird corner-cases does the right thing. It doesn't throw an error, instead the result becomes Infinity. When I multiply it with a finite number it stays Infinity. When I multiply it with 0 it becomes NaN which is totally sound because in a real-world application one could come to these numbers because of limitations of the storage. 0.00000......1 becomes 0 thus the real result of 1/0 x 0 in that case can indeed be literally everything. The beautiful thing about JavaScript is how it continues to handle this, when I say 1 < NaN or 1 > NaN it stays false. So the algorithms are likely to fail much more graceful than in other languages.

JavaScript’s behaviour is just how floats work. They are the same in all languages. There is storage reserved as part of their representation to encode infinity and NaN.

The issue here is hardware integers, which have no signalling bits beyond possibly sign.

Sure, JavaScript uses floats for everything. But the article seems to be actually mostly about real numbers: "The real numbers, along with our conventional notion of addition and multiplication, form a field." (Ignoring the fact that there are finite fields that are properly closed under all operations)

> These things are conventions, exactly the same as announcing that x^-n = 1/x^n and that x^0 = 0.

The convention that x^0 = 1 (including 0^0 = 1) is genuinely useful because it removes a case distinction from lots of combinatorial formulas. Hence this: http://tinyurl.com/zeropowerzero

x^0 = 0 seems to me to be - I won't say "wrong" because you're free to define things the way you like - in general less useful than x^0 = 1.

For similar reasons, (0 * log 0) = 0 makes sense when computing entropies and stuff in certain machine learning applications. This one can also be justified as the limit of x * log(x) as x -> 0 is 0, but I've seen at least one person just trying to define "log 0 = 0" which I consider less elegant; in the kind of application where this convention is useful, you'll rarely if ever see a log 0 that's not multiplied by a plain 0.

Where it gets really weird is when you do KL divergence and can end up with 0 * log (0/0), but again you can save a case distinction by just declaring this to be 0. The elegant way to do this is to define d(p, q) = p * log(p/q) when p, q != 0 and 0 otherwise. In this particular application, just going with 1/0 = 0 seems to work fine in practice as in a term q * log(q/0) you can rewrite the whole thing by flipping the sign to get 0 * log(0/q) in that term, which we have already declared to be 0 (whether or not q is 0 itself).

In this case it's not a bug in the code, it's being able to handle probability distributions with mass 0 on some points at the level of arithmetic rather than as a special case in the formula.

You lose simple properties of division, such as (a + b)/c = a/c + b/c.

If you set 1/0 = 1 (as the author claimed causes no inconsistency), then (2 + 1)/0 = 2/0 + 1/0 is false

If you come to rely on division by zero behaving a certain way (as happens to all features/bugs of any language), then suddenly silly decisions about how to implement a formula can cause wildly different behavior. Good luck refactoring!

(a + b)/c = a/c + b/c for c ≠ 0. Otherwise it has no meaning.

Therefore (2 + 1)/0 = 2/0 + 1/0 is not even false, it just means nothing.

BTW, you didn't mention Infinity explicitly, but it would lead to the same inconsistency, if you think about it:

(2 - 1)/0 = 2/0 - 1/0

I had considered this as a possibility following much the same train of thought expressed by abakker but because it diverges from most common practice (and from mathematics) and because I was unsure whether anyone would actually want it, I had not really considered using it.

While reading the article and the comments I realized that it will work perfectly in my NISC processor [1]. I just need to update my specification.

To extend the simple first specification to include multiply is very simple. I just need to have a MUL register which, when written, multiplies the written value by the value in the accumulator with the low part of the result being left in the ACC and the high part in the MUL register.

Extending to include integer divide is a little more complicated. I will have to add a DIV register and a DIVEX register. Writing to DIV will divide the value in the ACC by the value written leaving the result in the ACC and the remainder in the DIV register. DIVEX will contain the address of the routine to call when division by zero is attempted which means that DIVEX must be loaded before division is used. If I specify that DIVEX is initialized to zero by the hardware and that DIVEX==0 means that divide by zero leaves zero in the ACC and the remainder (former contents of ACC) is left in the DIV register then 1/0 = 0 will be the default behavior with the ability to change that behavior simply by writing the address of the divide exception handler to the DIVEX register.

I leave it as an exercise for the reader to determine how to deal with this in high level languages. I can fully support it in machine code and assembly language.

[1] https://github.com/BillBohan/NISC

I’m not sure if a general system should deviate from established definitions but in specific programs I certainly bend the rules.

For instance, I made a game, and I might accidentally end up with a value that won’t modulus correctly due to zero denominator. In that app, mathematical accuracy for this single outlier does me no good at all because it manifests as “might crash randomly” when I want “doesn’t crash, period”. I therefore wrote a “safe modulus” routine that essentially guards against zero and makes a command decision to return a value. The added robustness against crashes is preferable, since I may not know if I have found every stupid case of the math accidentally working out to exactly zero.

In fact, more generally, exact zeroes mask lots of bugs. They are often default initial values, meaning you might not notice something working accidentally. Sometimes I use a really tiny float as my “meant to be zero” to distinguish, e.g. 0.0001 means “item was supposed to appear at coordinate 0”, that way anything that accidentally ended up at 0 is easier to detect.

The standard definition of r = p/q is the number that solves the equation rq = p. This version of "division" does not satisfy that definition, and is therefore not actual division. Call it division* or something.

Edit: it seems that Pony is only doing this for integer "division", which isn't regular division anyway, and the standard rules don't apply.

I remember that 1/n is saying 1 with respect to n increments. 1/4 is 1 out of 4 buckets (of 1 integer). If you have 1/no buckets, it is an amount, but it is impossible to know how much. It's measuring a caterpillar without a unit of measure. "He's 7" "Ok, Im sure he is, but 7 what?" 1/0 may approach 0, but it is not 0.

But what does it give you? I may not like PHP's definition of "5uper" + 3 as 8, but at least I can see an advantage to it, a use for it. What would you do with that zero quotient, any examples? And I mean examples where you haven't checked the value of the divisor (otherwise what's the point). I appreciate spooneybarger's input as a core developer of Pony, because he lets us know this was a difficult decision, and frames the definition squarely in the context of the language.

On the other hand, the author of the article seems to push for a general, mathematical definition of 1/0 as 0. First of all, good luck with that, as there is no standards-issuing body in mathematics. And whether the author likes it or manages to overturn a very long tradition, division is defined when we grow up as multiplying by the multiplicative inverse, with some occasional notes like "Division by zero is undefined for the real numbers and most other contexts [1] or "In general, division by zero is not defined [2], pointing to settings where clearly you won't find consensus.

I refer to when we grow up because we should not forget the intuitive definition Wikipedia gives first and, I guess understandably, MathWorld gives last: "separating an object into two or more parts". As we know, this restriction of two parts can (more and then less) intuitively be loosened to one, negative numbers, rational numbers, real numbers, etc., but only arbitrarily for zero. But then again, even if we unanimously agreed on one value, what does it give you?

[1] https://en.wikipedia.org/wiki/Division_(mathematics)

[2] http://mathworld.wolfram.com/Division.html

Well, it's a design choice that you can make for rational numbers and the restricted rationals with error values that we typically use in computer arithmetic. There's nothing wrong with it and as the article points out, even most proof assistants use this definition for rational division.

For real numbers though, division by zero will always diverge or be undefined, no matter how you represent them. All computations on real numbers are continuous and there is no continuous extension of division which includes 0 in the domain of the denominator.

One can get around this by switching to projective reals (essentially reals extended with a new element that's both +infinity and -infinity). This is no longer totally ordered and has some other problems, but it's actually a great choice for a lot of numerical computations. Yet, I've never seen something like this implemented in hardware, aside from John Gustafson's unum concept.

Once a mathematician explained to me in mind-numbing detail why dividing by zero is impossible, so I understand why this is gross better than I ever wanted to.

But having said that, I do not remember when I last saw a Divide-by-Zero-error in the wild. In practical terms, this is the last kind of bug I worry about.

1/0 = 1(±∞)

https://twitter.com/westurner/status/960508624849244160

> How many times does zero go into any number? Infinity. [...]

> How many times does zero go into zero? infinity^2?

Zero goes into zero x times, for any real x. Infinity isn't real, therefore neither is infinity^2 so no.

Extrapolate.

What value does 1/x approach?

What about 2/x?

And then, what about ∞/x? What value would we expect that to approach? ∞(±∞)

I've used this workaround in genetic algorithms, as has John Koza, the pioneer of the field.

The idea behind this is you're never going to get the computer to program itself with exceptions, so better not to let it produce code it will not be able to execute fully without human intervention.

In some languages, you could define a new division operator that returns an Optional/Option/Maybe result, and then use a nil-coalescing operator to choose what you want in case of division-by-zero. In Swift:

    infix operator /? : MultiplicationPrecedence
    extension FloatingPoint {
        static func /? (lhs: Self, rhs: Self) -> Self? {
            return rhs == 0 ? nil : lhs / rhs
        }
    }
    extension BinaryInteger {
        static func /? (lhs: Self, rhs: Self) -> Self? {
            return rhs == 0 ? nil : lhs / rhs
        }
    }

    10 /? 2 ?? 0  // -> 5
    10 /? 0 ?? 0  // -> 0
    10 /? 0 ?? 10 // -> 10

You can't define your own in Pony but,

/?, *?, +? and -? are coming to Pony. We call them "safe math operators" and will error on integer overflow, underflow, and division by zero.

I consider it infinity because the limit as the denominator goes to 0 is infinity.

I see this with investments that have infinity ROI. If you get into an investment using only other people's money (OPM) and you make a profit then you have made x / 0. Saying I made an infinity return makes more logical sense than I made 0 return.

There's a saying about the difference between a mathematician and an engineer. If there is a $100 bill on a table and each step you take must be half the remaining distance or less the mathematician will never get there, but the engineer will get there no problem.

It's a non-sensical debate IMO but from the investing scenario that I described above, for all practical purposes, it makes more sense to consider it infinity.

> I consider it infinity because the limit as the denominator goes to 0 is infinity.

Note that this only works if the denominator approaches 0 from a positive side. Otherwise it's 0. This is the idea behind the extended real numbers.

FWIW the EEL2 language (part of https://www.cockos.com/wdl/ and what powers REAPER's JSFX audio, video processors, etc) also makes this design decision...

To be honest, this is the kind of post I'd write after a few beers when I'm not giving a shit and I think people have the right idea about something a lot of people would find controversial. Great post! You've made a real contribution here.

If something is undefined in math, it doesn't mean define it with whatever value you want: it means undefined because you can't define it.

The function sqrt(x) is undefined for negative x in the real number system. Is it therefore zero? No. Just because a value is not in a domain doesn't mean just pick one.

Most math textbooks I know and Wikipedia define division as the inverse of multiplication. You are saying that there is a distinction, the inverse of multiplication is not the same as division: you can write 1/0, but that is not the same as 1 * 0⁻.

This is unconventional to say the least, and the only argument you give to make this destinction is your desire to define 1/0 as 0.

I don’t really understand the main argument given in the article; since zero has no multiplicative inverse, you can’t prove anything involving a division by zero. (So why talk about field axioms?)

However, to extend an operation usefully to a larger set of numbers, we can isolate some properties that we want to keep, for example:

1. Division is linear in the first argument: (ab + c)/x = a(b/x) + c/x, for all a,b,c,x.

2. If x has a multiplicative inverse, then x * (1/x) = 1.

3. Taking reciprocals twice gets back to the original number: 1/(1/x) = x for all x.

The choice 1/x = 0 is consistent with all the above, and so probably still “useful”. What properties do you want out of a division function?

Any division either works and returns a result, or doesn't work and doesn't return a result. This is similar to any other function that maybe returns a result (returns an Option<T>/Maybe<T> or even Result<T, E>).

Perhaps it's not a good design to have division as an operator a programming language? Just like

Maybe<int> i = ParseInt("foo")

one should also do this for division:

Maybe<int> q = Div(n, d)

Is there any language that does this (returns an option for default division?)

Obviously, this is also the case for ALL other operations on finite number types because of overflow. But overflow is MUCH rarer than division by zero issues, at least in my experience.

That's interesting. In my career, I've rarely encounted division by zero. I've encountered over and underflow considerably more. Different experiences, different points of view.

As near as I can tell, he's just redefining what division means when the divisor is zero. That is, creating a special case. And yes, I get that it's a useful hack in programming.

So anyway, IANAM. What I learned was that 1/0 is infinity. And in software, that generally means a divide-by-zero error. But I also learned the utility of making approximations and exploring behavior at limits. And 1/x obviously increases exponentially as x approaches zero.

So how, then, can 1/x all of a sudden be zero when x is zero? It makes no sense to me. Call it undefined if you like. But it's obviously not zero.

1/x as x -> 0 is a famously tricky expression because your statement that it "obviously increases exponentially as x approaches zero" is only true half the time, because it's only true if you approach zero from the positive side, with x being set to smaller and smaller positive values. If, on the other hand, you set x to negative values of smaller and smaller size, 1/x actually decreases toward -Infinity. This is one of the several reasons that 1/x is typically considered undefined for the Reals.

Damn, so last night I was thinking about how 1/x approaches ∞ for positive x, and -∞ for negative x. And it struck me that perhaps beyond both ∞ and -∞ is 0, so 1/x might actually equal 0 when x is 0. Rather like closed "liner" paths in closed universes. But again, IANAM ;)

OK, sure. Either infinity or -infinity. But then just look at the absolute value of 1/x. And in any case, neither infinity nor -infinity look anything like zero.

I know nothing about pony, but if it does have an optional type, this would be a much better choice. You lose information by returning 0. Returning "none" would keep the information that you tried to divide by 0. Of course, this means all division would return an optional instead of a value. This is the cost of safe, robust programming.

<rant> I see a lot of software engineers trying to get rid of the cost of writing robust programs. It's not possible. Stop trying. You are either safe, or you are not. You either handle all cases, or you don't. </rant>

This is a case of poor abstraction. Many commenters in this thread explain why, in their application, 0 is a good fallback for division by zero.

But, falling back to 0 is not the correct error handling result for all situations. In other situations, an error is the correct result. The language designers should include proper division, and this style of division should be labeled a "safe" division; or, a division that throws an error should be labeled an "unsafe" division.

I have serious doubts about a language if it chooses one-size-fits-all error handling like this.

This item reminded me of how I've owned a couple different German cars with a fuel consumption meter that showed minimum consumption (or maximum mpg) when the car was idling. It seems like they must indeed have defined (fuel used ÷ distance traveled) as zero when the distance is zero. Which is annoying and grossly wrong in my opinion. For some reason, Japanese cars seem to do it correctly.

It may be true that 1/0=0 can be part of a reasonably consistent system, but that doesn't mean it's a good one. Can we define 1/0 as ∞?

I don’t think 1/0 = infinity is a good choice either, since -1/0 = 1/(-1 * 0) = 1/0, so we would have infinity being equal to negative infinity, which is assumedly not a practical choice. 1/0 = 0 is actually more symmetric in this regard.

While I fully agree, I'd like to point out that reducing specifically to 0/0 = 0 is more generally useful (ie. maintains intuition) than x/0 = 0, which breaks intuition.

Given a/b = c, your intuition of finding c is to get a number such that c×b = a.

c×0 = 0 has an infinite number of solutions, 0 being a particularly practical one.

c×0 = 1 (and more generally a≠0) has no solution, especially in the reduced explanation of multiplication as taking integer multiples of a value.

(Also note that having 0/0 = 0 maintains symmetry and continuity of the function y = 0/x.)

But this is not for man of industry!

there is a pretty good episode on numberphile that explains why dividing by zero is undefined.

Basically the reason why 1/0 = 0 is wrong is the fact that you cant reproduce 1 by taking the answer 0 and multiplying it by 0 to get the number being divided. Which goes on to break a bunch of other fundamental rules of mathematics.

That is to say, if you took 6 / 2 = 3 you can reverse the division by doing 3 * 2 = 6.

However if you have 6 / 0 = 0 and you were to try and reverse it then you would have 0 * 0 != 6. Then you have bizarre circumstance where everything decided by zero logically equals the same thing. Where (2 + 2) / 0 all of a sudden equals (Einsteins laws of gravity) / 0. And there is no logical way to really explain what that is supposed to mean.

Also if you try to use limits to find a solution of f(x) = 1/x where x is defined as the limit of 1 and -1 as it approaches 0 from both sides. You end up with the answer that is even more confusing when you try to graph it.

That is x = +inf and -inf. Which on a graph is represented as two curves where the limit as 1 -> 0 from the positive side of the x axis curves up along the y axis to infinity without intersecting where x=0. And from the negative side where we approach 0 from -1 we end up with a curve that moves down the -y axis without intersecting at 0.

So frankly, n / 0 = 0 just doesn't make sense because just trying to approach it from both sides suggests that the closer you try to move to zero from both sides the further apart the answer moves away from converging together at the origin. Which would be expected if n / 0 = 0 was actually true.

I'm writing a software language that has 1/0 = 0 as well. In my case, I am experimenting with several ideas, two of which are no runtime errors and no exceptions, so everything is either a logic error (aided by multiple return values) or a compiler error. It works fine in normal scenarios, but dividing by zero can't be caught at compile time, and operators can only return a single value, so I had to return something.

It is the average of 1/0+ and 1/0-

So at least that's something

> So at least that's something

It's also nothing. :-)

Sometimes I have a feeling that I should be avoiding division in all cases to begin with, but then, there are cases where it seems all too indispensable. Especially when a value is a measure with an ignored error, division close to zero is almost meaningless. Is it a realistic goal to try and avoid division in the first place? I don't remember my numerical computing course well enough

I have lower level question about how Pony implements this behavior:

When a CPU is asked to divide by zero it generates an exception. This exception would cause the OS to jump to the interrupt handler in the IDT for divide by zero exceptions. This handler generally results in the OS terminating the process. Does the Pony runtime register its own signal handler with the OS for a divide by zero exception?

An alternative to multiplicative inverse is to think of division x/y as allocating an amount x to y recipients; this is a very common operation in finance, eg allocating x shares to y accounts, or if you prefer, splitting a bill x among y diners. In this interpretation, you can't allocate anything to 0 recipients, so its reasonable and convenient to set 1/0 = 0

Ruby defines division by zero for Floats

  1.0 / 0
  => Float::INFINITY

and

  0 * Float::INFINITY
  => Float::NAN

I think infinity is a more intuitive result, but most of the time i get this as a user i would rather see 0 (bought books per month: Infinity). As a programmer i like to get an error, because i forgot to handle an edge case...

That's IEEE 754 https://en.wikipedia.org/wiki/IEEE_754#Exception_handling

AFAIK Javascript does this as well.

1/0=0 is basically crack for the HN crowed, I knew it as soon as I saw it, just 5 little characters would drive people into the mouth of madness.

It's like WWE Raw Smackdown, Hulk Hogan vs. The Rock and everyone has to take a side.

And it's literally Friday night.

Sorry we're not supposed to comment like this buy y'all (I suppose 'we') are a really funny bunch sometimes.

The article uses two example theorems to justify this: a * (b/c) = b * (a/c), which can be extended to cover the c=0 case, and a/a = 1, which can be extended to cover the a=0 case. I can see how this can be useful in some situations, but it's not natural in the same way as e.g. analytical continuations of complex functions are.

In case you're wondering, Elm has a strict "no runtime errors" rule, but avoids this by not having integers.

Another interesting example is array access. What should a[len(a)+1] be if your language doesn't have runtime errors?

Elm returns a Maybe type. However, this would be very awkward if you're actually doing a lot of calculations using arrays.

[Edit: Pony is different.]

Pony does have exceptions, and indexing an array does raise if the index is out of bound. It doen't have runtime errors because all exception must be handled somewhere in the call stack, the sooner, the better.

Because of this rule, defining / as a partial function forces the user to fence every single division in a try clause.

Using boxed integer as Elm does is not an option as Pony targets high-speed computing, not browser rendering. Different fields, different trade-offs.

Defensive users can well define `div(I32, I32): I32?` that throws an error and use it instead of `/`.

As repeated in this thread, 1/0 is undefined because nonsensical. So, it's OK to have any sane, consistent and well documented behaviour. At least with Pony, the user can choose speed and convenience when they're sure there is no possible 0 at this place. Well, TBH, I think it's always the case. Because there is no such thing as a division by zero, you're algorithm is simply wrong and unsound if it ends up dividing by 0, and that's where this case differs from integer overflow

Note: in Pony literature, "partial" means "can throw an error". "partial" as in "doesn't apply to the whole domain of the arguments types"

Julia gives "Inf" and Inf+Inf =Inf and 1/Inf = 0.0

I prefer this because if you have a function converging on 0 then you will see growth towards Inf - then Inf - rather than growth followed by a cliff; which could then propagate into all your other calculations and move you from the very small to the very large in an instant.

Sometimes I wonder how much actual energy is expanded by humanity in such 'debates' (electricity, coal, nuclear..). I'm just that kind of person that likes to put thing into perspective. I'm certainly as 'guilty' as the next person in engaging in such trifle matters :-)

This triggered an immediate "that is wrong!" response from me, which I had to suppress to actually read the argument.

From this definition, I'd guess that pony isn't optimized for numerical code and floating point operations, because there it tends to make less sense.

Please note 1/0 = 0 in pony is only on integer math.

1.0 / 0.0 = infinity per the standard.

1/0 = undefined behavior and is left to language implementers to decide how to handle.

Meanwhile, in Python v3.7.0...

      >>> 1 / 0
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      ZeroDivisionError: division by zero
      >>> 0 / 0
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      ZeroDivisionError: division by zero
      >>> 1 / 0.0
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      ZeroDivisionError: float division by zero
      >>> 0.0 / 0.0
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      ZeroDivisionError: float division by zero

Meanwhile, in Elixir v1.7.1...

      iex(1)> 1 / 0
      ** (ArithmeticError) bad argument in arithmetic expression: 1 / 0
          :erlang./(1, 0)
      iex(1)> 0 / 0
      ** (ArithmeticError) bad argument in arithmetic expression: 0 / 0
          :erlang./(0, 0)
      iex(1)> 1.0 / 0.0
      ** (ArithmeticError) bad argument in arithmetic expression: 1.0 / 0.0
          :erlang./(1.0, 0.0)
      iex(1)> 0.0 / 0.0
      ** (ArithmeticError) bad argument in arithmetic expression: 0.0 / 0.0
          :erlang./(0.0, 0.0)

Meanwhile, in Ruby v2.5.1...

      irb(main):001:0> 1 / 0
      Traceback (most recent call last):
              3: from /Users/mpope/.rbenv/versions/2.5.1/bin/irb:11:in `<main>'
              2: from (irb):1
              1: from (irb):1:in `/'
      ZeroDivisionError (divided by 0)
      irb(main):002:0> 0 / 0
      Traceback (most recent call last):
              3: from /Users/mpope/.rbenv/versions/2.5.1/bin/irb:11:in `<main>'
              2: from (irb):2
              1: from (irb):2:in `/'
      ZeroDivisionError (divided by 0)
      irb(main):003:0> 1 / 0.0
      => Infinity
      irb(main):004:0> 0.0 / 0.0
      => NaN

Meanwhile, in PHP v7.0.8...

      > echo 1 / 0;
      >
      INF
      Division by zero :1
      > echo 0 / 0;
      >
      NAN
      Division by zero :1
      > echo 1 / 0.0;
      >
      INF
      Division by zero :1
      > echo 0.0 / 0.0;
      >
      NAN
      Division by zero :1

Meanwhile, in Node v10.7.0...

      Infinity
      > 1 / 0
      Infinity
      > 0 / 0
      NaN
      > 1 / 0.0
      Infinity
      > 0 / 0.0
      NaN

Meanwhile, in Python...

  In [1]: 255 + 1 is 256
  Out[1]: True
  In [2]: 256 + 1 is 257
  Out[2]: False

Every language has its inconsistencies, when it comes to math, because they run on real-world computers. All these are "slow" interpreted languages that allow runtime failures and don't use plain machine integers. Just a different trade-off.

Anyway, the Inf/NaN trick is not better than the 0 trick in my opinion, because all subsequent operations result happily in NaN. I've never seen in any NaN language a program that checks for NaN the result of each and every division.

with a NaN-kind of language, it would be:

  a = b/c
  if a == NaN:
    print "oops"

with a 0-trick language:

  a = b/c
  if a == 0 and c == 0:
    print "oops"

not THAT different, IMO :)

Just yesterday I had a 1/0 bug (code iterating along some line segments that forgot to account for the possibility of a zero-length segment). If 1/0 was 0, the code would have worked correctly instead of crashing.

So, there's one data point in favor. :-)

code iterating along some line segments that forgot to account for the possibility of a zero-length segment

Out of curiosity, could you describe what you were doing and why 1/0 = 0 would have returned the correct result?

I think a principled mathematical way to say it is that the multiplicative structure of a field is a group object in the monoidal category of pointed sets and the smash product (with 0 as the point). So the multiplicative inverse of 0 really is 0.

So I believe in this article the equation:

y = 1/x

will result in 2 nice asymptotes with a dot in the middle (0,0)

1/0 = 0 doesn't make sense to me, even because lim x->0+ 1/x is infinite and lim x->0- 1/x is -infinite

so the value that makes more sense for 1/0 is infinite

Why infinity rather than negative infinity? Is 1/0 = 1/(-0)?

Doug Crockford argues the same thing in his talk about the future of programming languages:

The Post JavaScript Apocalypse https://youtu.be/99Zacm7SsWQ?t=2434

Please forgive my tone, it's not keeping in the noble spirit of Hacker News. But here goes:

So that's it. I read your proof. You try cloaking it in pseudo-mathematical formulation, but what you are really doing is defining division as a derived operator, rather than the axiomatic operator it is in mathematics. I can say 1= infinity in my universe and as long as I am consistent, it is sound.

You're saying this is a useful property to have, and certainly that holds merit in certain conditions, but it is not a correct property.

Your article title should be clarified to state "1/0=0 (in my universe)." But then it wouldn't be controversial would it? After all, this is just an experiment to gain some visibility for Pony, isn't it?

The OP didn't invent the definition of fields as defined by additional and multiplication, with division defined as the Inverse of multiplication. Even the Wikipedia article on fields (https://en.wikipedia.org/wiki/Field_%28mathematics%29#Defini...) defines them this way. (Not that Wikipedia is an authority on truth, but I find that it's a pretty good indicator of what positions are common/widespread regarding a subject.) It's a bit silly to claim that division is defined as axiomatic "in mathematics" given how fundamental fields, defined as the OP defined them, are to modern number theory and mathematics in general.

My math is rusty but 1 / 0 := 0 implies that 0 * 0 := 1. This contradicts the definition of a binary field [1], let alone a field of real numbers.

[1] https://en.wikipedia.org/wiki/GF(2)

> "It is totally fine to define 1/0 = 0."

No, it's not, at least not useful. If you define it that way, you will not have a field. Then you don't have +, -, *, and / operations with the commonly assumed behavior. However, it is definitely possible to define some operation such that 1 `op` 0 := 0, just not the inverse operation of multiplication.

> However, it is definitely possible to define some operation such that 1 `op` 0 := 0, just not the inverse operation of multiplication.

If you read the post this is actually exactly what the OP is saying.

Pony lang says 1/0=0

I say neigh (sorry if you didn't catch that joke, I'm a little horse).

If x/0 =0 then, since division is inverse of multiplication x= 0*0 this fails to hold for any x not 0

But the story says there is no defined multiplicative inverse of zero (undefined) so that they are free to choose any value they want. And they choose 0.

This is unsatisfactory to me because it seems to break the intuitive pattern of x/n getting larger as n approaches zero from the positives. 1/4 .25< 1/3 .33 < 1/2 .5 < 1/1 1 >1/0 0 >1/-1 -1 < 1/-2 -.5 < 1/-3 -.333

You see that sign flip thingy happening around 1/0?

Maybe I am misunderstanding.

> But is Pony doing something unsound? Absolutely not. It is totally fine to define 1/0 = 0. Nothing breaks and you can’t prove something false. Everybody who was making fun of Pony programmers for being ‘bad at math’ doesn’t actually understand the math behind it.

This is playing semantic games. A whole lot does break: / no longer has its usual properties, and if you use those usual properties you can certainly prove false things. It's no different from saying that it's totally fine to define 2 + 2 = 5 and nothing breaks, you then just have to say that 5 isn't the arithmetic successor of 4 any more.

What usual properties does 1 / 0 = 0 break?

It is pretty annoying when you see NaN on a web page. I personally have fallen into the division by zero trap on numerous occasions.

If thing is zero don't divide, like the base case in a recursive function. This is the maths version of null pointer exception

1/0 is Infinity, to keep consistency with beautiness of Geometry. Consider for example the stereographic projection.

A trick to ensure you don't divide by zero in C with minimal overhead(that converts zeros to 1) x/(y+(y==0))

One thing this all seems to miss that this is about INTEGER division. So any field argument does not apply?!?

Thought of another reason besides below comment why I was wrong, but thanks goes to below comment too!

Because it has the unfortunate consequence of eliminating the uniqueness property of fields.

If you allow 0 to have a multiplicative inverse 1/0, then the product of 0 and 1/0 must be equal to the multiplicative identity, which is 1. Then it follows that 0 = 0 * 0 = 1. From here it's straightforward to prove that x = y for all x, y in the field F.

A multiplicative inverse is a division. You cannot define division by x in fields without defining multiplication by 1/x and vice versa. The article is plainly incorrect in its attempt to refute this point (and in any case, shouldn't be using field theory to justify its purpose in the first place).

1 / 1 = 1 1 / 0.1 = 10 1 / 0.01 = 100 1 / 0.001 = 1000 ....

The convention is consistent. I don't find it useful, but it is consistent.

If you have a cake and divided it in zero parts, where did the cake go ?

I.e. a short-circuit means current = 0 because it trips a fuse?

You know.. dividing is like breaking something up.. If you divide by 2, you break it up into 2 pieces.. if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0.

> You know.. dividing is like breaking something up.. If you divide by 2, you break it up into 2 pieces.. if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0.

And dividing by 0.5 is breaking into how many pieces exactly?

> if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0.

This explains exactly why we shouldn't divide by 0. The pieces after breakage should, if one is so inclined, be able to be re-assembled into the whole; but, once you break something into 0 pieces, it is gone. Thus at best `0/0` could be defined … but the problem there is not that there's no answer but that every answer is equally good.

  You know.. dividing is like breaking something up [..]

No. What it is 'like' is totally irrelevant and actively harmful to consider if you want to be able to get anything serious done with your programming language. This is not a place to start philosophizing. For consistent arithmetic it is important to know which axioms are fulfilled. Division needs to be a mathematically clearly defined operation.

I mean, you’re not wrong. Not right either (for technical reasons), but that kind of argument leads you to mathematical objects like the Cantor set: a set of line segments with zero total length. Mathematically, you have a bunch of objects; practically, you have nothing.

1/0 = 0 is just plain lazy. So is 0^0 = 1. Now some might argue it is a matter of how you define the operators. What I say is that then separate them cleanly. e.g. pow(0,0) = 1 powr(0,0) = NaN

Some symbol is failing to render on my android phone.

1/0 = #DIV/0! (Sorry couldn't resist)

1/0 = +infinity; 1/+infinity = 0; simple.

Except machine integer types do not have infinities in them. So not so simple in the real world.

It's like in Ruby, when you divide 3/2 you get 1 (integer division) which is almost never the behavior you want (unless you cast all you numbers to float which is a pain to do).

> It's like in Ruby, when you divide 3/2 you get 1 (integer division) which is almost never the behavior you want

I dunno, if I'm dividing a quantized space, which is a fairly common thing to do, its exactly what I want.

> (unless you cast all you numbers to float which is a pain to do).

Using floats just gets you different wrong answers than using integers, unless you happened to somehow have ints to start and want a floating point approximation, which I find is less likely than wanting integer division.

What you really want for exact division where there are integers involved is to have at least one operand specified as a rational; this also takes less keystrokes, if its a literal, than changing it to a float to get an inexact answer.

Related to this, prior to Ruby 2.5, the standard library include "mathn", a library which monkey-patched all the numeric types so that operations on them acted pretty much like Ruby had a Scheme-style numeric tower, but since that has process-wide effects not restricted to where the library is required, that was deprecated in 2.2 and removed in 2.5.

When dealing with integer quantities and together with modulo, it's pretty natural. n/d gives the integer result, n%d gives the rest. n/2 for example always gives you the "middle" element. And in e.g. a loop where you e.g. transmit elements in blocks, you handle full blocks n/blocksize times, followed by a partial block with n%blocksize elements.

It's not always what you want, but it's pretty reasonable. The alternative would be if it always rounds up, which seems weirder to me. I don't think rounding to the nearest integer makes sense with integer quantities at all, that's strictly a real number operation.

In Ruby there is % which gives you remainders.

When we first teach children about division we teach them that, "17/5 = 3 with a remainder of 2". It is only later that they learn about decimal points and learn to say that 3.4 is the answer.

> do not mock other programmers

Who is mocking anyone though?

What about for really large values of zero?

Screams into the calculus void!

What an absurdly dumb article.

So x%0 = x for all x?

The set of integers do not form a field so the argument is nonsense.

> The set of integers do not form a field

The set of integers represented by the integer types of pony can be treated as a field, since they have discrete ranges.

Oh, so 0*0=1 ?

> So it is _not_ a theorem that a * (b / 0) = b * (a / 0)

As the article explains, the whole issue about dividing by 0 is the lack of multiplicative inverse. If you define division for 0 as something other than multiplication by the multiplicative inverse, there is no longer an issue doing the division. Hope that helps.

If a hn title said 1*0=0 could you reply "Oh, so 1=0/0?"

The entire point of the article was suggesting you can define a consistent system without multiplication and division being entirely symmetrical (as they already are not)

isn't a pony an animal you ride? where's the math?

Hey look, /r/badmathematics is leaking

When setting out to add a new axiom to a heavily studied area of mathematics, perhaps one should at least formulate an argument that isn't shown to be incomplete with the most basic wikipedia search.

https://en.wikipedia.org/wiki/Division_by_zero

Reply on news.ycombinator.com