On Tue, 15 Sep 2020 at 16:48, Stephen J. Turnbull
Paul Moore writes:
OK, so to me, 1.0 / 0.0 *is* a "true infinity" in that sense. If you divide "one" by "zero" the only plausible interpretation - if you allow infinity in your number system - is that you get infinity as a result. Of course that just pushes the question back to whether you mean (mathematical) "one" and "zero" when you make that statement.
The answer is yes. I can say so authoritatively :-) because I introduced the term "true infinity" into this thread to distinguish those results of computations done in the extended real system result in infinity from those results of computations in the extended real system which result in finite values, but overflow the floating point representation. Both kinds of values are represented by inf in the Python (or IEEE 754) floating point number system.
This is not a philosophical question, as you seem to think. It's purely terminological, an abbreviation for the long sentence above. I thought that would be obvious, but I guess I have a Dutch ancestor I didn't know about. ;-) I apologize for not being more careful.
I'm going to skip a huge chunk of your reply. I've read it, and get what you're saying. I even agree with the majority of the comments. I was skimming the thread initially, and I think that in doing so I missed some of the context. I'm not 100% sure I agree with you on *all* points, but you're right that I'm looking at the discussion from a perspective that you didn't intend, and by doing so I doubt I'm helping, so I'll duck out of the philosophy at this point :-)
I don't have any problem with 1 // 0 raising and 1 / 0 returning inf because Python is not Lisp[1]: x / y *always* gives a float result. 1 / 0 "should" obey float conventions. Users need to know that floats are weird in a host of ways, so making users learn that 1 / 0 does something different from 1 // 0 doesn't seem like a deal-breaker. If I were designing Python numerics for Python 4.0 ... but I'm not. <shudder/>
And as soon as we start considering integer division, we're talking about breaking a *vast* amount of code.
Yeah, I'm ok with *not* breaking that code.
You may have misunderstood me - when I said "integer division", I meant "division of two integers", not "the // operator", so I was including 1 / 0. So having 1/0 return inf would break all the code that checks for ZeroDivisionError on the / operator, which was my concern. And having 1/0 behave differently than 1.0/0.0 makes me very uncomfortable, even though you can argue that by using floats I was implicitly accepting float semantics (and nans). My *only* concern with the points you and Ben were making was that you seemed to be suggesting changes to the division operator and ZeroDivisionError, which I view as being much more controversial than any other aspect of what you were saying. (Basically, everything else I'm at best +0 on, and mostly "don't care").
But I still do not see what practical use there is in putting inf in the builtins, except saving a few keystrokes for people who generally will not know what they're doing.
This point, I 100% agree with. Paul