Hacker News Reader

Comment by sethev | Hacker News Reader

I debated this with my boss at my first programming job (this was 20+ years ago). He thought 1/0 should be 0 rather than an error because "that's what people expect". My argument was from mathematical definitions (the argument which this blog post picks apart).

In retrospect, I see his point better - practical use trumps theory in most language design decisions.

I haven't changed my mind but the reason has shifted more toward because "it's what a larger set of people expect in more situations" rather than mathematical purity.

View on HN

1/0 = 0 is usually not a practical thing, it's to satisfy that the output of the division operator stays in the type and you don't want crashes (a "feature" of ponylang and gleam, e.g.). Its kind of a PL wonk thing.

It's not at all a good idea for very important practical reasons as I outline in a reply to parent.

I don't want to handle errors after every division and division doesn't crash, both sound rather practical, though.

The original purpose of defining it to be Nan/INF in floating point was exactly that. You'd do all the work and then check if it was Nan/INF at the end without having to check every intermediate result.

If you want to do all the work at the end, 'exceptions' do exactly that, too.

Throwing an exception in a function normally stops the rest of the work that function would do. That is not the case when using Inf and similar

    > const f = (x) => [x/2, x/0]
    undefined
    > f(10)
    [ 5, Infinity ]

I assert stopping immediately is much more practical. In many cases, you waste considerable amounts of processing power to reach a conclusion you often won't be able to use.

It depends on your use case.

Sure but what should be the default?

Rust and Haskell can solve this fairly well: both styles of dealing with errors are easily accessible.

Go solves this really badly.

As for specifically what to do about division: the right default depends on your application. Either way is defensible, and I would rather work on making it easy to pick either style in the language of your choice, than to worry too much about what the default should be.

That's a good point, sometimes this is what you want.

The problem is that if you forget to check you find out a month later or ten functions over.

> I don't want to handle errors after every division and division doesn't crash.

You can have one or the other.

You can't have both without the risk of nasal demons. Unless the result of the operation is business-safe to throw away.

That's why having the default / have both is an poor design choice by gleam and pony. Someone will reach for / and encounter demons. Afaict the other langs that do this are not intended for real world prod use. By default / should force the developer into either crashable or unwrap error return. If you want some sort of opt-in "logic-unsafe /", fine but call it something else like </> e.g.

Funny you should mention gleam since it's a BEAM host language... surely they shouldn't fear crash management, right ?

You would think.

Some people get scarred working in other langs and can't let go, I guess?

Well, if the requirement is to stay in the type, you could extend the type to include the point at infinity. That satisfies both programmer and the mathematician.

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

Never have I ever met anybody who would think dividing by zero yields zero O_o

If anything it feels natural to yield +/-infinity

It's not about what I think zero division yields I've taken a math class before. It's just about representation within the type system. If division can return infinities we can't safely combine division with other functions that are expecting ints and floats.

Most languages throw an error instead, but there are tradeoffs there too. If you've decided not to throw an error you should at least return a usable number and zero makes more sense than -1 or 7 or a billion or whatever.

You could also build the number stack from the ground up to accommodate this edge case, and make it so all arithmetic functions can handle infinities, infinitesimals and limits. I've come across a racket sublang like that but it's nearly unusable for the normal common things you want to do with numbers in code.

NaN is a valid float, so are infinities

They're valid according to a spec that doesn't mean I want one showing up when I'm trying to calculate the area of a semicircle or whatever. In the context of getting one by surprise in simple arithmetic they are approximately as bad as zero. Either way you have to decide how to handle it and there are tradeoffs of different approaches, as the article discusses. It's not about someone just being ignorant of basic math like the comment I was replying to implied.

>In the context of getting one by surprise in simple arithmetic they are approximately as bad as zero.

I don't think so, because getting 0 in a larger expression might yield a result that looks plausible, leading to hidden bugs. Inf and NaN both are good because they necessarily propagate all the way up to the end result, making it obvious that something went wrong.

Technically, it is possible for floating-point Inf to stop propagating prior to the final result, depending on the operation. For example, 1/Inf produces zero, as does exp(-Inf).

But those are cases where the larger a value is, the less is contributes to the final value.

