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'.
