- 세상의 모든 계산기 자유(질문) 게시판 일반 ()
손으로 세제곱근 계산하기? 도대체 왜 그러시는 건데요??
세제곱근을 손으로 풀어야 하나요?
"8의 세제곱근" 같은 것도 아니고, "1.392274 의 세제곱근"을 손으로 풀어야 한다구요?
왜죠? 도대체 왜 그러시는 건데요?
(핸드폰이나 컴퓨터에 있는) 공학용 계산기를 쓰면 되는 걸 알지만, 그걸 못쓰는 상황이라는 건데...
굳이 저런 상황이 왜 있는 건지? 모르겠지만...
여튼 일반 계산기도 없고 오직 손으로 풀어야 한다면,
그냥 못풀겠다고 하고 펜을 집어 던지시는게 좋습니다.
오차값이라도 제발 구해달라고 누가 사정사정한다면 그 때는 얘기가 좀 달라지겠지만요.
딱 떨어지지 않는 세제곱근의 근사값으로 계산하는 것은 그렇게 어렵지는 않습니다.
다음 과정만 잘 따라오시면 됩니다.
1. 정확한 해를 손으로 계산하는 것은 매우 어렵다.
- 고차방정식을 풀 때는 특히 손 계산으로는 해를 정확히 얻기 어렵다.
2. 손으로 계산할 때는 근사값으로 만족해야 한다.
- 근사 방법으로 빠르게 해를 구하고, 일정한 오차 범위를 허용하는 것이 현실적이다.
3. 이항 전개를 활용한 근사 계산
- \( (1 + r)^3 = 1^3 + 3r + 3r^2 + r^3 \)에서 \( +3r^2 +r^3 \) 는 \( r \)이 0에 가까울 때 무시할 수 있다.
- \( 3r^2 \)까지 포함하고, \( r^3 \) 만 버린다면, 오차는 줄어들겠지만, 제곱근을 손으로 또 구해야 하는 불상사가 생긴다.
- 어쩔 수 없이 2차항 3차항은 버려야만 한다.
- 따라서, \( 1 + 3r = 1.392274 \)를 풀어 간단한 근사 해 \(r = 0.130758 \)를 구해볼 수는 있다.
- 그런데, r=0.130758 이 0에 가깝다고 볼 수 있나?
4. 핵심은 \( r \)이 0에 가까워야만 이 논리에 의미가 있다는 것이다.
- \( r \)이 너무 크면 오차가 커져 근사 결과에 의미가 없어지므로, 매우 작은 \( r \)일 때 이 방법이 유효하다.
- 어떻게 r을 0에 가깝게 만들 것인가? 우리는 그 방법을 찾을 것이다. 늘 그랬듯이...
5. 이자율과 현실적 문제에서의 활용
- 이자율은 보통 5% 내외로 현실적으로 작은 값이기 때문에, 이를 바탕으로 사전 지식을 활용할 수 있다.
- \( 1.392274 \)는 \( 1.1^3 \)보다 크고 \( 1.2^3 \)보다 작다는 것을 (경험적으로) 감각적으로 알 수 있다.
- 아니면 최소한 앞선 과정3.에서 찾은 답이 r=0.130758 이니 제일 앞자리 0.1을 없애면 r이 0에 더 가까워지는 것 아니겠는가?
6. 더 정밀한 근사를 위해 수식을 변형해 사용
- \( 1.1 + r' \)을 기준으로 다시 전개하여 오차를 줄일 수 있다.
- \( (1.1 + r')^3 \approx 1.331 + 3.63r' \)로 고차항을 무시하여 전개 후, \( 1.331 + 3.63r' = 1.392274 \)을 계산하면, 훨씬 작은 오차로 근사값을 얻을 수 있다.
- 그렇게 찾은 r'=0.016879889807163 이고, 0.1 을 더해주면 더욱 더 근사해진 근사값 r = 0.116879889807163 을 얻는다.
이 방법은 계산량이 상대적으로 적고, 1차식으로 계산이 끝나기 때문에
직관적으로 \( r \) 값을 점점 더 작은 값으로 조정하면서 빠르게 근사값을 구할 수 있습니다.
더 정밀하게 다음 값을 구한다면
직전에 찾은 결과값에서 한자리 더 정확한 값을 선택해 0.12 또는 0.11을 빼고 r'' 를 계산해 볼 수 있겠습니다.
세상의모든계산기 님의 최근 댓글
예시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