You have never met Steve Chow, the BlackPenRedPen bloke on YouTube, then. (-:

https://youtube.com/watch?v=n1ZLag56sAo

i would not expect 1/0 to be zero. as you divide by smaller numbers, the quotient gets bigger, so i can't understand why someone would expect /0 to be zero.

If I have five apples and were to divide them among 0 people then nobody gets anything and I can eat them all, so the proper solution would be 5.

you can't divide the apples among 0 people and then claim to still have them, because in that case you would have divided them among 1 people

Like everything in life, it depends... For example: Storage has 5 items that need to be processed. 5 items need to be split equaly between available processes. There are currently 0 available processes so 5 / 0 = 0 items to be processed is more correct than either 5 or Nan or infinity.

Your example is quite vague (e.g. are we dealing with an integer number of items and processes?) and in general if something looks kinda like a division it doesn't mean it is exactly division. Just like in math, we have the power to simply say: if COND -> divide normally, else -> do something else.

And that's why the answer is 0.

Paraphrasing you: "If I have five apples and were to divide them among 0 people, how many does each person get?" This sums up one approach to this problem, and can be thought of in a more intuitive manner than the limit approach. The answer could be zero. Or 1. Or 37. In fact, any number makes as much sense as the question. Which is why either an exception is raised, (or +- Inf is returned for floats, but that's just the limit approach). But perhaps it would be more fun just to return a random number on divide by zero :)

It's more like you had five apples and divided them among zero people, which means not even you get to keep them. They were thrown in the trash instead. The answer is zero.

A stateful expectation of existence is what the denominator describes, but if you forced it to describe people, then you'd phrase it as "how many (ghosts) could possess (any number of apples)?"

Which would be infinite, since ghosts occupy no space and can't interact with physical reality.

As a proportion, compared to nonexistence, any quantity of something is infinitely greater than nothing, so if not n/0, how would you express you expect not the absence of a thing, but its nonexistence?

In other words, the quotient is 0, the reminder is 5?

That's an interesting solution...

I agree wholeheartedly. I think the issue stems from 0 meaning both 0 of "something"/"a concept" and "nil."

If I have 5 apples and divide them in to 0 buckets of apples, that makes sense. If I have 5 apples and divide them into 0 buckets of tractor; that doesn't make sense.

One intuition could be: As you divide 1 by negative numbers of smaller and smaller magnitude, you get negative numbers of increasing magnitude. At 0, the positive infinity of 1/0 is met by the negative infinity of 1/-0 and their average is 0.

why take averages?

Well, it would be simultaneously at both extremes.

The OP uses finite fields and fields are basically harmonic structures (think modular math). Assume the field is the numbers 0..n-1 MOD n. At (n-1) + 1 you will get n MOD n which is equivalent to 0 MOD n which is 0. Now assume n-1 approaches infinity; is 0 not ∞ ?

I remember my junior high maths well enough, allowing division by zero is an essential step in proving that 1 == 2, which we _definitely_ don't want.

> He thought 1/0 should be 0 rather than an error because "that's what people expect"

So I saw this in action once, and it created a mess. Private company had a stupid stock dividend mechanism: every shareholder received some fraction, dependent on fundraising, of a recurring floating pool of shares, quantity dependent on operating performance. (TL; DR Capital was supposed to fundraise, management was supposed to operate. It was stupid.)

One quarter, the divisor was zero for reasons I can't remember. This should have resulted in no stock dividend. Instead, the cap-table manager issued zero-share certificates to everyone. By Murphy's Law, this occured on the last quarter of the company's fiscal year.

Zero-share certificates are used for one purpose: to help a shareholder prove to an authority that they no longer own any shares. Unlike normal share certificates, which are additive, a zero-share certificate doesn't add zero shares to your existing shares; it ambiguously negates them. In essence, on that day, the cap-table manager sent every shareholder a notice that looked like their shares had been cancelled. Because their system thought 1 / 0 = 0.

If you're dividing by zero in a low-impact system, it really doesn't matter what you output. Zero. Infinity. Bagel. If you're doing so in a physical or financial or other high-impact system, the appropriate output is confused puppy.

Huh? The article shows why 1/0=0 is mathematically sound, and then considers an error preferable in a programming context anyway, because practicality. It’s the opposite of the reasoning you’re describing.

> The article shows why 1/0=0 is mathematically sound

It does not, because it is not. And the “real mathematicians” that he quotes aren’t supporting his case either, they’re just saying that there are cases where it’s convenient to pretend. If you look at the Wikipedia page for division by zero you may find “it is possible to define the result of division by zero in other ways, resulting in different number systems”: in short, if it’s convenient, you can make up your own rules.

> in short, if it’s convenient, you can make up your own rules.

Yes.

People find it confusing that there is no simple model that encapsulates arithmetic. Fields do not capture it in its entirety. The models of arithmetic that describe it end up being extremely complex.

Arithmetic is ubiquitous in proofs of other things, and people like the author of this blog cannot get over it.

Reality is weird, inconsistent, and weirdly incomplete.

Get used to it!

"Making up your own rules" is literally what mathematics is, though. Using that as a counterargument to using a specific set of axioms tells me you don't understand mathematics.

But adopting a rule that says 1/0 = 0 means you may also have to accept that 1 = 0*0.

>”Making up your own rules" is literally what mathematics is, though.

We don’t make up arbitrary rules, though. Well…so-called mathematicians who study systems with completely arbitrary rules are just jerking off. The rules that most mathematicians use are based on our intuitions about what can’t be proven but “has to be” true.

Reply on news.ycombinator.com