81–90 of 593 posts
Earlier quoted context omitted.
It is inconsistent. If 1/0 = 0, then 1 = 0*0.
So according to you, 0*0 = 0, thus 0/0 = 0?
> 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.
[0] https://ziglang.org/documentation/master/#Standard-Library-M...
Earlier quoted context omitted.
> correctly state the undefined nature of 1/0 Erm, when we say it's "undefined" we mean it literally -- standard mathematical systems of arithmetic do not define a value for that division. If you make another system of arithmetic you can define it how you want and be consistent with "regular maths" for the operations in which things are defined. It's an extension. > We have "NaN" for a reason Funnily enough, IEEE754…
> Defining it as 0 at least means floating point numbers are (presumably) closed under arithmetic operations, which could be handy. They already are closed. Floating point includes Inf and Nan for that reason. :-)
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.
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…
Earlier quoted context omitted.
You’re doing something different than real number arithmetic. Saying 1/0 = x, and then treating x like a real number is inconsistent. But just saying “we are going to augment the real numbers with an element x that is not a real number, and then define some properties of x and prove things about it” is not.
> You’re doing something different than real number arithmetic Computer languages execute on rules that are not utilizing real number arithmetic. I didn't want to mention it, but there's these things called floats... Edit: Pony took out the "normal" version of division by zero and suggest to write a wrapper to check beforehand.
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.
It's like in Ruby, when you divide 3/2 you get 1 (integer division) which is almost never the behavior you want (unless you cast all you numbers to float which is a pain to do).
It's not always what you want, but it's pretty reasonable. The alternative would be if it always rounds up, which seems weirder to me. I don't think rounding to the nearest integer makes sense with integer quantities at all, that's strictly a real number operation.