On Tue, 15 Sep 2020 at 16:48, Stephen J. Turnbull <[email protected]> wrote: > > 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 _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XQ4E6FO66SZ5AHBU22BDEIHKHSS7ZZ6N/ Code of Conduct: http://python.org/psf/codeofconduct/
