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

581–590 of 593 posts

Re: 1/0 = 0

#581

Post by dllthomas »

karmakaze wrote: post #547
Boulth wrote: post #527

Earlier quoted context omitted.

> (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?

Another is that well-known attempts at checked exceptions in practice provide an incredibly limited vocabulary for talking about raised exceptions - usually just unconditional "might raise X" or "does not raise X". If you could say things like "raises anything raised by my argument f, except for X because I catch that" it seems like it might be a much better idea (especially if you can infer those...)

Re: 1/0 = 0

#582

Post by j2kun »

lisael wrote: post #321
j2kun wrote: post #141

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 :)

If you define a/0 to be a value, then you can ask whether (2 + 1)/0 = 2/0 + 1/0. This is not meaningless since both sides are defined. If you define a/0 = 2, then the equation is false.

Using "infinity" (which is not how it's actually done in math) requires you to rule out the possibility of operations like infinity - infinity.

Re: 1/0 = 0

#583

Post by WalterBright »

karmakaze wrote: post #577
WalterBright wrote: post #555

Earlier quoted context omitted.

Aircraft and spacecraft all have backup systems for critical software. When software self detects a bug (such as an assert failure) the offending computer is shut down and electrically isolated, and the backup is engaged. What is absolutely NOT done is soldiering on with a computer in an unknown state. Any software system that is life critical is either designed this way or is very badly engineered. I've written a co…

And what if the program is the lowest level and getting into an impossible state due to a hardware issue (bad bit). At some level a program has to soldier-on.

Then it sets an I/O pin that pulls the reset switch.

Re: 1/0 = 0

#584

Post by j2kun »

hyperpape wrote: post #179
j2kun wrote: post #161

Earlier quoted context omitted.

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 same theorem forall c != 0, (a+b)/c = a/c + b/c is true before and after. It may be helpful to observe that while using the same symbol '/' in both cases is confusing, mathematical theorems are not about symbols, but about particular mathematical objects. The old theorem is about the division relation defined for real numbers != 0, the new one is a relation defined for all real numbers, that just happens to coinc…

That is exactly my point. Now you have to disambiguate a poorly-chosen symbol.

The theorem doesn't need the stipulation that c != 0 since you have already excluded c from the domain.

Re: 1/0 = 0

#585

Post by karmakaze »

WalterBright wrote: post #583
karmakaze wrote: post #577

Earlier quoted context omitted.

And what if the program is the lowest level and getting into an impossible state due to a hardware issue (bad bit). At some level a program has to soldier-on.

Then it sets an I/O pin that pulls the reset switch.

I cant tell ic you're being serious. The appropriateness of that would depend on whether the hardware condition was persistent in which case we have a reboot loop. It doesn't seem resonable for software meant to run in a harsh envirinment to assume prefect rumtime conditions. Do probabilitites and tradeoffs ever get considered when faced with inconsistent state?

Re: 1/0 = 0

#586

Post by kragen »

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…

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/

Re: 1/0 = 0

#587

Post by behringer »

jibal wrote: post #469
behringer wrote: post #373

Earlier quoted context omitted.

That's not correct mathematically though. You can't divide something 0 times and get any number. Adding zero + zero + zero infinite times does not equal 1.

"That's not correct mathematically though." Yes, certainly it is. "You can't divide something 0 times and get any number. Adding zero + zero + zero infinite times does not equal 1." The discussion is about mathematics, not elementary school arithmetic.

Feel free to give me a proof that adds zeros and gets a number greater than 0.

Re: 1/0 = 0

#590

Post by vmchale »

luso_brazilian wrote: post #7

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

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.
Post reply on HN