The 2,500 year old history of why Python’s all([]) returns True

Re:The 2,500 year old history of why Python’s all([]) return... by JadeNB on Wednesday March 18, 2020 @01:05PM (#22618822)

0/0 isn't the best example, because every answer leads to a satisfying system—i.e., it'd be perfectly fine to have a multiply valued quotient here; we'd just have to let it infect all the rest of our arithmetic operations. It's 1/0 and other such fractions that have no sensible answer.

[ Parent | on HN ]

Re:The 2,500 year old history of why Python’s all([]) return... by eru on Thursday March 19, 2020 @09:49AM (#22627456)

I'm a bit confused.

You can make 1/0 return infinity, and preserve some properties of fields. Though that works best, if your zeroes are also signed.

But for 0/0, I don't see nearly as many properties you can rescue.

[ Parent | on HN ]

Re:The 2,500 year old history of why Python’s all([]) return... by JadeNB on Thursday March 19, 2020 @10:11AM (#22627628)

Whatever value x you assign to 1/0, it had better be true that multiplying it by 0 gives 1; and the properties of a field give that 0x = (0 + 0)x = 0x + 0x, so that 0x = 0. You thus would have to give up either distributivity or additive inverses, which are pretty dear to me!

If, on the other hand, you regard y = 0/0 as a "multi-valued variable" standing for any element of the field, then it behaves perfectly fine, since 0y = 0. The only problem is that it's infectious, so that just about any arithmetic computation involving it, like y + 1 or 2y, also suddenly has to stand for every element of your field. (If you work over a ring, then y + 1 stands for any element and 2y only stands for elements of the ideal generated by 2, etc.) Computations like 0y and y + (-y) both still yield 0.

This is not very useful—at least I can't see anything useful to come of it—but, aside from the infectious multi-valuedness, I don't see what problems result.

[ Parent | on HN ]