Live data from Hacker News

1/0 = 0

hillelwayne.com

341–350 of 593 posts

Re: 1/0 = 0

#341
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

Rust has your back:

pub fn checked_div(self, rhs: u8) -> Option

Checked integer division. Computes self / rhs, returning None if rhs == 0.

You would use this as lhs.checked_div(rhs).unwrap_or(your sane default)

This is dramatically better than always returning zero silently, as doing so is bound to be wrong in certain cases. If you run into a situation where you are afraid your RHS may be 0 but still want to do the right thing, this is what you'd use.

Re: 1/0 = 0

#342

Earlier quoted context omitted.

Practically, it's quite common to not immediately know the divisor. In cases where the divisor is initially unknown but takes an imperceptible amount of time to compute it's better to render 0%. Otherwise you might get a flash of a full progress bar (for example) while the divisor is determined. Of course, it's context dependent. As others mention, your code might be full of stuff like X / (divisor || 1) .

X / (divisor || 1). It's invalid code in C, C++ and Java.

This is valid C and C++.

Re: 1/0 = 0

#343
post #194

Just yesterday I had a 1/0 bug (code iterating along some line segments that forgot to account for the possibility of a zero-length segment). If 1/0 was 0, the code would have worked correctly instead of crashing. So, there's one data point in favor. :-)

code iterating along some line segments that forgot to account for the possibility of a zero-length segment Out of curiosity, could you describe what you were doing and why 1/0 = 0 would have returned the correct result?

Hah, you know what, looking more closely at the code, the bug was not what I thought, and while the code doesn't crash now, it will still do the wrong thing!

So the code was given a path described by line segments p0-p1-p2-...pN, and what it wanted to do was find the point s distance along the path.

It's iterating over pairs of points (pI, pJ) and looking at the segment length. Is the segment length > the remaining length? If so, then we know our point is somewhere on the segment (pI, pJ). In particular, it is (remaining length) divided (segment length) pct along the segment.

This code was dying on zero-length segments (i.e., a repeated point) because of the divsion above. I wasn't thinking too clearly and fixed the problem by just skipping 0 length segments.

But actually, the only way that code can even trigger is if the original distance along the path was negative, in which case we actually just want to always return the start of the path.

So, in summary, my particular case was buggy either way, and 1/0 behavior doesn't hurt or help (except it caused a crash instead of an incorrect line in some cases; not really sure if that's better or worse).

