14. Aritmatika Pecahan Floating Point: Masalah dan Keterbatasan¶
Angka pecahan floating point diwakili dalam perangkat keras komputer sebagai pecahan basis 2 (biner). Misalnya, pecahan desimal:
0.125
memiliki nilai 1/10 + 2/100 + 5/1000, dan dengan cara yang sama pecahan biner
0.001
memiliki nilai 0/2 + 0/4 + 1/8. Dua pecahan ini memiliki nilai yang identik, satu-satunya perbedaan nyata adalah bahwa yang pertama ditulis dalam notasi fraksi basis 10, dan yang kedua dalam basis 2.
Sayangnya, sebagian besar pecahan desimal tidak dapat direpresentasikan persis dengan pecahan biner. Konsekuensinya adalah bahwa, secara umum, angka pecahan floating-point desimal yang Anda masukkan hanya didekati oleh angka-angka pecahan floating-point biner yang sebenarnya disimpan dalam mesin.
Masalahnya lebih mudah dipahami pada awalnya di basis 10. Pertimbangkan fraksi 1/3. Anda dapat memperkirakannya sebagai pecahan basis 10:
0.3
atau, lebih baik,
0.33
atau, lebih baik,
0.333
dan seterusnya. Tidak peduli berapa banyak digit yang Anda ingin tulis, hasilnya tidak akan pernah benar-benar 1/3, tetapi akan menjadi perkiraan yang semakin baik dari 1/3.
Dengan cara yang sama, tidak peduli berapa banyak digit basis 2 yang ingin Anda gunakan, nilai desimal 0.1 tidak dapat direpresentasikan persis sebagai fraksi basis 2. Dalam basis 2, 1/10 adalah percahan berulang yang tak terhingga
0.0001100110011001100110011001100110011001100110011...
Stop at any finite number of bits, and you get an approximation.
On a typical machine running Python, there are 53 bits of precision available
for a Python float, so the value stored internally when you enter the decimal
number 0.1 is the binary fraction
0.00011001100110011001100110011001100110011001100110011010
which is close to, but not exactly equal to, 1/10.
It's easy to forget that the stored value is an approximation to the original decimal fraction, because of the way that floats are displayed at the interpreter prompt. Python only prints a decimal approximation to the true decimal value of the binary approximation stored by the machine. If Python were to print the true decimal value of the binary approximation stored for 0.1, it would have to display
>>> 0.1
0.1000000000000000055511151231257827021181583404541015625
Itu lebih banyak angka daripada yang dianggap berguna oleh kebanyakan orang, jadi Python menjaga jumlah angka tetap dapat dikelola dengan menampilkan nilai bulat sebagai gantinya
>>> 0.1
0.1
It's important to realize that this is, in a real sense, an illusion: the value in the machine is not exactly 1/10, you're simply rounding the display of the true machine value. This fact becomes apparent as soon as you try to do arithmetic with these values
>>> 0.1 + 0.2
0.30000000000000004
Perhatikan bahwa ini adalah sifat dasar dari pecahan floating-point biner: ini bukan bug di Python, dan ini juga bukan bug dalam kode Anda. Anda akan melihat hal yang sama dalam semua bahasa yang mendukung aritmatika pecahan floating-point perangkat keras Anda (meskipun beberapa bahasa mungkin tidak display perbedaan secara default, atau dalam semua mode keluaran).
Other surprises follow from this one. For example, if you try to round the value 2.675 to two decimal places, you get this
>>> round(2.675, 2)
2.67
The documentation for the built-in round() function says that it rounds
to the nearest value, rounding ties away from zero. Since the decimal fraction
2.675 is exactly halfway between 2.67 and 2.68, you might expect the result
here to be (a binary approximation to) 2.68. It's not, because when the
decimal string 2.675 is converted to a binary floating-point number, it's
again replaced with a binary approximation, whose exact value is
2.67499999999999982236431605997495353221893310546875
Since this approximation is slightly closer to 2.67 than to 2.68, it's rounded down.
If you're in a situation where you care which way your decimal halfway-cases
are rounded, you should consider using the decimal module.
Incidentally, the decimal module also provides a nice way to "see" the
exact value that's stored in any particular Python float
>>> from decimal import Decimal
>>> Decimal(2.675)
Decimal('2.67499999999999982236431605997495353221893310546875')
Another consequence is that since 0.1 is not exactly 1/10, summing ten values of 0.1 may not yield exactly 1.0, either:
>>> sum = 0.0
>>> for i in range(10):
... sum += 0.1
...
>>> sum
0.9999999999999999
Aritmatika pecahan floating-point biner memiliki banyak kejutan seperti ini. Masalah dengan "0.1" dijelaskan secara rinci di bawah ini, di bagian "Representation Error". Lihat Perils of Floating Point untuk penjelasan lebih lengkap tentang kejutan umum lainnya.
As that says near the end, "there are no easy answers." Still, don't be unduly wary of floating-point! The errors in Python float operations are inherited from the floating-point hardware, and on most machines are on the order of no more than 1 part in 2**53 per operation. That's more than adequate for most tasks, but you do need to keep in mind that it's not decimal arithmetic, and that every float operation can suffer a new rounding error.
While pathological cases do exist, for most casual use of floating-point
arithmetic you'll see the result you expect in the end if you simply round the
display of your final results to the number of decimal digits you expect. For
fine control over how a float is displayed see the str.format() method's
format specifiers in Format String Syntax.
14.1. Kesalahan Representasi¶
Bagian ini menjelaskan contoh "0.1" secara terperinci, dan menunjukkan bagaimana Anda dapat melakukan analisis yang tepat atas kasus-kasus seperti ini sendiri. Diasumsikan terbiasa secara mendasar dengan representasi pecahan floating point biner.
Representation error refers to the fact that some (most, actually) decimal fractions cannot be represented exactly as binary (base 2) fractions. This is the chief reason why Python (or Perl, C, C++, Java, Fortran, and many others) often won't display the exact decimal number you expect:
>>> 0.1 + 0.2
0.30000000000000004
Why is that? 1/10 and 2/10 are not exactly representable as a binary fraction. Almost all machines today (July 2010) use IEEE-754 floating point arithmetic, and almost all platforms map Python floats to IEEE-754 "double precision". 754 doubles contain 53 bits of precision, so on input the computer strives to convert 0.1 to the closest fraction it can of the form J/2**N where J is an integer containing exactly 53 bits. Rewriting
1 / 10 ~= J / (2**N)
sebagai
J ~= 2**N / 10
dan mengingat bahwa J memiliki tepat 53 bit (adalah >= 2**52 tetapi < 2**53), nilai terbaik untuk N adalah 56:
>>> 2**52
4503599627370496
>>> 2**53
9007199254740992
>>> 2**56/10
7205759403792793
That is, 56 is the only value for N that leaves J with exactly 53 bits. The best possible value for J is then that quotient rounded:
>>> q, r = divmod(2**56, 10)
>>> r
6
Karena sisanya lebih dari setengah dari 10, perkiraan terbaik diperoleh dengan membulatkan ke atas:
>>> q+1
7205759403792794
Therefore the best possible approximation to 1/10 in 754 double precision is that over 2**56, or
7205759403792794 / 72057594037927936
Perhatikan bahwa sejak kami mengumpulkan, ini sebenarnya sedikit lebih besar dari 1/10; jika kita belum mengumpulkan, hasil bagi akan sedikit lebih kecil dari 1/10. Tetapi tidak dapatkah hal itu exactly 1/10!
Jadi komputer tidak pernah "sees" 1/10: apa yang dilihatnya adalah pecahan tepat yang diberikan di atas, perkiraan 754 double terbaik yang bisa didapatnya:
>>> .1 * 2**56
7205759403792794.0
If we multiply that fraction by 10**30, we can see the (truncated) value of its 30 most significant decimal digits:
>>> 7205759403792794 * 10**30 // 2**56
100000000000000005551115123125L
meaning that the exact number stored in the computer is approximately equal to the decimal value 0.100000000000000005551115123125. In versions prior to Python 2.7 and Python 3.1, Python rounded this value to 17 significant digits, giving '0.10000000000000001'. In current versions, Python displays a value based on the shortest decimal fraction that rounds correctly back to the true binary value, resulting simply in '0.1'.