31–40 of 593 posts
Earlier quoted context omitted.
It is inconsistent. If 1/0 = 0, then 1 = 0*0.
1/0 = undef (cast to 0) 1 != 0*0 I don't see the inconsistency. Abstract math vs practical application.
> 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…
What if number types were Optionals after any operation that could result in any kind of unusual number (sqrt(-1), Infinity, NaN)? Or maybe after every operation, since any operation could overflow the type. Do any languages do that? Seems more consistent (if way more hassle) than giving a mathematically false result out of pragmatism. At least in a strictly typed language.
Earlier quoted context omitted.
> You know.. dividing is like breaking something up.. If you divide by 2, you break it up into 2 pieces.. if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0. And dividing by 0.5 is breaking into how many pieces exactly?
I guess its more flipped. How many pieces equal the whole, not how many pieces can the whole be broken up into. That's why you can't divide by 0, any number of nothing can't make a whole. *disclamer: I have no math background whatso ever
The reason it's a useful function is it has some properties:
y=1/x is continuous except where x==0. That is, as you approach 0 from either side, it grows to either +- infinity. The developers of this language want to make this function ==0 when x is 0.
You can do that, sure, but it doesn't change the fact that when you go from +0.0000001 to -0.0000001, you now have 2 non-continuous jumps instead of just one.
> 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…
> the many pieces of code that assume that (x / y) * y equals x The same issue if division by zero throws an exception. This is simply a more practical approach that dispenses with the exception handling (ie becomes a less irregular test case). Edit: Not buggy behavior, when expected.
Earlier quoted context omitted.
I think OP means that nothing breaks mathematically. It is not inconsistent and not false, so you can work with it. The only issue is to deal specially with the case of division by zero, which you have to do anyways. Code that assumes that (x/y) * y = x is wrong if you don't check for y = 0, independently of what you define x/0 to be.
It is inconsistent. If 1/0 = 0, then 1 = 0*0.
You know.. dividing is like breaking something up.. If you divide by 2, you break it up into 2 pieces.. if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0.
> You know.. dividing is like breaking something up.. If you divide by 2, you break it up into 2 pieces.. if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0. And dividing by 0.5 is breaking into how many pieces exactly?
Multiplying by the square root of 2 is also a fun one since you need limits to show people that real numbers only make sense with the least upper bound theorem and limits and things they expect to work "intuitively" (like division or multiplication) only have approximate meaning when they use the common operations.
But that isn't my only qualm.
In the construction of the fields, there is a simple definition of the division function. It is intrinsically the solution of a = r * b, where r is the unknown. If a is nonzero, and b is zero, then r, the ratio, is said not to exist. Put another way, there is no real value of r that can be chosen that satisfies r * 0 = a. See [1] for example, as 0 is not an invertible element of the field over the reals.
So ... I can't say I agree with their choice of 1/0 == 0. They may be free to choose any value they wish, but then from an aesthetic viewpoint, do they really want to surprise the user?
What proportion of the time will a divide-by-zero operation be a symptom of a bug, where evaluating 1/0 as any valid number will make it harder to identify that bug?
There might be a mathematical justification for 1/0 = 0, but the computer science justification seems tenuous at best. The overwhelming majority of the time, I want divide-by-zero to throw an exception or evaluate to NaN. I'd far rather deal with the edge case of intentionally dividing by zero, rather than the not-at-all-uncommon case of unintentionally dividing by zero and getting unexpected behaviour as a result.
You know.. dividing is like breaking something up.. If you divide by 2, you break it up into 2 pieces.. if you divide by 0, from some standpoints, you do have nothing, because you broke it up into 0 pieces, and 0 pieces is 0.
This explains exactly why we shouldn't divide by 0. The pieces after breakage should, if one is so inclined, be able to be re-assembled into the whole; but, once you break something into 0 pieces, it is gone. Thus at best `0/0` could be defined … but the problem there is not that there's no answer but that every answer is equally good.