For the case where we do have a zero-length segment, 1/0 = 0 would give desired behavior (just scale to first point in segment). (But of course, when it's a zero length segment, any value would be OK, since it would just get multiplied by zero again.)

Re: 1/0 = 0

#344

Please forgive my tone, it's not keeping in the noble spirit of Hacker News. But here goes: So that's it. I read your proof. You try cloaking it in pseudo-mathematical formulation, but what you are really doing is defining division as a derived operator, rather than the axiomatic operator it is in mathematics. I can say 1= infinity in my universe and as long as I am consistent, it is sound. You're saying this is a us…

The OP didn't invent the definition of fields as defined by additional and multiplication, with division defined as the Inverse of multiplication. Even the Wikipedia article on fields ( https://en.wikipedia.org/wiki/Field_%28mathematics%29#Defini... ) defines them this way. (Not that Wikipedia is an authority on truth, but I find that it's a pretty good indicator of what positions are common/widespread regarding a su…

Nice try, but sorry.

In your link, division is defined as the inverse of multiplication. However, the inverse of multiplication is one of the axioms of the field, so by transitivity, division is an axiom as well (it's simply a convenient label for "the inverse of multiplication"). One can put the name "Division" to some other axiom or derived property, absolutely, but then "the inverse of multiplication" still needs to be dealt with. The author, if you note, conveniently omits the multiplicative inverse from their stated axioms.

I'm far from a pure mathematician, but even I can see through the facade, implying that it's pretty thin.

Re: 1/0 = 0

#345
post #5

My two issue with this is it totally relies on a specially constructed definition, and it leads to unintuitive results. The issue with special definitions is you can use them to say anything you want, turning regular, common operations into weirdness. What does it mean to take a factorial on the real numbers, or to add only on the even integers? In both cases, we're twisting what are generally accepted mechanics and…

Just wanted to share: C++ allows you to overload operators, so you can certainly create your own universe of mathematics if desired.

Re: 1/0 = 0

#346
post #342

Earlier quoted context omitted.

X / (divisor || 1). It's invalid code in C, C++ and Java.

This is valid C and C++.

It is, but it will always give you a divisor of 1 (because "true" is 1 -- I also thought it would work until I tested it):

    % cat >division.c 
    
    int main(void)
    {
            printf("1/0 = %d\n", 1 / (0 || 1));
            printf("1/2 = %d\n", 1 / (2 || 1));
    
            printf("1.0/0 = %f\n", 1.0 / (0 || 1));
            printf("1.0/2 = %f\n", 1.0 / (2 || 1));
    }
    % gcc -Wall -o divison divison.c
    % ./divison
    1/0 = 1
    1/2 = 1
    1.0/0 = 1.000000
    1.0/2 = 1.000000
In Python this is not the case:

    % python3
    >>> 1 / (0 or 1)
    1
    >>> 1. / (0 or 1)
    1.0
    >>> 1 / (0 or 1)
    1
    >>> 1. / (2 or 1)
    0.5
    % python3
    >>> 1 / (0 or 1)
    1.0
    >>> 1 / (2 or 1)
    0.5

Re: 1/0 = 0

#347

Earlier quoted context omitted.

Zero goes into zero x times, for any real x. Infinity isn't real, therefore neither is infinity^2 so no.

Extrapolate. What value does 1/x approach? What about 2/x? And then, what about ∞/x? What value would we expect that to approach? ∞(±∞)

It doesn't approach anything, it's unbounded.

Re: 1/0 = 0

#348
post #324

Earlier quoted context omitted.

I can give you a simple proof by contradiction. 1. Let F be a field containing an element x =/= 0. 2. Suppose we have defined division by zero in F such that, for all x in F , there exists an element y = x /0 (i.e. F adheres to the field axiom of multiplicative closure). Note that at this point it does not matter how we have defined division by 0, we will just generously continue and assume you've done it in a way th…

>Since y = x/0, it follows that the product of y and 0 is equal to x, because division is the inverse of multiplication. Can you explain how this follows? I thought division was only the inverse of multiplication for all nonzero denominators, which would mean we can't use that definition for deduction in x/0. It might hinge on your next sentence: >By the field axioms, division does not exist if there is no multiplica…

Your edit is starting to get it. If by the argument of the article x/y = cotton candy for all x,y, then probably the argument of the article isn't good. And the reason is precisely that division in a field is taken to be nothing but a notational shorthand for multiplication by the multiplicative inverse.

Re: 1/0 = 0

#349

Earlier quoted context omitted.

You may not be familiar but a "factorial on the real numbers" is the gamma function and it has all sorts of useful applications. (it works on real and complex numbers except for non-positive integers)

The concerned reader might wonder how it is possible to assert that there is _one_ correct definition of an extension of the factorial function to the real/complex numbers. Why is the gamma function better than any other extension? The answer is that the gamma function is the unique logarithmically convex extension of the factorial function.

There ISN'T one correct extension of a factorial function.

The properties of the standard gamma function are great, but some might prefer the properties of Hadamard's or Luschny's alternative gamma function.

Like many arbitrary extensions in mathematics -- be it the factorial function or the division function which deals with 1 / 0 differently -- it's a matter of taste and convenience!

Interestingly the arbitrariness of some mathematical choices seem to unnerve folks on an almost existential level. My guess is that it conflicts with their expectation of capital T truth from mathematics.

Re: 1/0 = 0

#350
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

Most of the time when I have to think about what to do with a 0 divisor, I come to the conclusion that

  if (foo == 0):
    return MAX_FLOAT
  else:
    return bar / foo
is more sound for the given algorithm than "return 0" (still crappy, but more sound).

Then use MAX_FLOAT as an error flag instead of 0, which could have been the result of a legal operation (with bar==0).

Post reply on HN