Numpy redondea de una manera diferente que python

El código

import numpy as np a = 5.92270987499999979065 print(round(a, 8)) print(round(np.float64(a), 8)) 

da

 5.92270987 5.92270988 

¿Alguna idea de por qué?

No se encontró nada relevante en las fonts numpy.

Actualizar:
Sé que la manera correcta de lidiar con este problema es construir progtwigs de tal manera que esta diferencia sea irrelevante. Que yo hago Me topé con ella en las pruebas de regresión.

    Actualización2:
    Respecto al comentario de @VikasDamodar. Uno no debe confiar en la función repr() :

     >>> np.float64(5.92270987499999979065) 5.922709875 >>> '%.20f' % np.float64(5.92270987499999979065) '5.92270987499999979065' 

    Update3:
    Probado en python3.6.0 x32, numpy 1.14.0, win64. También en python3.6.4 x64, numpy 1.14.0, debian.

    Actualización 4:
    Sólo para estar seguro:

     import numpy as np a = 5.92270987499999979065 print('%.20f' % round(a, 8)) print('%.20f' % round(np.float64(a), 8)) 5.92270987000000026512 5.92270988000000020435 

    Actualización 5:
    El siguiente código muestra en qué etapa se produce la diferencia sin usar str :

     >>> np.float64(a) - 5.922709874 1.000000082740371e-09 >>> a - 5.922709874 1.000000082740371e-09 >>> round(np.float64(a), 8) - 5.922709874 6.000000496442226e-09 >>> round(a, 8) - 5.922709874 -3.999999442783064e-09 

    Claramente, antes de aplicar ‘redondos’ eran el mismo número.

    Actualización 6:
    En contraste con la respuesta de @ user2357112, np.round es aproximadamente 4 veces más lento que la ronda:

     %%timeit a = 5.92270987499999979065 round(a, 8) 1.18 µs ± 26.5 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) %%timeit a = np.float64(5.92270987499999979065) round(a, 8) 4.05 µs ± 43.9 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each) 

    También en mi opinión, np.round hizo un mejor trabajo redondeando a la más cercana incluso que la round incorporada: originalmente obtuve este número 5.92270987499999979065 dividiendo 11.84541975 por dos.