[공학용 계산기] 결과이상/에러 상황에서 확인할 것들. Check List
계산기 결과가 이상하다고 생각된다면 가장 먼저 계산기 초기화를 시켜보세요.
그래도 문제가 계속된다면 아래 내용을 하나씩 확인해 보시면 되겠습니다.
1. 각도 (Radian Vs Degree) 설정 확인
문제 원인
- ⓐ 각도 설정한 대로 입력하지 않음.
- ⓑ 각도 단위를 모름
확인할 내용
- 대부분의 공학용 계산기는 이 스샷처럼 현재의 각도설정값을 표시함 (D/R/G)
- 화면에 (각도단위) 표시가 없는 계산기라면 cos(90) 을 입력하여 계산
결과 = 0 이면 현재 Degree 모드
결과 = -0.44807... 이면 Radian 모드
결과 = 0.156434... 이면 Gradian 모드
참고 링크
- https://www.allcalc.org/4217 : 공학용 계산기의 각도설정
- https://www.allcalc.org/4813 : 각도의 단위 비교 설명
2. 괄호 ( ) 의 잘못된 사용 or 미사용
문제 원인
- ⓐ 괄호를 반드시 쳐줘야 하는데 빼먹음
- ⓑ 괄호의 쌍이 맞지 않음
확인할 내용
- "괄호를 더 쳐야 하는건가??" 의문스러운 부분에 모두 괄호를 쳐 보세요.
(삼각함수(각도의 앞뒤)) : sinx 는 sin(x)로, tan2(x) 또는 tan(x)^2 는 (tan(x))^2 로
(분모의 앞뒤), (분자의 앞뒤) : (a×b+1)÷2π 는 (a×b+1)÷(2π)로, 1÷2i 는 1÷(2i) 로
(지수)의 앞뒤 : 2^-3*π 는 2^(-3*π) 로
로그(진수) 의 앞뒤 - 특히 한줄로 식을 입력(Line IO)하는 경우에는 더욱 주의하여야 합니다.
- 괄호의 앞 뒤 쌍을 잘 맺어 주어야 합니다.
- 식이 길어 너무 복잡하다고 느껴지신다면 부분계산후 변수에 저장 ⇒ 변수를 이용해 계산하시면 편리합니다.
참고 링크
- https://www.allcalc.org/10629 : 괄호 이야기
- https://www.allcalc.org/8406 : 변수 메모리(부분계산 방법)
3. 잘못된 곱하기 생략 (Improper implied multiply)
문제 원인
- 생략하면 안되는 곱하기를 생략함 (일부 기종 한정)
확인할 내용
- [TI-nspire] 처럼 다문자 변수명이 가능하거나, 변수명과 함수명이 분리없이 사용된다면 주의하세요.
예) a(2+1)
(2+1)a 또는 a×(2+1)
참고 링크
- https://www.allcalc.org/10174 : [TI-nspire] 에러 : 잘못된 곱하기의 생략
4. 음수기호 (negative sign) 착각
문제 원인
- 음수부호(Negative Sign)를 써야 할 자리에 빼기명령(Subtract Operator)을 사용
확인할 내용
- 버튼안에 괄호【(-)】로 묶여서 표시된 것이 음수부호(Negative Sign)입니다.
계산기에 따라 다른 표시를 사용할 수도 있습니다. (+/- Neg) - 괄호없이 그냥 【－】 로 적힌 것은 빼기 명령 Subtract Operator 입니다.
- 잘 못 입력하더라도 상황에 맞게 자동으로 마이너스를 음수기호로 변환해주는 계산기도 있지만, 그냥 에러가 나는 계산기도 많습니다. 두개를 구분하여 사용해야 하는 이유입니다.
관련 링크
- https://www.allcalc.org/5876
5. 기타 설정의 확인
문제 원인
- 문제가 없는데 문제가 있는 것으로 착각
확인할 내용
- 설정상의 문제로 답이 원하지 않는 형식으로 표시될 수 있습니다.
예) 1.20130E-7 - 자릿수 문제나, 각도 문제, 좌표 표시 방법의 문제 등이라면 설정을 다시 확인하여 보세요.
참고 링크
- https://www.allcalc.org/2383 결과에 E가 뭐죠? ▶ 숫자(자릿수)의 표기법 Display Digits
6. 범위 (Limit) 한계
문제 원인
- 계산기 취급 한계를 벗어난 너무 크거나 너무 작은 수를 다룸
확인할 내용
- 계산기마다 한계(limit)값이 다르므로 설명서에서 반드시 확인하여야 합니다.
- 한계의 종류에는 최대한계, 최소한계, 유효자릿수 한계 등이 있습니다.
- 오류가 발생하면 오히려 좋은데, 오류인 결과를 문제 없는 결과인 것 마냥 표시하면 더 심각해집니다.
참고 링크
- https://allcalc.org/6925 [공학용 계산기] 계산기의 가장 큰 수는? 자릿수 한계 (feat. 팩토리알)
7. (허수나 자연상수 등) 기호 vs 알파벳 구분
문제의 원인
- 기호의 착각 : 복소수(i)나 자연대수(e) 등과 같이 특정 기호를 입력해야 할 것을 일반 알파벳으로 입력
확인할 사항
- 알파벳 【i】 혹은 알파벳 【j】 는 단순히 변수를 가르키는 문자일 뿐 허수 기호가 아닙니다.
- 알파벳 【e】 도 마찬가지로 자연대수가 아닙니다.
- 기호로 사용되는 문자는 알파벳과 달리 두껍거나 이탤릭체로(기울어져) 표시되는 경우가 많습니다.
8. 변수값의 영향 or (사용 불가능한) 예약변수명
문제의 원인
- ⓐ 이미 저장되어 있던 변수값이 영향을 미침
- ⓑ 잘못된 변수명을 사용함
확인 사항
- 변수에 다른 값이 이미 들어가 있는 것은 아닌지 확인하고, 가급적 변수를 초기화하여 사용
- 변수가 의심되는 경우 다른 변수로 바꾸어 사용
※ 원인 파악이 안되는 경우
수식을 최소 단위로 나누어서 부분부분 문제가 없는지 체크하시고, 문제가 없으면 부분을 조합하여 전체 식을 계산해보시는게 좋겠습니다.
-
25
세상의모든계산기 님의 최근 댓글
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