Technically, yes, there are other ways of initializing such values, but they're all either less obvious, or much less convenient.
If your platform uses IEEE floating point,1 any float
arithmetic that overflows, without raising any other flags besides overflow, is guaranteed to give you inf
. This means 1.0 / 0.0
probably won't work (Python will detect that this is a division by zero), but the even simpler 1e500
will.2
Once you have inf
, you can just do -inf
and inf/inf
to get the negative infinity and NaN values.
But would someone reading your code understand 1e500 / 1e500
as readily as float('nan')
? Probably not.
Meanwhile, you can always do something like struct.unpack('>f', b'\x7f\x80\0\0')[0]
, which unpacks the well-defined bit pattern for an IEEE big-endian double inf
value as a float
, whether your float
is that type under the covers or not. But why would you want to write (or read) that?3
But, if you're using Python 3.5 or later, you don't need to initialize those values; you can just use the constants in the math
module:
print(math.inf, +math.inf, -math.inf, math.nan)
And if you're using Python 2.7 or 3.4 or something, you can always just define your own constants and use them over and over:
inf, nan = float('inf'), float('nan')
print(inf, +inf, -inf, nan)
1. Technically, Python doesn't require IEEE floating point. In fact, what it requires are something that acts like the platform's C double
—which C doesn't require to be an IEEE type, and only if that makes sense for the implementation (e.g., Jython is obviously going to use the relevant Java type without caring what the C compiler used to compile the JVM thinks), and it doesn't clarify exactly what it means to act like a C double. However, the float
type—not to mention things like the math
module—really isn't going to work unless float
is something reasonably close to an IEEE float type, like maybe the pre-IEEE IBM and Intel types or the not-quite-IEEE Motorola compat types. Also, as of 2018, the only supported platforms by any of the three existing Python 3.x implementations all give you either IEEE 754-1985 double
or IEEE 754-2008 float64
. But, if this is really a potential issue for your code, you should check sys.float_info
to verify whatever assumptions are relevant.
2. It's conceivable that some platform might use an IEEE 754-1985 long double
or an IEEE 754-2008 float128
or something. If you're worried about that, just use a bigger number. Or, say, 1e500 ** 1e500 ** 1e500
.
3. Well, if you specifically need a quiet or signaling NaN, or one with a custom bit pattern instead of the default one… but anyone who needs that presumably already knows they need that.