Live data from Hacker News

1/0 = 0 (2018)

hillelwayne.com

211–220 of 245 posts

Re: 1/0 = 0 (2018)

#211

Earlier quoted context omitted.

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.

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?

Re: 1/0 = 0 (2018)

#212

Earlier quoted context omitted.

People are too scared of crashes. Sure, crashing is not ideal. Best is to do what the program is supposed to do, and if you can’t, then it’s better to produce a friendly error message than to crash. But there are far worse outcomes than crashing. Avoiding a crash by assigning some arbitrary behavior to an edge case is not the right approach.

Strongly agree here. IMO libraries should try hard to return sensible error codes (within reason, eg null pointer access is unrecoverable imo) but application code should just crash. And when a library returns an error code, default to just crashing if it fails until you have a compelling reason to do something more complicated.

Yes but here's the conflict. You design a typed language, you want the primary operators to be type stable so you can compose them. Then there's no room to return an error from a basic operation. So if your language also makes it a priority to NEVER CRASH, you are stuck.

Re: 1/0 = 0 (2018)

#213
post #111

Yes, it's all good and nice that your types are sound and you don't have panics, but I feel like this could get you in trouble in the real world (gleam also uses this division convention, and people very much use gleam for "real world" things). Suppose you took an average over an unintentionally empty list (maybe your streaming data source just didn't send anything over the last minute due to a backhoe hitting a fibe…

I use Gleam in production[0][1], and that is not really an issue. Gleam offers division functions that return an error type, and you can use those if you need that check. They fit a list-length use case well as they work better with a piping syntax which is popular in Gleam. [0] https://nestful.app [1] https://blog.nestful.app/p/why-i-rewrote-nestful-in-gleam

> Gleam offers division functions that return an error type, and you can use those if you need that check.

Yes, but is that what any given developer will reach for first? Especially considering that an error-returning division is not composable?

The language puts people into a place where the instinctive design can cause very dangerous outcome, hard to see in a code review, unless someone on the team is a language lawyer. You probably don't want one of those on your team.

I think there's a reasonable argument for gleam to have an operator that does division resulting in zero but at the very least that should NOT be "/"

Re: 1/0 = 0 (2018)

#214
Math major here: this is wrong. The expression 1/0 is NOT A NUMBER, even if you allow positive infinity or negative infinity. In particular, it is most certainly not 0.

Note that infinity would be a fine answer IF MATHEMATICS COULD BE CONSISTENTLY EXTENDED to define it to be so, but this cannot be done (see below). Note that using infinity does not "break" mathematics (as some have suggested below) otherwise mathematicians would not use infinity at all.

If we have an expression that is not a number, such as 1/0, you can sometimes consistently define it to be something, such as a number or positive infinity or negative infinity, IF THAT WOULD BE CONSISTENT with the rest of mathematics. Let's see an example of the standard means of getting a consistent definition of exponentiation starting with its definition on positive integers and extending eventually to a definition for on a much bigger set, the rationals (ratios of signed integers).

We define 2 ^ N (exponentiation, "two raised to the power of N") for N a positive integer to be 2 multiplied by itself N times. For example: 2 ^ 1 = 2; 2 ^ 2 = 4; 2 ^ 3 = 8.

Ok, what is 2 ^ N where N is a negative integer? Well we did not define it, so it is nothing. However there is a way to CONSISTENTLY EXTEND the definition to include negative exponents: just define it to preserve the algebraic properties of exponentiation.

For exponents we have: (2 ^ A) * (2 ^ B) ("two raised to the power of A times two raised to the power of B") = 2 ^ (A+B) ("two raised to the power of A plus B"). That is, when you multiply, the exponents add. You can spot check it: (2 ^ 2) * (2 ^ 3) = 4 * 8 = 32 = 2 ^ 5 = 2 ^ (2 + 3).

So we can EXTEND THE DEFINITION of exponentiation to define 2 ^ -N for positive integer N (so a negative integer exponent) to be something that would BE CONSISTENT WITH the algebraic property above as follows. Define 2 ^ -N ("two raised to the power of negative N") to be (1/2) ^ N ("one half raised to the power N"). Check: (2 ^ -1) * (2 ^ 2) = ((1/2) ^ 1) * (2 ^ 2) = 1/2 * 4 = 2 = 2 ^ 1 = 2 ^ (-1 + 2).

Ok, what is 2 ^ 0 ("two raised to the power of zero")? Again, we have not defined it, so it is nothing. However, again, we can CONSISTENTLY EXTEND the definition of exponentiation to give it a value. 2 ^ 0 = (2 ^ -1) * (2 ^ 1) = 1/2 * 2 = 1. This always works out no matter how you look at it. So we say 2 ^ 0 = 1.

I struggled with this for days when I was a kid, literally yelling in disbelief at my parents until the would run away from me. I mean 2 ^ 0 means multiplying 2 times itself 0 times, which means doing nothing, so I thought it should be 0. After 3 days I finally realized that doing nothing IN THE CONTEXT OF MULTIPLICATION is multiplying by ONE, not multiplying by zero, so 2 ^ 0 should be 1.

Ok, is there a way to CONSISTENTLY EXTEND the definition of exponentiation to include non-integer exponents? Yes, we can define 2 ^ X for X = P / Q, where P and Q are integers (a "rational number"), to be 2 ^ (P/Q) = (2 ^ P) * (2 ^ -Q). All the properties of exponentials work out.

Notice how we can keep EXTENDING the definition of exponentiation starting from positive integers, to integers, to rationals, as long as we do so CONSISTENT with the properties of the previous definition of exponentials. I will not do go into the details, but we can CONSISTENTLY EXTEND the definition of exponentiation to real numbers by taking limits. For example, we can have a consistent definition of 2 ^ pi ("two raised to the power of pi") by taking the limit of 2 ^ (P/Q) as P/Q approaches pi.

HOWEVER, IN CONTRAST to the above extension of the definition of exponentiation, there is NO SUCH SIMILAR CONSISTENT EXTENSION to division that allows us to define 1/0 as ANY NUMBER AT ALL, even if we allow extending to include positive infinity and negative infinity.

The limit of 1/x as x goes to zero FROM THE POSITIVE DIRECTION = positive infinity. Some example points of this sequence: 1/1 = 1; 1/0.5 = 2; 1/0.1 = 10; 1/0.01 = 100, etc. As you can see the limit is going to positive infinity.

However, the limit of 1/x as x goes to zero FROM THE NEGATIVE DIRECTION = NEGATIVE infinity. Some example points from this sequence: 1/-1 = -1; 1/-0.5 = -2; 1/-0.1 = -10; 1/-0.01 = -100, etc. As you can see the limit is going to NEGATIVE infinity.

Therefore, since positive infinity does not equal negative infinity, there is NO DEFINITION of 1/0 that is consistent with BOTH of these limits at the same time. The expression 1/0 is NOT A NUMBER, even if you include positive and negative infinity, and mathematics cannot be consistently extended to make it into a number. Q.E.D.

Re: 1/0 = 0 (2018)

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

Re: 1/0 = 0 (2018)

#216
post #165

Earlier quoted context omitted.

You'll find that keeping my client information's integrity is as important to me as keeping the financials. That, however, is still not enough to alleviate OP's concerns, which is why I've explained how the `1/0=0` problem can be entirely avoided. I expect entirely avoiding the problem OP mentioned is enough to alleviate the concerns it raises.

> keeping my client information's integrity is as important to me as keeping the financials Nobody is questioning your intentions. People writing apps in memory-unsafe languages don’t give fewer shits. They’re just more prone to certain classes of errors. > how the `1/0=0` problem can be entirely avoided 1/0 problems are generally expected to be entirely avoided. This is about where the system behaves unexpectedly, w…

[deleted]

Re: 1/0 = 0 (2018)

#217

Earlier quoted context omitted.

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.

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

Re: 1/0 = 0 (2018)

#218

Earlier quoted context omitted.

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.

> 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.

Re: 1/0 = 0 (2018)

#219
post #141

Earlier quoted context omitted.

> I haven't yet encountered a language which solves this issue: Well, Python supports arbitrary precision integers. And some other niche languages (Sail is one I know). I don't think "running out of memory" counts as a caveat because it still won't give the wrong answer. For floats, I don't think it's actually unreasonable to use different operators there. I vaguely recall some languages use +. or .+ or something for…

> Well, Python supports arbitrary precision integers. And some other niche languages (Sail is one I know). As a Lisper, I very carefully chose an example to account for arbitrary-precision integers (so X + X where X is, say, 8^8^8^8 (remember, exponentiation is right-associative, 8^8^8^8 = 8^(8^(8^8)))). > I don't think "running out of memory" counts as a caveat because it still won't give the wrong answer. Being ped…

Right, but you can never guarantee giving the correct answer. What if someone unplugs the power mid-computation? That's basically where running out of memory is (for a modern desktop system anyway).

The best you do is "not the wrong answer".

Re: 1/0 = 0 (2018)

#220
post #167

Earlier quoted context omitted.

> keeping my client information's integrity is as important to me as keeping the financials Nobody is questioning your intentions. People writing apps in memory-unsafe languages don’t give fewer shits. They’re just more prone to certain classes of errors. > how the `1/0=0` problem can be entirely avoided 1/0 problems are generally expected to be entirely avoided. This is about where the system behaves unexpectedly, w…

Correct, these are all trade-offs we make when building a product. Choosing between the "1/0 crashes your program" problem and the "1/0 returns 0" problem is one such tradeoff. All I was doing was clarifying the impression OP gave. Now that we all know the details we can make whatever tradeoff we prefer.

Let's be clear. Gleam is still a bit of an esolang. If you had a company and onboarded a junior onto it would you expect them to know that 1/0 == 0? As a senior doing code review for said junior, would you be confident that you would correctly think through every corner case when you encounter the / operator?

Its the year of the Lord 2024, why is a new language putting in such a huge footgun out of the box in its stdlib.

Post reply on HN