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

161–170 of 593 posts

Re: 1/0 = 0

#161

Post by j2kun »

hyperpape wrote: post #102
j2kun wrote: post #80

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

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.

Re: 1/0 = 0

#162

Post by azernik »

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

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

Re: 1/0 = 0

#163

Post by [deleted] »

SamReidHughes wrote: post #160
c3534l wrote: post #145

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

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.

[deleted]

Re: 1/0 = 0

#164

Post by PyroLagus »

genezeta wrote: post #62
banachtarski wrote: post #32

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.

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…

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

Re: 1/0 = 0

#165

Post by ArtWomb »

spooneybarger wrote: post #103

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

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!

Re: 1/0 = 0

#166

Post by mreome »

cryptonector wrote: post #116
mreome wrote: post #97

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.

Re: 1/0 = 0

#167

Post by c3534l »

recursive wrote: post #151
c3534l wrote: post #145

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

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.

I would think that the result of a nonzero int minus a nonzero int would be an integer. So f(nonzero x, y) = y / x is fine, but f(nonzero x, nonzero y, z) = z / (x - y) is not.

Re: 1/0 = 0

#168

Post by nostalgeek »

ushi wrote: post #132

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

AFAIK Javascript does this as well.

Re: 1/0 = 0

#169

Post by mywittyname »

c3534l wrote: post #145

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

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.

Re: 1/0 = 0

#170

Post by [deleted] »

c3534l wrote: post #145

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

[deleted]
Post reply on HN