계산기 사용시 (유효자릿수에 의한) 라운딩 처리 때문에 발생하는 오류 가능성, rounding errors
-
- 2024.09.13 - 07:50 2020.11.28 - 13:15 1963 10
출처 : HP-15C ADVANCED FUNCTIONS HANDBOOK (p.145)
ㄴ Appendix : Accuracy of Numerical Calculations
Example 2: Many Pennies.
A corporation retains Susan as a scientific and engineering consultant at a fee of one penny per second for her thoughts, paid every second of every day for a year. Rather than distract her with the sounds of pennies dropping, the corporation proposes to deposit them for her into a bank account in which interest accrues at the rate of 11¼ percent per annum compounded every second. At year's end these pennies will accumulate to a sum
where
payment = $0.01 = one penny per second,
i = 0.1125 = 11.25 percent per annum interest rate,
n = 60×60×24×365 = number of seconds in a year.
Using her HP-15C, Susan reckons that the total will be $376,877.67. But at year's end the bank account is found to hold $333,783.35. Is Susan entitled to the $43,094.32 difference?
In both examples the discrepancies are caused by rounding errors that could have been avoided. This appendix explains how.
The war against error begins with a salvo against wishful thinking, which might confuse what we want with what we get. To avoid confusion, the true and calculated results must be given different names even though their difference may be so small that the distinction seems pedantic.
번역 ChatGPT-4o
출처: HP-15C 고급 기능 설명서 (p.145)
ㄴ 부록: 수치 계산의 정확도
예제 2: 많은 페니.
한 기업이 Susan을 과학 및 엔지니어링 컨설턴트로 고용하면서, 1년 365일 24시간의 매 초마다 그녀의 상상에 대해 1 페니를 지급하기로 한다. 기업은 Susan이 떨어지는 동전 소리에 방해받지 않도록 그녀에게 지급할 돈을 은행 계좌에 예치할 것이며, 그 계좌에는 11¼ 퍼센트의 연이율로 매초마다 복리 이자가 붙는다. 일 년 후 이 페니들은 다음과 같은 금액으로 불어날 것이다.
$$ total = (payment) × \frac {(1+\frac{i}{n})^{n}-1}{\frac{i}{n}} $$
여기서,
지급액 = $0.01 = 1 페니 / 1 sec,
i = 0.1125 = 연이율 11.25%,
n = 60×60×24×365 = 1년의 초 단위 수.
Susan은 그녀의 HP-15C를 사용해 총액이 $376,877.67 이 될 것으로 계산했다.
그러나 1년 후 계좌에 있는 금액은 $333,783.35 뿐이었다.
Susan은 $43,094.32 의 차액을 받을 자격이 있을까?
두 예제 모두 차이가 발생한 원인은 반올림 오류 때문이다. 이러한 오류는 피할 수 있었다. 이 부록에서는 그 이유를 설명한다.
오류와의 전쟁은 우리가 원하는 것과 얻는 것을 혼동할 수 있는 비현실적 기대를 겨냥한 포격으로 시작된다. 혼란을 피하기 위해, 진정한 결과와 계산된 결과에는 구별된 이름이 부여되어야 하며, 그 차이가 너무 작아 보잘것없어 보일지라도 구분해야 한다.
HP-15C는 1982년 출시해 1989년 단종된 공학용 계산기입니다. 구형 기종이다보니 계산에 사용된 유효자릿수가 크지 않았던 듯 싶습니다(찾아보니 10 자리네요).
이 예제에서는 그래서 발생한 오차율이 무려 12.91% 에 달하는데... 이 정도면 (이 용도로는) 못쓴다고 봐야 맞을 겁니다. (항상 검산하고 있을 수는 없잖아요)
그러니 설명서 appendix에 이와 관련하여 오차가 발생할 수 있음을 강력하게? 경고하고 있습니다. 경고할 수밖에 없겠죠. 이 데이터를 그대로 썻다가는... 끔찍한 사태가 발생할 수도 있으니까요. 물론 이 예제는 좀 극단적인 계산에 해당한다고 할 수 있겠습니다만...
Round-Off Error As mentioned earlier, the HP-15C holds every value to 10 digits internally. It also rounds the final result of every calculation to the 10th digit. Because the calculator can provide only a finite approximation for numbers such as π or 2/3 (0.666…), a small error due to rounding can occur. This error can be increased in lengthy calculations, but usually is insignificant. To accurately assess this effect for a given calculation requires numerical analysis beyond our scope and space here! Refer to the HP-15C Advanced Functions Handbook for a more detailed discussion.
60p. Section 5: The Display and Continuous Memory. HP-15C Owner’s Handbook. 20Edition 2.4, Sep 2011
참고 : https://en.wikipedia.org/wiki/HP-15C
문제가 발생한 원인
i/n = 0.1125 / (60 × 60 × 24 × 365) 까지는 문제가 없었지만...
위의 값에 1을 더하는 순간 1 + i/n
화면 자릿수 표시 한계로 마지막 자릿수가 안보이니, 이 값에서 다시 1을 빼 보면
원래 이자율이 아니라 반올림된 "4" 가 남아 있습니다. 이자율이 달라진(올라간) 셈입니다.
요즘 계산기는 어떨까요? (feat. 울프람 알파)
https://www.wolframalpha.com/input?i=0.01*%28%28%281%2B%28%280.1125%29%2F%2860*60*24*365%29%29%29%5E%2860*60*24*365%29-1%29%2F%28%28%280.1125%29%2F%2860*60*24*365%29%29%29%29
= 333783.34994842833172198487646142620143147263335390407812403560738...
≒ 333783.35
-
25
댓글10
-
세상의모든계산기
TI-nspire CX (CAS)
오차 ≒ 4.78829, 오차율 ≒ 0.0014%
-
세상의모든계산기
TI-nspire CX (CAS) Finance Solver
오차 ≒ 0.000000002 오차율 ≒ 0%
단지 우연인지??
공식을 다른 (변형된) 걸 쓰나??
-
세상의모든계산기
HP 39gII
오차 ≒ 262.01175, 오차율 ≒ 0.0785%
-
세상의모든계산기
CASIO fx-570ES (Emul)
오차 ≒ -0.15815, 오차율 ≒ 0.0000474 %
* fx-991EX 결과 동일
-
세상의모든계산기
프로그램을 이용해서 순수하게 루프로만 계산
# 복리 계산 프로그램 # 매초 입금액: 0.01원 # 매초 이자율: 11.25%/(60*60*24*365) # 총 기간: 60*60*24*365 초 # 변수 초기화 deposit_per_second = 0.01 interest_rate_per_second = 11.25 / (60 * 60 * 24 * 365) / 100 total_seconds = 60 * 60 * 24 * 365 balance = 0 # 루프를 통한 복리 계산 for second in range(total_seconds): balance += deposit_per_second # 매초 입금 balance *= (1 + interest_rate_per_second) # 이자 적용 # 최종 잔고 출력 print(f"1년 후 최종 잔고는: {balance:.16f}원")결과 : 1년 후 최종 잔고는: 333783.3508975196164101원
더 정밀한 변수를 사용하면? getcontext().prec = 50
from decimal import Decimal, getcontext # Decimal의 정밀도 설정 getcontext().prec = 50 # 필요한 정밀도에 맞게 설정 # 변수 초기화 (Decimal 사용) deposit_per_second = Decimal('0.01') interest_rate_per_second = Decimal('11.25') / (60 * 60 * 24 * 365 * 100) total_seconds = 60 * 60 * 24 * 365 balance = Decimal('0') # 루프를 통한 복리 계산 for second in range(total_seconds): balance += deposit_per_second # 매초 입금 balance *= (1 + interest_rate_per_second) # 이자 적용 # 최종 잔고 출력 print(f"1년 후 최종 잔고는: {balance:.100f}원")1년 후 최종 잔고는: 333783.3511391508986042206488714749901779988494135500000000000000000000000000000000000000000000000000000000원 // getcontext().prec = 50
1년 후 최종 잔고는: 333783.3511391508986042206488714749901779987514741688945977231006921793358689473965341940033140160948000000원 // getcontext().prec = 100
-
세상의모든계산기
문득 루프로 돌리는게 정확할까? 공식에 넣어 계산하는게 정확할까? 궁금해 졌습니다.
처음에는 별 생각 없었는데(오차가 더 적을 거라는 기대가 있었던 것 같음)
생각해 보니 루프는 오차가 계속 누적되므로 루프 횟수가 많아질수록 오차가 커질 것 같음.from decimal import Decimal, getcontext # Decimal의 정밀도 설정 (100자리까지 계산) getcontext().prec = 100 # 변수 초기화 (Decimal 사용) deposit_per_second = Decimal('0.01') interest_rate_per_second = Decimal('11.25') / (60 * 60 * 24 * 365 * 100) total_seconds = 60 * 60 * 24 * 365 balance_loop = Decimal('0') # 루프를 통한 복리 계산 for second in range(total_seconds): balance_loop += deposit_per_second # 매초 입금 balance_loop *= (1 + interest_rate_per_second) # 이자 적용 # 공식에 맞는 정확한 계산 (fvaf) annual_interest_rate = Decimal('11.25') / 100 # 11.25% 연이자율 n = total_seconds # 총 복리 계산 횟수 (초 단위로 계산) fvaf = ((1 + annual_interest_rate / n) ** n - 1) / (annual_interest_rate / n) # 연금의 내가계수 공식 balance_fvaf = deposit_per_second * fvaf # 공식에 따른 미래 가치 # 결과 출력 print(f"루프를 통한 계산 결과: {balance_loop:.100f}원") print(f"공식에 따른 계산 결과: {balance_fvaf:.100f}원")루프를 통한 계산 결과: 333783.3511391508986042206488714749901779987514741688945977231006921793358689473965341940033140160948000000원
공식에 따른 계산 결과: 333783.3499484283317219848764614262014314726333539040781240356073844039099828033112644904100722067345000000원* 울프람 알파는 일단 결과로 보여지는 자릿수까지는 모두 공식에 의해 정확한 값을 보여주고, 【More Digits】 버튼을 누르면 그에 따라 정밀도를 높여 다시 계산하는 것 같습니다.
세상의모든계산기 님의 최근 댓글
- claude AI는 l-c*r^2 을 1-c*r^2 으로 잘못 읽고 표시하고 있습니다. - TI-nspire CAS 계산기에 l-c*r^2 ≥0 을 조건에 추가해 계산해 보아도 결과는 바뀌지 않습니다. 2026 07.20 ⚠️ 경고가 바로 두 번째 방법이 "성공"한 이유와 정확히 연결되어 있습니다. 경고의 의미 "Domain of the result might be larger than the domain of the input"는 CAS가 절댓값(모듈러스)을 계산하는 과정에서 원래 식보다 정의역이 더 넓은 형태로 단순화했다는 뜻입니다. 구체적으로 이 계산은 내부적으로 대략 이런 과정을 거칩니다. $$\left|\frac{er}{e\cdot r}\right| = \sqrt{\left(\frac{er}{e\cdot r}\right)\cdot\overline{\left(\frac{er}{e\cdot r}\right)}}$$ 즉 원래 식(복소수)과 그 켤레복소수를 곱해서 실수부·허수부 제곱합을 만들고, 거기에 다시 제곱근을 씌우는 과정입니다. 이 과정에서 √(x²) → x 또는 √a·√b → √(ab) 같은 규칙들이 쓰이는데, 이런 규칙들은 x가 실수이고 0 이상일 때만 엄밀하게 성립합니다. CAS는 이 조건들을 일일이 다 추적하지 않고 넘어가면서, 원래는 (e≠0, r+l·ω·i ≠ 0 등) 복소수 특유의 좁은 정의역을 가진 식을, r, l, ω가 어떤 실수여도(부호 무관하게) 정의되는 1/√(r²+l²·ω²)라는 더 넓은 정의역의 식으로 바꿔버린 것입니다. CAS는 이 손실을 감지하고 경고를 띄운 것입니다. 이게 왜 조건 대입 성공과 연결되는가 정리하면, 이 경고는 사실상 이런 뜻입니다. "나는 이 결과를 만들면서 원래 식이 가지고 있던 정의역 제약 정보(부호 조건, i 관련 조건 등)를 이미 버렸다." 바로 이 "정의역 정보를 버린" 상태가 이후 con_1 대입을 매끄럽게 만드는 원인입니다. 첫 번째 시도에서는 i가 살아있는 원래 식에 조건을 대입했기 때문에, CAS가 √(1-c·r²)이 실수인지(정의역 조건: 1-c·r² ≥ 0) 계속 추적하려고 했고, 그 정보가 con에 없어서 더 이상 정리를 못 하고 멈췄습니다. 두 번째 시도에서는 절댓값 계산 단계에서 이미 그런 세밀한 정의역 추적을 CAS 스스로 포기(단순화)했기 때문에, 이후 ω에 무리식을 대입해도 "이게 실수가 맞나?" 하는 검증 절차 없이 그냥 대수적으로 치환·정리해 버립니다. 그래서 깔끔하게 √c/√l이 나온 겁니다. 한 줄 요약 절댓값 계산 시 뜬 "정의역이 넓어졌을 수 있다"는 경고는, CAS가 그 순간에 원래 식의 엄밀한 조건(정의역)을 놓쳤다는 신호이고, 바로 그 "조건을 놓친 상태"이기 때문에 뒤에 이어지는 조건식 대입이 막힘없이 진행된 것입니다. 다만 그 대가로, 결과인 1/√(r²+l²·ω²)이나 최종 √c/√l이 원래 회로 조건(i≠0이 되는 경계, 분모가 0이 되는 경우 등)에서는 엄밀히 성립하지 않을 수 있다는 점은 감안하셔야 합니다. 실제 물리적으로는 r, l, c > 0이고 결과도 물리적으로 타당한 형태라 문제없어 보이지만, 수학적 엄밀성 측면에서는 "정의역이 넓어진 근사적 결과"라는 꼬리표가 붙어있는 셈입니다. 2026 07.20 Claude AI 답변 TI-Nspire CAS의 | (such that / 조건대입) 연산자는 대입 시점의 수식 형태를 그대로 두고 기호만 치환하는 연산입니다. 대입 후에 처음부터 다시 "실수부/허수부 분리, 유리화" 같은 재간소화를 자동으로 수행하지 않습니다. 이 차이가 지금 보신 결과 차이의 핵심입니다. 첫 번째 경우 (|er/(e·r)| | con_1 and con → 실패) 이 시점의 식은 아직 r + l·ω·i 형태의 복소수 그대로입니다 (i가 살아있음). 여기에 con_1: ω = √(1-c·r²)/(√c·l)을 대입하면, 분모 안에 i · √(1-c·r²) 라는 항이 새로 생깁니다. 문제는 CAS가 √(1-c·r²)이 실수인지(즉 1-c·r² ≥ 0인지) 판단할 근거가 없다는 겁니다. 저장해 두신 con 조건은 c>0, l>0, r>0뿐이고, 1-c·r²≥0이라는 조건은 포함되어 있지 않습니다. 그래서 CAS는 i와 이 무리식을 더 정리(유리화, 실수부·허수부 재결합)하지 못하고 있는 그대로 남겨둡니다. 결과에 여전히 i가 보이는 이유입니다. 두 번째 경우 (결과값 1/√(r²+l²·ω²)에 대입 → 성공) |er/(e·r)| (절댓값/모듈러스) 연산은 그 자체로 이미 "복소수 → 실수" 변환을 완료한 결과입니다. 즉 1/√(r²+l²·ω²)에는 더 이상 i가 없고, 순수하게 r, l, ω로만 이루어진 실수식입니다. 이 식에 ω = con_1을 대입하는 것은 그냥 실수 대수식에 실수 대입하는 것이므로, i와 무리식이 뒤엉키는 문제 자체가 발생하지 않습니다. 그래서 바로 깔끔하게 √c/√l로 정리됩니다. 정리하면 절댓값(모듈러스) 계산은 "이 값들이 실수다"라는 가정을 이미 내부적으로 써서 i를 제거하는 연산입니다. 그 연산을 조건 대입 이전에 해두면, 이후 대입은 단순 실수 대입이라 문제없이 정리됩니다. 반대로 i가 남아있는 식에 무리식을 포함한 조건을 먼저 대입하면, 그 무리식의 실수성/부호에 대한 가정이 없어서 CAS가 i를 소거하는 재간소화를 못 하고 멈춰버립니다. 실용적 팁: 복소식에 조건을 대입해야 할 때는 가능하면 절댓값·실수화(유리화) 등을 먼저 끝내서 i를 없앤 뒤 조건을 대입하거나, 대입 후 결과에 다시 simplify/expand/combine 같은 명령을 한 번 더 걸어주면 (필요한 도메인 조건과 함께) 정리가 되는 경우가 많습니다. 2026 07.19 저도 어림잡아 추측할 뿐이지 정확한 이유를 알지는 못합니다. 질문하신 사진을 그대로 (Gemini 3.5 Flash / ChatGPT / Claude Sonnet 5) AI에 넣어 보니 claude AI 가 제일 합리적인 답변을 주어서 이를 붙여 넣습니다. 2026 07.19 아 그렇네요. 감사합니다. ^^ 2026 04.28