Numpy的float32和float比较

Question

Continuing from Difference between Python float and numpy float32 :

import numpy as np

a = 58682.7578125
print(type(a), a)
float_32 = np.float32(a)
print(type(float_32), float_32)
print(float_32 == a)

Prints:

<class 'float'> 58682.7578125
<class 'numpy.float32'> 58682.8
True

I fully understand that comparing floats for equality is not a good idea but still shouldn't this be False (we're talking about differences in the first decimal digit, not in 0.000000001) ? Is it system dependent ? Is this behavior somewhere documented ?

EDIT: Well it's the third decimal:

print(repr(float_32), repr(a))
# 58682.758 58682.7578125

but can I trust repr ? How are those stored internally in the final end ?

EDIT2: people insist that printing float_32 with more precision will give me its representation. However as I already commented according to nympy's docs :

the % formatting operator requires its arguments to be converted to standard python types

and:

print(repr(float(float_32)))

prints

58682.7578125

An interesting insight is given by @MarkDickinson here , apparently repr should be faithful (then he says it's not faithful for np.float32 ).

So let me reiterate my question as follows:

• How can I get at the exact internal representation of float_32 and a in the example ? If these are the same, then problem solved if not,
• What are the exact rules for up/downcasting in a comparison between python's float and np.float32 ? I 'd guess that it upcasts float_32 to float although @WillemVanOnsem suggests in the comments it's the other way round

My python version:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32

Answer 1

The numbers compare equal because 58682.7578125 can be exactly represented in both 32 and 64 bit floating point. Let's take a close look at the binary representation:

32 bit:  01000111011001010011101011000010
sign    :  0
exponent:  10001110
fraction:  11001010011101011000010

64 bit:  0100000011101100101001110101100001000000000000000000000000000000
sign    :  0
exponent:  10000001110
fraction:  1100101001110101100001000000000000000000000000000000

They have the same sign, the same exponent, and the same fraction - the extra bits in the 64 bit representation are filled with zeros.

No matter which way they are cast, they will compare equal. If you try a different number such as 58682.757812 4 you will see that the representations differ at the binary level; 32 bit looses more precision and they won't compare equal.

(It's also easy to see in the binary representation that a float32 can be upcast to a float64 without any loss of information. That is what numpy is supposed to do before comparing both.)

import numpy as np

a = 58682.7578125
f32 = np.float32(a)
f64 = np.float64(a)

u32 = np.array(a, dtype=np.float32).view(dtype=np.uint32)
u64 = np.array(a, dtype=np.float64).view(dtype=np.uint64)

b32 = bin(u32)[2:]
b32 = '0' * (32-len(b32)) + b32  # add leading 0s
print('32 bit: ', b32)
print('sign    : ', b32[0])
print('exponent: ', b32[1:9])
print('fraction: ', b32[9:])
print()

b64 = bin(u64)[2:]
b64 = '0' * (64-len(b64)) + b64  # add leading 0s
print('64 bit: ', b64)
print('sign    : ', b64[0])
print('exponent: ', b64[1:12])
print('fraction: ', b64[12:])

Answer 2

The same value is stored internally, only it doesn't show all digits with a print

Try:

 print "%0.8f" % float_32

See related Printing numpy.float64 with full precision

Answer 3

The decimal 58682.7578125 is the exact fraction ( 7511393/128 ).

The denominator is a power of 2 ( 2**7 ), and the numerator span 23 bits. So this decimal value can be represented exactly both in float32 (which has 24 bits significand) and float64.

Thus the answer of Victor T is correct: in internal representation, it's the same value.

The fact that equality answer true for same value, even for different types is a good thing IMO, what do you expect of (2 == 2.0) ?

Answer 4

They're equal. They're just not printing the same because they use different printing logic.

How can I get at the exact internal representation of float_32 and a in the example ?

Well, that depends on what you mean by "exact internal representation". You can get an array of bit values, if you really want one:

>>> b = numpy.float32(a)
>>> numpy.unpackbits(numpy.array([b]).view(numpy.uint8))
array([1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0,
       1, 0, 1, 0, 0, 0, 1, 1, 1], dtype=uint8)

which is as close as you'll get to the "exact internal representation", but it's not exactly the most useful thing to work with. (Also, the results will be endianness-dependent, because it really is based on the raw internal representation.)

If you want a C-level float, which is how NumPy represents float32 values at C level... well, that's C. Unless you want to write your own C extension module, you can't work with C-level values directly. The closest you can get is some sort of wrapper around a C float, and hey! You already have one! You don't seem happy with it, though, so this isn't really what you want.

If you want the exact value represented in human-readable decimal, printing it with extra precision using str.format or by converting it to a regular float and then a decimal.Decimal would do that.

>>> b
58682.758
>>> decimal.Decimal(float(b))
Decimal('58682.7578125')

The 58682.7578125 value you picked happens to be exactly representable as a float, so the decimal representation coming out happens to be exactly the one you put in, but that won't usually be the case. The exact decimal representation you typed in is discarded and unrecoverable.

What are the exact rules for up/downcasting in a comparison between python's float and np.float32 ?

The float32 gets converted to a float64, losslessly.

Answer 5

58682.8

My machine shows 58682.758 for this line.

I fully understand that comparing floats for equality is not a good idea

It is "not a good idea" if they calculated independently. On the other hand, it is a good idea if you get the same number and check its conversion.

Is it system dependent ? Is this behavior somewhere documented ?

It's fully dependent on conversion to text. According to comments, float32 is essential. If so, the guaranteed accuracy for float32 is 7 decimal digits, unlike Python's internal float that is float64 (at least on x86). That is why the value is truncated in print. The recommended way to print float values in decimal is to stop when output form is that converts back to the same internal value. So it reduces 58682.7578125 to 58682.758: the difference is less than ULP.

The same value printed as internal "float" or numpy float64 will have more significant digits because their omission will result in another internal value:

>>> 58682.758 == 58682.7578125
False
>>> numpy.float32(58682.758) == numpy.float32(58682.7578125)
True
>>> print(repr(numpy.float32(58682.758).data[0:4]))
'\xc2:eG'
>>> print(repr(numpy.float32(58682.7578125).data[0:4]))
'\xc2:eG'
>>> numpy.float64(58682.758) == numpy.float64(58682.7578125)
False
>>> print(numpy.float64(58682.758).hex(), numpy.float64(58682.7578125).hex())
('0x1.ca7584189374cp+15', '0x1.ca75840000000p+15')

You are lucky these two values are equal in float32 with this concrete value (was this intentional?) but it might be different with other one.