Numpy float64 vs Python flotteur

Je suis en luttant contre certains virgule flottante problèmes dans les Pandas read_csv fonction. Dans mon enquête, j'ai trouvé ceci:

In [15]: a = 5.9975

In [16]: a
Out[16]: 5.9975

In [17]: np.float64(a)
Out[17]: 5.9974999999999996

Pourquoi est builtin float de Python et de la np.float64 type de Python donnant des résultats différents? Je pensais qu'ils étaient tous les deux C++ doubles?

Notez également que les Pandas read_csv fonction emploie son propre super-rapide de chaîne-à-flotteur de conversion qui est pas arrondie. Ainsi, après l'exportation d'une valeur, et re-lecture, la valeur récupérée peut-être 1 ou 2 ulps différent de l'original.

OriginalL'auteur mchangun | 2014-11-24

  1. 16
    >>> numpy.float64(5.9975).hex()
'0x1.7fd70a3d70a3dp+2'
>>> (5.9975).hex()
'0x1.7fd70a3d70a3dp+2'

    Ils sont le même nombre. Ce qui diffère, c'est leur représentation; le Python type natif utilise une "saine" de la représentation et de la NumPy type utilise une représentation précise.

    Par la représentation, tu veux dire la façon dont il est imprimé à l'écran?
    Via le __repr__() méthode ou de son C de niveau équivalent, oui.
    Un véritable précis représentation serait effectivement 5.99749999999999960920149533194489777088165283203125, qui est l'exacte valeur décimale de l'64-bit à virgule flottante que vous obtenez lorsque vous évaluez le flotteur littérale 5.9975.
    Le max de précision d'un flotteur 64 peut atteindre près de 10 à 16 (de l'unité à la dernière place (ULP), voir en.wikipedia.org/wiki/Floating-point_arithmetic) donc l'idée d'une valeur décimale significative de plus de 16 chiffres pour un virgule flottante est trompeuse.
    Chaque numériques binary64 représentation n'en fait d'un exact équivalent décimal. Le problème se produit lorsque nous croyons que beaucoup moins de précision la valeur décimale est représenté par un binary64 valeur.

    OriginalL'auteur