- TI nspire
[TI-nspire] 계산 결과의 분모에 허수(i) or 무리수(√)를 그대로 남겨두는 방법
-
- 2025.01.13 - 09:52 2015.11.15 - 21:01 5918 5
1. 분모의 유리화(Rationalisation) or 실수화(?)
[TI-nspire] 계산기는 '분자/분모 꼴'인 결과의 분모에 무리수(√)나 복소수(i)가 남아 있는 것을 싫어합니다.
ㄴ 다른 공학용 계산기들도 비슷합니다.
그래서 어지간하면 강제로 분모의 유리화 or 실수화를 진행합니다.
ㄴ 문자가 들어 있거나 해서 실수/허수 판단이 안되는 경우 등에는 진행되지 않습니다.
2. 문제의 발생
그 결과값이 상수인 경우에는 큰 문제가 되지 않으나, 미지수를 포함한 식인 경우에는 경우에 따라 아래처럼 문제가 될 수도 있습니다.
강제적인 유리화 또는 실수화 과정에서 (x-α)가 분모, 분자에 각각 곱해졌는데, 그 다음 계산에서 x=α 를 대입해야 하는 경우에는 분모가 0이 되고, 의도치 않게 결과값으로 undef 이 나옵니다.
결과적으로 쓸데없이 분모분자에 0을 곱해서 0/0 꼴을 만든 것과 같습니다.
3. 해결 방안
factor(Expr1[, Var]) ⇒ expression
cfactor(Expr1[, Var]) ⇒ expression
- 옵션인 ,var 값을 생략해도 괜찮을 수 있지만, 가급적 입력하는 것을 추천합니다.
- 무리수에서는 factor, 복소수에서는 cfactor를 사용하는게 모양상 바람직합니다.
복소수 변수일 경우에는 변수 뒤에 언더스코어바(_)를 붙여주는 것이 바람직합니다. - 위 명령으로 최종 수식을 감싸주면 분모가 더이상 유리화 또는 실수화되지 않고 그대로 출력됩니다.
- 위처럼 분모 위치에 묶여있는 상태에서 |x=α 조건을 붙여서 사용하거나, 결과값에 조건을 붙여서 계산하면 undef 문제를 해결할 수 있습니다.
☆ 반대로 유리화가 진행되지 않은 채 남은 다항식을 강제로 통분하려면 comDenom( ) 명령을 사용하시면 됩니다.
-
25
댓글5
-
세상의모든계산기
ㄴ "Var 값의 입력여부"에 따라 결과의 차이가 발생할 수 있습니다. -
세상의모든계산기
cfactor 함수와 ,var 변수의 조합에 따라 다양한 결과가 나옴을 알 수 있습니다.
눈에 보이는 계산에서는 실수를 바로 파악할 수 있지만, 결과값이 외부로 즉시 드러나지 않는 프로그램 내부에서 이런 문제가 발생하면 문제 파악이 어려울 수 있습니다. 여러가지 경우를 가정해서 미리 테스트 해보는 일이 필요합니다.
-
1
세상의모든계산기
cfactor의 도움으로 원하는 결과식이 구해지긴 하지만, x=α 를 결과식이 아닌 처음의 수식에 집어넣으면 답이 안나올 수 있습니다.
이런 경우에는 어쩔 수 없이 계산을 2단계로 나누어서 해야 합니다. (다른 방법이 있으면 제보 바랍니다)
-
세상의모든계산기 님의 최근 댓글
fx-570 CW 는 아래 링크에서 https://allcalc.org/56026 2025 10.24 불러오기 할 때 변수값을 먼저 확인하고 싶을 때는 VARIABLE 버튼 【⇄[x]】목록에서 확인하고 Recall 하시면 되고, 변수값을 이미 알고 있을 때는 바로 【⬆️SHIFT】【4】로 (A)를 바로 입력할 수 있습니다. 2025 10.24 fx-570 CW 로 계산하면? - 최종 확인된 결과 값 = 73.049507058478629343538 (23-digits) - 오차 = 6.632809104889414877 × 10^-19 꽤 정밀하게 나온건 맞는데, 시뮬레이션상의 22-digits 와 오차 수준이 비슷함. 왜 그런지는 모르겠음. - 계산기중 정밀도가 높은 편인 HP Prime CAS모드와 비교해도 월등한 정밀도 값을 가짐. 2025 10.24 HP Prime 에서 <Home> 73.0495070344 (12-decimal-digits) // python 시뮬레이션과 일치 <CAS> 21자리까지 나와서 이상하다 싶었는데, Ans- 에서 자릿수를 더 늘려서 빼보니, 뒷부분 숫자가 아예 바뀌어버림. 버그인가? (전) 73.0495070584718691243 (21-digits ????) (후) 73.0495070584718500814401 (24-digits ????) 찾아보니 버그는 아니고, CAS에서는 십진수가 아니라 2진수(bit) 단위로 처리한다고 함. Giac uses 48 bits mantissa from the 53 bits from IEEE double. The reason is that Giac stores CAS data (gen type) in 64 bits and 5 bits are used for the data type (24 types are available). We therefore loose 5 bits (the 5 low bits are reset to 0 when a double is retrieved from a gen). 출처 : https://www.hpmuseum.org/cgi-bin/archv021.cgi?read=255657 일단 오차를 놓고 보면 16-decimal-digits 수준으로 보임. 2025 10.23 khiCAS 에서 HP 39gII 에 올린 khiCAS는 254! 까지 계산 가능, 255! 부터는 ∞ fx-9750GIII 에 올린 khiCAS는 factorial(533) => 425760136423128437▷ // 정답, 10진수 1224자리 factorial(534) => Object too large 2025 10.23