2013-03-31 12 views
6

Qualcuno mi potrebbe spiegare questo pice di codice:Comportamento della funzione "round" in Python

>>> round(0.45, 1) 
0.5 
>>> round(1.45, 1) 
1.4 
>>> round(2.45, 1) 
2.5 
>>> round(3.45, 1) 
3.5 
>>> round(4.45, 1) 
4.5 
>>> round(5.45, 1) 
5.5 
>>> round(6.45, 1) 
6.5 
>>> round(7.45, 1) 
7.5 
>>> round(8.45, 1) 
8.4 
>>> round(9.45, 1) 
9.4 

Aggiornato

Credo che sia a causa della rappresentazione galleggiante. Ho ragione?

+0

stesso fenomeno in 2.7.2 – frickskit

+1

correlate: http://stackoverflow.com/questions/10825926/python-3-x-rounding-behavior. La risposta è qui: http://stackoverflow.com/a/10093820/1258041 –

+0

@SperanskyDanil Hai ragione, mi dispiace, questo non è lo stesso –

risposta

8

Hai ragione. Nessuno dei numeri può essere rappresentato esattamente. In alcuni casi la parte frazionaria è strettamente maggiore di 0.45 e in alcuni è strettamente minore:

In [4]: ['%.20f' % val for val in (0.45, 1.45, 2.45, 3.45, 4.45, 5.45, 6.45, 7.45, 8.45, 9.45)] 
Out[4]: 
['0.45000000000000001110', 
'1.44999999999999995559', 
'2.45000000000000017764', 
'3.45000000000000017764', 
'4.45000000000000017764', 
'5.45000000000000017764', 
'6.45000000000000017764', 
'7.45000000000000017764', 
'8.44999999999999928946', 
'9.44999999999999928946'] 

Questo spiega l'arrotondamento apparentemente incoerente.

0

come NPE ha detto che la rappresentazione binaria di un numero decimale non è esatto, in modo da poter ottenere un comportamento strano da arrotondamento, un modulo che risolve questo problema è decimale, Here is the official documentation