Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1/0 = 0

hillelwayne.com

Post reply on HN
Print view View original

541–550 of 593 posts

Re: 1/0 = 0

#541

Post by seandougall »

Giroflex wrote: post #502
jeremyjh wrote: post #500

Earlier quoted context omitted.

You can check for 0 and throw in those cases, and then propagate the error path appropriately. And as they've already said in this thread, they will be providing a checked arithmetic in the standard library to do that for you.

Well, sometimes the average is 0, e.g. (-2 + 2)/2. And the whole point is that this is meant to catch unforeseen interactions as soon as possible. If you add a check it's no longer unforeseen, and it may easily slip the programmer's mind.

If I'm not mistaken, jeremyjh was referring to checking for 0 in the denominator, not the numerator.

Re: 1/0 = 0

#543

Post by pps43 »

seandougall wrote: post #540
pps43 wrote: post #505

Earlier quoted context omitted.

> I don't see the issue with those examples Let me elaborate then. Average credit card balance predicts probability of default. Joe who maxed out his credit card is higher risk than Jane who pays back her entire credit card balance every month. Now we have Jack with no credit card. We predict that Jack is low risk because his average credit card balance is zero. Second example, defibrillator that monitors blood press…

It seems to me taking averages would be inappropriate in all three of those scenarios. Credit risk is based on total debt, and since credit cards are a revolving line of credit, the entire credit limit is considered debt, even if the balance is zero. That's why you can improve your credit score by closing out a credit card that you never use and that carries a zero balance (which we did in order to qualify for a mort…

Everything is relative. $1,000 balance is a lot of money for someone making $35,000, not so much for someone making $350,000. Many independent variables that go into risk scores tend to be ratios or averages, hence zero (or near zero) denominator is possible.

It is normally addressed with floors and ceilings or something like Laplace rule of succession, so that no data at all results in a reasonable number. Very rarely that reasonable number is zero.

I'm not saying taking the average is necessarily good in the examples given, just that if you are computing the average, then that computation should not silently return zero if there's no data to average.

That's the way AVG() in SQL or mean() in R work, they return NULL or NA rather than 0. If you know that NA should be 0 you can explicitly COALESCE, but that should be your decision rather than the default behavior.

Re: 1/0 = 0

#544

Post by boyce »

a_wild_dandan wrote: post #338
chess19 wrote: post #287

Earlier quoted context omitted.

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.

> 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. That's not implied, so far as I can tell. a / b = 1 / 0, thus a * d = b * c => 1 * d = 0 * c => d = 0 So all you can say is that d = 0, or at most that c / 0 = 0. Is there some extra step you're taking?

So if 1·d = 0·c, write 1 in terms of the other elements and then evaluate.

Re: 1/0 = 0

#545

Post by fibo »

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

Re: 1/0 = 0

#546

Post by karmakaze »

WalterBright wrote: post #375
whack wrote: post #72

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…

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…

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.

Re: 1/0 = 0

#547

Post by karmakaze »

Boulth wrote: post #527
Ace17 wrote: post #458

Earlier quoted context omitted.

> 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 wi…

> (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)). Actually if you check out the interviews with Java designers the checked exceptions mechani…

The mis-categorization of some exceptions[0] as checked or not is part of why checked exceptions seem like a mistake. The other is when exceptions cross boundaries of human organizations like nested libraries.

[0] NumberFormatException is a RuntimeError as are all IllegalArgumentException, WTF?

Re: 1/0 = 0

#548

Post by Dylan16807 »

throwawaymath wrote: post #504
Dylan16807 wrote: post #484

Earlier quoted context omitted.

> Onlookers reading these comments probably think those of us harping on this point are anal pedants with a mathematical stick up our ass. But this thread is increasingly illustrating my central point, which is that the author shouldn't have tried to justify numerical operation definitions in a programming language using field axioms of all things. You can't use your own stubbornness to justify itself. I'm waiting fo…

Because a divisor cannot exist unless it is a multiplicative inverse. Therefore 0 is not a divisor. This is getting to be Kafkaesque...it breaks the field axioms themselves. How many different explanations and external resources do I need to provide in this thread for you to be convinced that this is not a controversial point in modern mathematics? I just explained it in the comment you responded to. You have exactly…

> Because a divisor cannot exist unless it is a multiplicative inverse. Therefore 0 is not a divisor.

So there are two separate issues here. One is whether we can extend the definition of the "/" operator, and the other is whether we call it "division".

I'm not interested in what we call it. I'm interested in the claim that extending "/" will break the field.

The dichotomy you're talking about is wrong. The two options are not "multiplicative inverse" and "does not interact with anything". "1/0 = 0" interacts with plenty! If I make a system where it's an axiom, I can calculate things like "1/0 + 5" or "sqrt(1/0)" or "7/0 + x = 7". I can't use it to cancel out a 0, but I can do a lot with it.

> It boggles my mind that there are people in this thread still fighting an idea in earnest which has been settled for over a century.

Remember, the question is not "should this be an axiom in 'normal' math?", the question is "does this actually conflict with the axioms of a field?"

> You can't just add another axiom to a field and call it a field.

Yes you can. There is an entire hierarchy of algebraic structures. Adding non-conflicting axioms to an X does not make it stop being an X.

Re: 1/0 = 0

#549

Post by ian1321 »

bunderbunder wrote: post #94
whack wrote: post #72

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…

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

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.

Re: 1/0 = 0

#550

Post by JadeNB »

esrauch wrote: post #99
JadeNB wrote: post #43

Earlier quoted context omitted.

> without multiplication and division being entirely symmetrical (as they already are not) What do you mean?

Multiplication by x and division by x are inverses, except there is already the sole special case of x=0 where that isn't true. The common way to resolve that is and be consistent is to axiomatically decide: 1) there is no inverse of * 0 2) 0 is not part of the range permitted for 1/x The point of the article is that another way to resolve it and be consistent is to axiomatically decide: 1) there is no inverse of * 0…

> As in, (x/y) * y=x is true either way only if y!=0. The only difference is whether when y=0 if it is not true because it is just illegal or if it is not true because (x/0) * 0 = 0 for all x.

Sure, I understand this claim. What I don't understand is the precise meaning of the claim "multiplication and division already are not entirely symmetrical." I don't know any existing technical meaning of "entirely symmetrical" for a pair of operations, but let's suppose that I switch the operations in your statement:

> (x/y) * y = x is true [for all x] only if y != 0.

Then I get:

> (x * y)/y = x is true [for all x] only if y != 0.

That's also true. What's the asymmetry?

Post reply on HN