아니... 원(회전)에서 왼쪽방향 오른쪽방향이 있다니
-
- 2024.02.04 - 19:27 2024.02.04 - 07:09 1232 1
1. 논란
원의 회전을 얘기할 때
왼쪽방향 회전/오른쪽방향 회전에 대한 논란이 있음을 알게 되었습니다.
https://r1.community.samsung.com/t5/%EA%B0%A4%EB%9F%AD%EC%8B%9C-s/%EC%95%84%EB%8B%88-%EC%9D%B4%EA%B2%8C-%EC%99%9C-%EC%99%BC%EC%AA%BD-%EC%98%A4%EB%A5%B8%EC%AA%BD%EC%9D%B4%EC%97%90%EC%9A%94/td-p/197365
2. 논란을 알기 전 나의 인식
원의 회전에 대해서는
시계/반시계 방향에 대해서만 배웠고,
논리적으로 그게 당연히 맞다고 생각하였기 때문에,
왼쪽/오른쪽 방향이라는 일반적 인식이 있을 거라고는 생각도 못했습니다.
3. 왜 왼쪽/오른쪽이 쓰이는 걸까?
그런데 그게 아니었나봅니다.
생각보다 많은 사람이 왼쪽방향=시계방향, 오른쪽방향=반시계방향이라고 생각하고 그렇게 쓰고 있나 봅니다.
기존에 가지고 있던 인식과 너무 괴리가 커서 왜 그럴까 생각해 봤는데요...
도저히 답이 안나오더군요.
본문 처음에 예시로 들었던 '스마트폰 사진'의 경우에는
곰곰히 생각해 보니
회전이라는 요소가 있긴 하지만,
사진/핸드폰은 사각형인데다가, 사진 내용상 위/아래가 명백히 구분되는 경우가 대부분이며
핸드폰 사용 특성상 손으로 핸드폰 아랫쪽(바닥)을 잡고 사용하고 돌릴 것이기에
↙반시계=왼쪽 vs 시계=오른쪽↘ 이 상당 부분 이해가 가더군요.
그럼에도 불구하고 사진의 경우가 아닌 일반적인 원운동(rotation회전) 에서 왼쪽/오른쪽 회전은 왜 쓰이는지는
도저히 이해가 되지 않아 검색을 하다보니
위키에 "기준점이 없는 회전을 설명할 때 왼손법칙/오른손법칙을 쓰기도 한다" 는 내용이 있기도 한데...
https://ko.wikipedia.org/wiki/%EC%8B%9C%EA%B3%84_%EB%B0%A9%ED%96%A5
음... 봐도 말이 되는 건가 싶기도 하구요.
앞서 사진의 예에서 봤던 것과는 왼/오른 이 반대로 되어 있네요.
(사진에서는 ↙반시계=왼쪽 vs 시계=오른쪽↘)
이러면 더욱 더 미궁으로 빠져 들어가는데...
시계가 발명되기 전이라고 가정하고(=시계방향이라는 단어가 없음)
시계방향을
1 : 왼쪽 방향
2 : 오른쪽 방향
둘 중 하나로 하기로 투표로 결정한다고 하면 나는 어디에 한표를 던질까? 를 고민해 본다면
아... 몰랑
도저히 모르겠네요. 뇌정지 옵니다.
-
25
세상의모든계산기 님의 Recent Comment
V2 갱신 (nonK / K-Type 통합형) 예전에는 직접 코드작성 + AI 보조 하여 프로그램 만들었었는데, 갈수록 복잡해져서 손 놓고 있었습니다. 이번에 antigravity 설치하고, 테스트 겸 새로 V2를 올렸습니다. 직접 코드작성하는 일은 전혀 없었고, 바이브 코딩으로 전체 작성했습니다. "잘 했다 / 틀렸다 / 계산기와 다르다." "어떤 방향에서 코드 수정해 봐라." AI가 실물 계산기 각정 버튼의 작동 방식에 대한 정확한 이해는 없는 상태라서, V1을 바탕으로 여러차례 수정해야 했습니다만, 예전과 비교하면 일취월장 했고, 훨씬 쉬워졌습니다. 2026 02.04 A) 1*3*5*7*9 = 계산 945 B) √ 12번 누름 ㄴ 12회 해도 되고, 14회 해도 되는데, 횟수 기억해야 함. ㄴ 횟수가 너무 적으면 오차가 커짐 ㄴ 결과가 1에 매우 가까운 숫자라면 된 겁니다. 1.0016740522338 C) - 1 ÷ 5 + 1 = 1.0003348104468 D) × = 을 (n세트) 반복해 입력 ㄴ 여기서 n세트는, B에서 '루트버튼 누른 횟수' 3.9398949655688 빨간 부분 숫자에 오차 있음. (소숫점 둘째 자리 정도까지만 반올림 해서 답안 작성) 참 값 = 3.9362834270354... 2026 02.04 1. 분모 먼저 계산 400 × 10000 = 100 × 6000 = GT 결과값 4,600,000 역수 처리 ÷÷== 결과값 0.00000021739 2. 분자 곱하기 ×3 00 00 00 ×4 00 ×1 00 00 최종 결과 = 2,608,695.65217 2026 02.04 해결 방법 1. t=-1 을 기준으로 그래프를 2개로 나누어 표현 ㄴ 근데 이것도 tstep을 맞추지 않으면 문제가 발생할 것기도 하고, 상관이 없을 것 같기도 하고... 모르겠네요. 2. t=-1 이 직접 계산되도록 tstep을 적절하게 조정 tstep=0.1 tstep=0.01 도 해 보고 싶지만, 구간 크기에 따라 최소 tstep 이 변하는지 여기서는 0.01로 설정해도 0.015로 바뀌어버립니다. 그래서 tstep=0.02 로 하는게 최대한 긴 그래프를 얻을 수 있습니다. 2026 02.02 불연속 그래프 ti-nspire는 수학자처럼 연속적인 선을 그리는 것이 아니라, 정해진 `tstep` 간격으로 점을 찍고 그 점들을 직선으로 연결하는 'connect-the-dots' 방식으로 그래프를 그립니다. 여기에 tstep 간격에 따라 특이점(분모=0)이 제외되어 문제가 나타난 것입니다. seq(−2+0.13*t,t,0,23) {−2.,−1.87,−1.74,−1.61,−1.48,−1.35,−1.22,−1.09,−0.96,−0.83,−0.7,−0.57,−0.44,−0.31,−0.18,−0.05,0.08,0.21,0.34,0.47,0.6,0.73,0.86,0.99} t=-1 에서 그래프를 찾지 않습니다. 그 좌우 값인 −1.09, −0.96 두 값의 그래프값을 찾고, Window 범위를 보고 적당히 (연속되도록) 이어서 그래프를 완성하는 방식입니다. 그래서 t=-1에서도 그래프 값이 존재하는 것입니다. 2026 02.02