I just realized I've been forgetting to CC the list. It is a bit long, but I'll cut out the non-relevant portions that everyone has seen before. In chronological order below. I ask the rest of you, does Some sound so crazy? - Josiah *** message from Josiah Carlson on Sun, 21 Dec 2003 19:05:45 -0800 ***
-1. Depending on your algorithm you can already use sys.maxint, or a large float (e.g. 1e300), or you can write 1e1000 (or 1e300**2) which on most systems evaluates to a floating point Infinity. And "Some" sounds like a really strange spelling of "Infinity". There's also a PEP (PEP 754) to add a proper way to spell floating point Infinity. Or you could reverse signs and use min(None, -a).
--Guido van Rossum (home page: http://www.python.org/~guido/)
I've read PEP 754, and yes, the author talks about having a proper Infinity, -Infinity and Not a Number (PosInf, NegInf and NaN respectively), but considering that it has been in the 'draft' state since March 28, has not been updated, and it doesn't seem like Python is any closer to having proper definitions now than it was ~9 months ago, I'm not going to put my eggs in the IEEE 754 Infinity basket. In terms of having something useful on a platform, there is only so useful that infinity can be. The below is from the windows verstion of Python 2.3.2
1e309 1.#INF -1e309 -1.#INF 1.#INF 1.0 max(1e309, 0) 1.#INF min(1e309, 10**309) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: long int too large to convert to float
The real trick is that it is not so much about being able to have max(Some, a) -> Some, it is about being able to have min(Some, a) -> a. Then you don't need to worry about sys.maxint not being big enough (because there are larger numbers), nor do you need to worry about float casts of large integers producing OverflowErrors. As for an application, many path searches in graphs start out with initializing distances to infinity, Some would be suitable for this. Other algorithms require a negative infinity for this, None has been working fine. As an initialization value, I believe that Some would be quite a useful object. Certainly Some seems like a strange way to spell infinity, but it is a logical infinity, one that you can compare things against, anything, not just Python floats or things that can be cast into Python floats. In terms if PEP 754, if it were actually implemented, certainly there would be some question as to whether Some would be equal to PosInf. If so, then would -Some be equal to NegInf? And if so, would None be equal to NegInf? Maybe such things would require a float cast. I talk about all this in my PEP submission, which isn't up yet. I suppose I probably should have given it a few days before discussing it, but yeah. - Josiah *** end message from Josiah *** *** message from Guido van Rossum on Sun, 21 Dec 2003 20:45:34 -0800 ***
I've read PEP 754, and yes, the author talks about having a proper Infinity, -Infinity and Not a Number (PosInf, NegInf and NaN respectively), but considering that it has been in the 'draft' state since March 28, has not been updated, and it doesn't seem like Python is any closer to having proper definitions now than it was ~9 months ago, I'm not going to put my eggs in the IEEE 754 Infinity basket.
I expect your PEP will fare no better, and given its weirdness, probably much worse. Do you know of any language that has a similar concept? --Guido van Rossum (home page: http://www.python.org/~guido/) *** end message from Guido *** *** message from Josiah Carlson on Sun, 21 Dec 2003 21:47:34 -0800 ***
I expect your PEP will fare no better, and given its weirdness, probably much worse. Do you know of any language that has a similar concept?
Is None so weird? All I am proposing is a symmetric value to None. Just like there is a -1 and 1, -Infinity and Infinity, None logically should have Some. Maybe not so much -Some == None, but as I propose in the PEP, possibly Some == not None. - Josiah *** end message from Josiah ***