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

311–320 of 593 posts

Re: 1/0 = 0

#311

Post by halflings »

stringer wrote: post #75
halflings wrote: post #64

Unlike what the author says, this is the total opposite to a practical/pragmatic solution. He does not prove that this is a useful representation, only that given his own axioms, this can be considered mathematically correct. Very practical issues with 1/0 == 0: - This result is counter-intuitive, took building a custom fields and responding to the incredulity of all. - The main reason this is counter-intuitive is no…

Were are speaking of integers here not FP numbers.

The article mentions floating point numbers as well, and the same applies to integers anyway. Only used FP numbers for emphasis.

Re: 1/0 = 0

#312

Post by imh »

throwawaymath wrote: post #295
imh wrote: post #275

Earlier quoted context omitted.

But the point is you keep the structure of a field for everything that already has it, right? No structure is taken away. All statements valid on any subset of the reals are still valid without modification under this new definition. The algebraic structure is still a field obeying the same axioms. There are just some new valid statements too.

No that's not correct, and this is why I think the author's entire point is pretty inane. If you're going to start off your argument with the full formalism of field axioms and consequent theorems, you need to be prepared to split hairs about whether or not your definitions constitute a field. Mathematics is thoroughly pedantic about definitions for a reason. If those formalisms don't matter because what you've done…

Is there a proof or something elsewhere you can link to? To be honest I can't really tell the point you're trying to make.

Re: 1/0 = 0

#313

Post by lisael »

PopeDotNinja wrote: post #120

Meanwhile, in Python v3.7.0... >>> 1 / 0 Traceback (most recent call last): File " ", line 1, in ZeroDivisionError: division by zero >>> 0 / 0 Traceback (most recent call last): File " ", line 1, in ZeroDivisionError: division by zero >>> 1 / 0.0 Traceback (most recent call last): File " ", line 1, in ZeroDivisionError: float division by zero >>> 0.0 / 0.0 Traceback (most recent call last): File " ", line 1, in ZeroD…

Meanwhile, in Python...

  In [1]: 255 + 1 is 256
  Out[1]: True
  In [2]: 256 + 1 is 257
  Out[2]: False
Every language has its inconsistencies, when it comes to math, because they run on real-world computers. All these are "slow" interpreted languages that allow runtime failures and don't use plain machine integers. Just a different trade-off.

Anyway, the Inf/NaN trick is not better than the 0 trick in my opinion, because all subsequent operations result happily in NaN. I've never seen in any NaN language a program that checks for NaN the result of each and every division.

with a NaN-kind of language, it would be:

  a = b/c
  if a == NaN:
    print "oops"
with a 0-trick language:

  a = b/c
  if a == 0 and c == 0:
    print "oops"
not THAT different, IMO :)

Re: 1/0 = 0

#314

Post by user5994461 »

l_t wrote: post #304
user5994461 wrote: post #298

Earlier quoted context omitted.

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

Boolean operators returning values is common, especially in dynamically typed languages. The code is valid in JavaScript, for example, and in Python (except it uses "or" instead of "||").

In python, it should probably be corrected with // or 1.0 to make it either an integer division or a float division.

Re: 1/0 = 0

#316

Post by glitchc »

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 useful property to have, and certainly that holds merit in certain conditions, but it is not a correct property.

Your article title should be clarified to state "1/0=0 (in my universe)." But then it wouldn't be controversial would it? After all, this is just an experiment to gain some visibility for Pony, isn't it?

Re: 1/0 = 0

#317

Post by glitchc »

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…

It happens in scientific computing with zero bounded signals fairly regularly. Sometimes values hover close enough to zero that the computation results in a/0. It's not desired but the only alternative is a guard that invariably adds a performance penalty. There are other ways around it, such as normalization, but they're not trivial depending on the problem and can actually add other sources of bugs/errors. I understand the author's intent even though I disagree with the result.

Re: 1/0 = 0

#318

Post by Zalastax »

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.

In Agda you have the choice of either making it truncate at 0 or constrain the domain to (a - b, a >= b) in which case you don't hve to define the function when a = b without sacrificing performance.

Re: 1/0 = 0

#319

Post by throwawaymath »

imh wrote: post #312
throwawaymath wrote: post #295

Earlier quoted context omitted.

No that's not correct, and this is why I think the author's entire point is pretty inane. If you're going to start off your argument with the full formalism of field axioms and consequent theorems, you need to be prepared to split hairs about whether or not your definitions constitute a field. Mathematics is thoroughly pedantic about definitions for a reason. If those formalisms don't matter because what you've done…

Is there a proof or something elsewhere you can link to? To be honest I can't really tell the point you're trying to make.

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 that maintains the other field axioms.

3. Since y = x/0, it follows that the product of y and 0 is equal to x, because division is the inverse of multiplication. By the field axioms, division does not exist if there is no multiplicative inverse with which to multiply.

4. But by the field axioms this implies that x = 0, which contradicts our initial assumption. Likewise, since we can repeat this procedure with any element x in F, this demonstrates that there exists no nonzero element x in F, and in fact F = {0}.

The failure in the article's refutation is that this proof is designed to permit you to assume you have suitably defined division by zero, then proceed to demonstrate without any loss of generality that you could not possibly have unless 1) F is not a field, or 2) F contains only 0. The fundamental algebraic property you sacrifice by defining division by zero is uniqueness, and uniqueness is a hard requirement in fields with nonzero elements.

Re: 1/0 = 0

#320

Post by l_t »

user5994461 wrote: post #314
l_t wrote: post #304

Earlier quoted context omitted.

Boolean operators returning values is common, especially in dynamically typed languages. The code is valid in JavaScript, for example, and in Python (except it uses "or" instead of "||").

In python, it should probably be corrected with // or 1.0 to make it either an integer division or a float division.

Ah, that's true. Good point.
Post reply on HN