[공학용 계산기] 계산기의 가장 큰 수는? 자릿수 한계 (feat. 팩토리알)
-
- 2025.10.27 - 13:35 2015.08.14 - 14:11 2636 11
1. 계산기별 factorial 계산시 결과
| Factorial | ~69! | 70!~449! | 450!~1006! | 1007!~3248! | 3249!~ |
|---|---|---|---|---|---|
| EL-509W | O | X(Error 2) | X | X | X |
| fx-570ES, EX | O | X(Math Error) | X | X | X |
| fx-9860G | O | X(Ma Error) | X | X | X |
| TI-nspire, 89T | O | O | X(450!) | X | X |
| HP Prime | O | O | O | X(∞) | |
| 윈도우10 내장 | O | O | O | O | X(Overflow) |
* CAS 계산기인 HP Prime 이나 TI-nspire 와 같은 상급계산기는
정수에 한정하여 내부 유효 자릿수(14 digits)와 관계없이 가능한 한도 내에서는 자연수 결과(참값)를 유지하지만,
기타 공학용 계산기는 내부 유효 자릿수(보통 14자리) 이상이 되면 예외없이 참 값을 버리고
부동소숫점 형식으로 단순화해서 근사값으로 계산합니다.
* 참고
69! = 1.71122e+98
70! = 1.19786e+100
449! = 3.85193e+997
500! = 1.22014e+1134
1006! = 4.10908e+2585
1007! = 4.13784e+2588
2000! = 3.316275e+5735
3000! = 4.14936e+9130
3248! = 1.97363e+9997
50000! = 3.34732... × 10^213236
1. nspire에서 500! 이상을 이용한 계산은 표기만 될 뿐, 실제로 이루어지지 않음
2. 기존 윈도우 계산기는 그만둘지 물어보는 창이 나와도 백그라운드로 계속 계산하여 결국에는 계산이 되었지만, 지금(윈도우10)은 그냥 오버플로우 메시지만 띄움
2. 검증 (500! 계산시)
1) Wolfram Alpha
2) TI-nspire
ㄴ 입력한 ! 심볼을 그대로 결과에 표함시켜 표시되지만, 실제 계산이 불가능하며 오류가 유발됨.
3) HP Prime
계산도 되고, 저장도 되고, 연산도 잘 되는데...
지수형식으로 저장하면, 그보다 작은 수에서도 Inf (CAS 의 경우) 가 나옴.
-> 정수 저장공간(array)이 따로 설정되는 듯 하고,
지수 형식의 경우 Double Precision 제한 받는 듯 함.
-> Home 에서는 9.99999999999*E499 이상의 숫자 입력시 9.99999999999*E499 로 강제로 바뀜
-
25
댓글11
-
세상의모든계산기
울프람 신께서는 한계도 없는지 계속 결과를 뽑아내 주시는데... 맞는지 틀리는지 검증할 방법이 없어서 그만 뒀습니다.
의심은 불경한 짓인가?
-
세상의모든계산기
fx-570 ES 로 70! (근사) 값 구하기
1. 70! 을 직접 구하면
2. ln(70!)의 근사값을 구함
ln(70!) ≈ 70*ln(70) - 70 + (1/2)ln(2*π*70)
3. 즉, ln(70!) ≈ 230.4378531...... 인데, 소숫점 지수형식으로 변환하려면
이 값을 ln(10)으로 나누면 됨. (밑이 10인 상용로그로 바뀜)
ln(70!)÷ln(10) ≈ 230.4378531......÷ln(10)
log(70!) ≈ 100.077888
70! ≈ 10^(100.077888) = 10^100 × 10^(0.077888) 이므로
최종 결과로
1.196432005 ×10^(100) 을 얻게 됨.
1.197857166997×10^(100) 과 비교하면 오차가 크리 크지 않음을 알 수 있음.
-
세상의모든계산기
같은 방식으로 500! 근사값을 구해보면
1.219933487 × 10^(1134)
1.22013682599111006870123878542304692625357434280319284219241358838 × 10^(1134) (참값, 울프람 알파)
-
세상의모든계산기
중간값 오류 가능성
http://kin.naver.com/qna/detail.nhn?d1id=5&dirId=50105&docId=236207580&ref=me2lnk
(최종결과값은 계산기 한계 이내일지라도)
계산식 중간에 계산기 한계를 넘는 중간결과가 발생하면
최종 결과의 오류로 이어질 수 있습니다.
이런 경우에는 계산 순서를 적절히 조절하여 한계를 벗어나지 않게 하거나,
단위를 줄여서(?) 계산하는 등의 편법이 필요합니다.예시)
A = 9.11*10^(-31),
B = (1.6*10^(-19))^4,
C = (4π*(8.85*10^(-12)))^2,
D = (1.054*10^(-34))^2
-
세상의모든계산기
fx-9860GII 에서도 똑같은 증상
http://kin.naver.com/qna/detail.nhn?d1id=11&dirId=113111&docId=286373393 -
-
세상의모든계산기
계산기 설명서에는 계산기에서 사용 가능한 숫자의 범위가 나옵니다. 이를 통해 몇 펙토리알까지 계산이 가능할지도 추정해 볼 수 있겠지요.
└ fx-5800p 설명서 중 발췌 ┘ -
세상의모든계산기
'왜 1.79769313E+308 일까?'
https://stackoverflow.com/questions/22402885/why-is-number-max-value-1-7976931348623157e308-instead-of-9007199254740992e102
바드 AI 에 물어보니
삼성 갤럭시 계산기 최대값이 1.79769313E+308 이던데 그 이유가 뭐야?
삼성 갤럭시 계산기의 최대값이 1.79769313E+308인 이유는 IEEE 754라는 부동소수점 표준을 따르기 때문입니다. IEEE 754는 컴퓨터에서 실수를 표현하는 방식을 정의하는 표준이며, 이 표준에 따르면 **'double precision'**이라는 형식으로 표현되는 실수의 최대값은 1.7976931348623157E+308입니다.
이유:
2진수 표현: 컴퓨터는 모든 정보를 2진수로 표현합니다. 실수를 표현하기 위해서는 가수와 지수라는 두 가지 정보가 필요합니다. 가수는 실수의 값을, 지수는 실수의 크기를 나타냅니다.
정밀도: IEEE 754 표준은 'double precision' 형식에서 가수를 53비트, 지수를 11비트를 사용하여 표현합니다. 53비트는 약 16자리의 10진수 숫자를 표현할 수 있으며, 11비트는 -308부터 308까지의 지수를 표현할 수 있습니다.
최대값 계산: 'double precision' 형식에서 표현할 수 있는 최대값은 2^53 - 1 (가수의 최대값) * 2^308 (지수의 최대값)입니다. 이 값을 계산하면 1.7976931348623157E+308입니다.
참고:
'double precision' 형식보다 더 큰 값을 표현할 수 있는 'quad precision' 형식도 존재하지만, 이 형식은 모든 컴퓨터에서 지원되는 것은 아닙니다.
IEEE 754 표준은 실수를 표현하는 가장 일반적인 표준이지만, 다른 표준도 존재합니다.
결론:
삼성 갤럭시 계산기의 최대값이 1.79769313E+308인 이유는 IEEE 754 표준을 따르기 때문입니다. 이 표준은 컴퓨터에서 실수를 표현하는 방식을 정의하며, 'double precision' 형식으로 표현할 수 있는 최대값은 1.7976931348623157E+308입니다.
세상의모든계산기 님의 최근 댓글
ChatGPT-5 기호(÷, /, :) 자체는 의미적으로 같은 “나눗셈”을 뜻하지만, 문맥(사람이 쓰는 수학 vs 컴퓨터/프로그래밍)에 따라 해석 우선순위가 달라질 수 있습니다. 🔹 1️⃣ 전통 수학 표기 — ÷, /, : 수학 교과서, 논문, 일반 문서 등에서는 셋 다 의미적으로 “나누기”로 간주됩니다. 즉, 48÷2(9+3), 48/2(9+3), 48:2(9+3) 은 같은 의미로 받아들여야 합니다. 모두 사람의 수학 관행적 해석이 적용되어 48 ÷ 2 × (9+3) = 288 로 처리되죠. 즉, 기호가 바뀌어도 결과는 바뀌지 않습니다. 🔹 2️⃣ 컴퓨터·프로그래밍 문맥에서 / 사용 시 컴퓨터는 “생략된 곱셈(implicit multiplication)”을 따로 구분하지 못합니다. 따라서 다음 두 식은 완전히 다르게 인식됩니다. 표현 파이썬 등에서 해석 결과 48 / 2*(9+3) ((48 / 2) * (9+3)) 288 48 / 2(9+3) ❌ 문법 오류 (생략된 곱셈 인식 불가) — 즉, 컴퓨터 언어에서는 생략된 곱셈이 허용되지 않기 때문에, /는 반드시 명시적 *와 함께 써야 합니다. 🔹 3️⃣ “:” 기호의 경우 현대 수학에서는 “비율”을 나타내는 기호로 쓰입니다. a:b = \frac{a}{b} 따라서 (27 : 3(1+2)3) 같은 표현은 모호하거나 비표준적으로 간주됩니다. 대부분의 경우 계산기로는 입력 자체가 불가능합니다. ✅ 정리 기호 의미 결과 변화 주로 쓰이는 문맥 ÷ 나누기 없음 초중등 수학, 일반 표기 / 나누기 없음 (단, 프로그래밍에서는 생략 곱 불허) 수학/컴퓨터 : 비율 (또는 나누기 의미로 혼용) 보통 계산식에서는 사용 안 함 비, 비율 표기 🔹 결론 48 ÷ 2(9+3), 48/2(9+3), 48:2(9+3) 는 “수학적 의미”로는 동일하게 81로 해석됩니다. 하지만 프로그래밍이나 수식 파서(context) 에서는 /만 유효하고, 생략된 곱은 허용되지 않으며, :는 아예 다른 의미(비율)로 인식됩니다. 2025 10.28 ChatGPT-5 💯 네, 정확히 그 지점을 짚으셨어요. 요약하면 이렇게 말할 수 있습니다: “생략된 곱하기(implicit multiplication)”는 문자에서는 강한 결합력을 인정하지만, 숫자나 괄호 사이에서는 일반 곱셈(×)과 동일한 우선순위로 취급된다. 즉, 문자에서는 더 강하게 결합, 숫자·괄호 사이에서는 그냥 ‘보통 곱셈’ 으로 본다는 것이 현대 수학 표기와 계산기의 관행적 규칙입니다. 🔹 두 경우의 구조적 차이 식 형태 실제 해석 결과 결합력 특징 ab ÷ ab 문자 붙음 ((a×b) ÷ (a×b)) 1 문자 간 결합이 강함 → 한 항으로 인식 3(1+2)3 숫자·괄호 혼합 (3 × (1+2) × 3) 27 생략된 ×는 보통 곱셈 → 좌→우 규칙 적용 🔹 왜 문자식은 결합력이 더 강한가? 기호적 표현의 안정성 (ab), (xy), (2x) 같은 표기는 수백 년 동안 “하나의 곱셈 항(term)”으로 인식되어 왔습니다. 그래서 수학자들은 이걸 암묵적으로 “괄호로 묶인 덩어리”로 봅니다. ab ÷ ab = (ab) ÷ (ab) 함수 표기와 구분 필요 예: (sinx ÷ x) 에서 sinx는 sin(x)로 묶여야 의미가 있습니다. 이런 이유로 “문자 옆에 붙은 기호나 문자”는 항상 먼저 결합되도록 하는 관행이 굳어졌습니다. 🔹 반면 숫자·괄호에서는 (3(1+2)) 는 단순히 “3 × (1+2)”의 약식 표현이고, 여기서 “생략된 곱셈”은 “명시적 곱셈”과 동일한 연산자로 간주됩니다. 따라서 27 ÷ 3(1+2)3 = 27 ÷ 3 × 3 × 3 = 81 처럼 좌→우 순서로 처리합니다. 🔹 결론 생략된 곱하기(implicit multiplication)의 결합력은 표기 맥락에 따라 다르다. 문자/기호와 함께 쓰일 때 → 강하게 결합 (하나의 항으로 인식) 숫자와 괄호 사이 → 일반 곱셈과 동일한 우선순위 (좌→우 계산) 이건 “규칙이 바뀐 것”이 아니라, 표기 문법(context) 이 달라서 ‘결합 단위(token)’이 달라진 결과라고 보는 게 가장 정확합니다. 2025 10.28 자게로 이동조치하였습니다. 그리고 이 글의 내용을 정리하여 HP 포럼에 올려두었습니다. https://allcalc.org/55774 [HP Prime] Solve 함수 사용법 2025 10.27 수치해석 방법 method 를 강제로 선택할 수 있으면 좋을텐데... 위의 스샷을 보면 되는 듯 하면서도 아래 스샷을 보면 안되는 것 같기도 합니다. solve(Expr,[Var]) csolve(LstEq,LstVar) nSolve(Expr,Var,[Guess or Interval],[Method]) deSolve(Eq,[TimeVar],FncVar) linsolve(LstLinEq,LstVar) fsolve(Expr,Var,[Guess or Interval],[Method]) 2025 10.17 종합해서 답변을 드리면 HP Prime 에 solve 에서 변수명에 구간을 입력하면 수치해석 방식으로 bisection 을 사용함. 이 bisection 방식은 해의 좌-우 부호가 서로 바뀌어야만 해를 인식하고 해의 좌-우 부호가 같으면 해를 인식하지 못합니다. 이 때문에 본문 sin 의 예나 아래 사진의 예에서는 해를 인식하지 못하는 것으로 보입니다. 2025 10.17