14. 부동 소수점 산술: 문제점 및 한계
************************************

부동 소수점 숫자는 컴퓨터 하드웨어에서 밑(base)이 2인(이진) 소수로 표
현됩니다. 예를 들어, 소수

   0.125

는 1/10 + 2/100 + 5/1000의 값을 가지며, 같은 방식으로 이진 소수

   0.001

는 값 0/2 + 0/4 + 1/8을 가집니다. 이 두 소수는 같은 값을 가지며, 유일
한 차이점은 첫 번째가 밑이 10인 분수 표기법으로 작성되었고 두 번째는
밑이 2라는 것입니다.

불행히도, 대부분의 십진 소수는 정확하게 이진 소수로 표현될 수 없습니다
. 결과적으로, 일반적으로 입력하는 십진 부동 소수점 숫자가 실제로 기계
에 저장될 때는 이진 부동 소수점 수로 근사 될 뿐입니다.

이 문제는 먼저 밑 10에서 따져보는 것이 이해하기 쉽습니다. 분수 1/3을
생각해봅시다. 이 값을 십진 소수로 근사할 수 있습니다:

   0.3

또는, 더 정확하게,

   0.33

또는, 더 정확하게,

   0.333

등등. 아무리 많은 자릿수를 적어도 결과가 정확하게 1/3이 될 수 없지만,
점점 더 1/3에 가까운 근사치가 됩니다.

같은 방식으로, 아무리 많은 자릿수의 숫자를 사용해도, 십진수 0.1은 이진
소수로 정확하게 표현될 수 없습니다. 이진법에서, 1/10은 무한히 반복되는
소수입니다

   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

이것은 대부분 사람이 유용하다고 생각하는 것보다 많은 숫자이므로, 파이
썬은 반올림된 값을 대신 표시하여 숫자를 다룰만하게 만듭니다

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

이것이 이진 부동 소수점의 본질임에 주목하세요: 파이썬의 버그는 아니며,
여러분의 코드에 있는 버그도 아닙니다. 하드웨어의 부동 소수점 산술을 지
원하는 모든 언어에서 같은 종류의 것을 볼 수 있습니다 (일부 언어는 기본
적으로 혹은 모든 출력 모드에서 차이를 *표시하지* 않을 수 있지만).

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

이진 부동 소수점 산술은 이처럼 많은 놀라움을 안겨줍니다. "0.1"의 문제
는 아래의 "표현 오류" 섹션에서 자세하게 설명합니다. 부동 소수점의 위험
은 다른 흔히 만나는 놀라움에 대해 더욱 완전한 설명을 제공합니다.

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. 표현 오류
===============

이 섹션에서는 "0.1" 예제를 자세히 설명하고, 이러한 사례에 대한 정확한
분석을 여러분이 직접 수행하는 방법을 보여줍니다. 이진 부동 소수점 표현
에 대한 기본 지식이 있다고 가정합니다.

*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)

를

   J ~= 2**N / 10

로 다시 쓰고, *J*가 정확히 53 비트(``>= 2**52`` 이지만 ``< 2**53`` 다)
임을 고려하면, *N* 의 최적값은 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

나머지가 10의 절반보다 크므로, 가장 가까운 근삿값은 올림 해서 얻어집니
다:

   >>> q+1
   7205759403792794

Therefore the best possible approximation to 1/10 in 754 double
precision is that over 2**56, or

   7205759403792794 / 72057594037927936

올림을 했기 때문에, 이것은 실제로 1/10 보다 약간 크다는 것에 유의하세
요; 내림을 했다면, 몫이 1/10 보다 약간 작아졌을 것입니다. 그러나 어떤
경우에도 *정확하게* 1/10일 수는 없습니다!

따라서 컴퓨터는 결코 1/10을 "보지" 못합니다: 볼 수 있는 것은 위에서 주
어진 정확한 분수, 얻을 수 있는 최선의 754 배정밀도 근삿값입니다:

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