On Sat, Sep 12, 2020 at 11:06:35AM -0400, Cade Brown wrote:
If, in the future, Python used a library such as MPFR and made all floats a given precision (say, by giving a flag to the interpreter "python -prec2048"), it would never be enough to make infinity because it only has the limitation of a 64 bit exponent.
Nobody is recommending that the best way to create an infinity is by writing 1e1000 or whatever other out of range number you choose. We're not using Python 2.4 anymore, and the correct ways to create an infiniy float is one of:
float('inf') from math import inf
(Or rather, most of us aren't using Python 2.4 anymore. For my sins, I am still maintaining code that is expected to run back to 2.4. Yay.)
Using something like 1e1000 (or choose a larger exponent) is a fall back for when nothing else works, and if that trick doesn't work either, then you have no hope for it, you are running on some weird machine without IEEE-754 semantics and there probably isn't an infinity at all.
In my own code I have something like this:
try: from math import inf except ImportError: try: inf = float('inf') except ValueError: # Could be Windows in 2.4 or 2.5? try: inf = float('1.#INF') except ValueError: # Desperate times require desperate measures. try: inf = 1e1000 assert inf > 0 and inf == 2*inf except (OverflowError, AssertionError): # Just give up, there is no infinity available. pass
Fortunately, I don't have to support some hypothetical future Python with 2048 bit non-IEEE-754 floats, but if I did, I'm sure that the import from math would work and the rest of the nested blocks would never be called.
This is just an example of course, probably won't happen, but when I read "1e1000" or such a number it doesn't strike me as infinite (although a particular version of IEEE floating point may consider it that), it strikes me as a lazy programmer who thinks it's bigger than any other number he's processing.
Well, I guess the code above makes me a lazy programmer.