- TI nspire
[TI-nspire] 복소수 Complex number, 페이저 Phaser 관련 기본 입력 및 기능
1. 설정하기 (Document Settings)
복소수 관련하여 설정할 것은 다음 두가지 항목 입니다.
- Real or Complex Format : Real / Rectangular / Polar
- Angle : Degree / Radian / Gradian
복소수를 다뤄야 하기 때문에 1.에서 Real 로 두는 것은 바람직하지 않습니다.
ㄴ Rectangular(직교좌표) 또는 Polar(극좌표) 형식 중 하나를 선택해 주세요. (최종 결과값 형식에 영향을 미칩니다)
각도 설정은 디그리 / 라디안 중 주로 사용하는 것으로 결정하시면 됩니다만...
가급적이면 라디안으로 두는 것이 좋습니다.
아래 스샷처럼 세팅에 따라 결과값 형식이 딱 정해져 있습니다.
본인 취향에 맞게 세부 세팅할 방법은 없습니다.
2. 복소수 및 페이저 기호의 입력
※
입력 주의사항
ⓐ [TI-nspire] 에서 허수 기호 i 는 알파벳 키 로 입력하지 않고, 특수문자키
(혹은 카탈로그키
)를 이용해서 입력하여야 합니다.
ⓑ 교과서/문제집 등에서 사용하는 허수기호 j 는 공학용 계산기에서는 사용하지 않습니다. 허수기호는 i 입니다.
i →j 로 변수j에 복소수 i값을 저장한 후 j를 대신 활용할 수는 있긴 합니다만... 그렇다고 결과가 허수단위로서 j에 대해 정리되는 것은 아닙니다.
ⓒ 각도 기호 ∠ 는 (위에서 2번째줄)에서 찾아 입력합니다. (별도의 단축키는 없습니다)
∠ 기호를 이용한 극좌표 형식은 반드시 전체를 괄호로 묶어야만 합니다. (r∠θ)
- 자연대수 e : 【ex】 키나 특수문자키
조합으로 입력합니다. 알파벳 【e】 가 아닙니다.
3. 복소수 형식간 변환 (극좌표 vs 직교좌표)
▶Polar, ▶Rect 의 입력방법들 (아래 중 택1)
ⓐ 각각
▶Polar,
▶Rect
ⓑ 각각 (방향키 연타로 찾기)
(방향키 연타로 찾기)
ⓒ 【▶】 (변환기호) 찾아 입력하고 알파벳 키로 직접 입력 : 가능은 하지만 번거로움
- Degree 모드일 때 (Document Setting에서)
- Radian 모드일 때
4. 관련 함수

- abs()
- angle()
- conj()
- imag()
- real()
- P►Rx()
- P►Ry()
- R►Pθ()
- R►Pr()
5. 참고
댓글18
-
세상의모든계산기
허수기호(i) 나 자연대수기호(e)의 입력 빈도가 많다면,
1문자 알파벳(변수)에 저장하여, 대체입력하는 방법도 생각해 볼 수 있습니다. -
1
세상의모든계산기
극좌표 형식에서 arctan 로 답이 나오는 이유는 각도값이 무리수이기 때문입니다. (대부분의 경우)
근사값 형태로 강제 계산하시면 됩니다.
[TI-nspire] 계산 모드 : 근사값 vs 참값 Calculation Mode : Approx vs Exact
- 1
- 2
- 3
- 1
- 1
-
1
세상의모든계산기
복소수에서 가장 중요한 공식 중 하나는 오일러 공식입니다.
$ e^{i\theta} = \cos(\theta) + i\sin(\theta) $
좌변 $ e^{i\theta} $에서 θ는 단위가 '각도(degree)'가 아닌 그냥 실수(real number), 즉 라디안 값으로 해석되는 무차원수이며,
θ가 반드시 라디안(radian) 단위일 때만 정확히 성립합니다.
그렇기 때문에 $ e^{j(30˚)} $ 처럼 쓰는 것은 잘못된 기술입니다.
- 1
- 1
세상의모든계산기 님의 최근 댓글
예시11) 선형 연립방정식에서 답이 false 로 나올 때 https://allcalc.org/55823 2025 10.22 approx(참 해) 값이 이상하게 튀는 것 같아서 AI를 이용해 (python 으로) 구해보았습니다. * python 의 유효자릿수가 nspire 의 유효자릿수(14자리~15자리)보다 더 길기 때문에 시도하였습니다. ** 원래는 wolfram alpha 로 구해보려고 했는데, 울프람에서는 수식 길이가 너무 길다고 거부하는 바람에 포기하였습니다. 그 결과, AI approx(참 해) 값은 정상 범주에 포함되었고, 이는 solve()로 구한 대부분의 결과값과 유사하였습니다. 그럼 nspire 의 approx(참 해)는 왜 튀었나? 참 해에 더하기,빼기,곱하기,나누기 가 너무 많이 포함되어 있다보니, 모두 계산하고 나면 오차가 누적&증폭되어 버리는 것 같습니다. 그래서 오히려 solve의 numeric 한 접근보다도 더 큰 오차가 발생한 듯 하고, 그래서 적절한 해의 x 구간을 벗어나버린 듯 합니다. 그것이 처음의 solve 에서 false 를 이끌어낸 주 원인이 아니었을까요? (추정) 2025 10.21 그래프로 확인 그래프 함수로 지정하고, 매우 좁은 구간으로 그래프를 확대해 보면 불연속적인 그래프 모습이 확인됩니다. 이것은 한계 digits(15자리) 이상을 처리하지 못하기 때문일 것이구요. 다만 특이한 점은, 그래프상으로 교점에 해당하는 구간이 73.049507058477≤x≤73.049507058484 사이로 나오는데 -> 이 구간은 'solve에서 여러 방법으로 직접 구해진 해들'은 포함되는 구간입니다. -> 하지만, '참값인 해를 계산기로 구한 appprox 값 x=73.049507058547'은 포함되지 않는 구간입니다. 2025 10.21 tns 파일 첨부 sol_num_vs_exact.tns 2025 10.21 검증하면 1번 식을 x에 대해 정리하고, → 그 x 값을 2번 식에 대입해 넣으면 → 그 결과로 x는 사라지고 y에 대한 식이 되니, y에 대해 정리하면 참값 y를 얻음. 얻은 y의 참값을 처음 x에 대해 정리한 1번식에 대입하면 참 값 x를 얻음. 구해진 참값의 근사값을 구하면 x=73.049507058547 and y=23.747548955927 참 값을 approx() 로 변환한 근사값은 원래 방정식 모두를 만족할 수 없지만, linsolve() 로 찾은 근사값과, AI로 참 값을 근사변환한 값은 원래 방정식 모두를 만족할 수 있습니다. 2025 10.21