[0, 1, 2, 3, 4]
이와 같은 배열을 만드는 일은 IDL에서 매우 흔하게 발생하는 일입니다. IDL이 반복문을 쓰기 보다는 배열의 인덱스를 배열로 지정하여 처리하는 쪽을 독려하기 때문에, 그렇습니다. 예를 들면 이런 거죠.
|
1 2 3 |
x=['Nikon', 'Canon', 'Olympus', 'Pentax', 'Fujifilm'] for i=0, 4 do print, x[i] |
이렇게 반복문을 써서 배열의 요소를 하나 하나 뽑아내기 보다는, 다음과 같이 쓰는게 IDL 스타일입니다.
|
1 2 |
i=[0,1,2,3,4] print, x[i] |
여기서는 i 변수가 배열이고, x 라는 배열의 인덱스를 i 배열로 지정함으로써, 반복문을 대체하고 있습니다. 물론, 지금 이 상황은 배열 전체 요소를 추출해 내는 상황이므로, print, x 라고만 해도 됩니다만, 그쪽으로 관심을 흐트리지 말고, “배열기반 언어 IDL은 당연히 Index 배열을 생성하는 기능이 발달해 있을 것이다”라는 제 얘기를 들어 주시면 좋겠습니다.
i=[0,1,2,3,4] 같이 쓰는 것은 배열 요소가 다섯개 뿐이니까 가능한 얘기지, 배열 요소가 1000개, 10000개면 이렇게 쓸 수 없겠군요. 그래서 Index 생성 함수가 존재합니다. 말 그대로 INDex GENerator, 즉, INDGEN() 함수입니다.
|
1 2 3 |
IDL> i=indgen(5) IDL> print, i 0 1 2 3 4 |
INDGEN은 디폴트로 사용시 정수형(INT) 인덱스를 만들지만, 사실상 모든 데이터 타입의 인덱스를 생성할 수 있는 다양한 키워드를 가지고 있습니다.
|
1 2 3 4 |
IDL> print, indgen(5, /FLOAT) 0.000000 1.00000 2.00000 3.00000 4.00000 IDL> print, indgen(5, /BYTE) 0 1 2 3 4 |
그리고 이를 조금이라도 더 간결하게 작성할 수 있는 다양한 INDGEN 계열 함수가 존재합니다. FINDGEN 은 FLOAT 형, BINDGEN은 BYTE형, DINDGEN은 DOUBLE 형 등, 거의 모든 데이터 타입에 대해 함수가 따로 존재합니다. 현재, INDGEN 포함 총 12개의 함수가 존재하는군요. 그 중에는 L64INDGEN 같이 눈에 익숙하지 않은 함수도 있네요.
장황하게 썼지만, 사실은 IDL 사용자들은 너무도 흔히 사용하기 때문에 다 알고 있는 내용입니다. 우리말 문법을 구구절절 설명하는 장면 처럼 어색하네요. 오늘 하고자 하는 얘기는 이제 시작합니다.
IDL 8.3 버전 부터는 새로운 인덱스 생성 방법이 제공됩니다.
|
1 2 3 |
IDL> i=[0:4] IDL> print, i 0 1 2 3 4 |
콜론 연산자(colon operator)라고 하는데, Python 같은 언어에서는 일찌감치 이 방식을 이용했습니다. IDL은 8.3버전(2013년 말 출시)에서 이 문법을 처음 지원했습니다. 처음 나왔을 때 저는, 이 방식을 널리 권장하는 쪽은 아니었습니다. 바로 앞 버전(예를 들면, IDL 8.2)만 사용한다고 해도 당장 문법 오류로 처리해 버리니, 차라리, 몇 자 더 타이핑 하더라도 전통의 방식인 INDGEN 계열 함수를 쓰는 게 안전하다고 보았던 거죠. 그런데 이제 3년이 넘었고, IDL의 현재 버전은 8.6까지 올라갔습니다. 이제는 대부분의 IDL 환경에서 이 문법을 지원하는 상황이 되었다고 생각합니다.
INDGEN이나 콜론 연산자는 물론 1씩 증가하는 수열을 만드는 것이 기본 임무입니다만, 좀 더 다양한 활용이 가능하지요.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
;;; 1 에서 시작하는 수열 IDL> print, indgen(5) + 1 ;INDGEN은 디폴트로 0부터 시작하므로 Offset 1을 더해줌. 1 2 3 4 5 IDL> print, [1:5] ;콜론 연산자는 [시작:끝] 의 형태로 사용함. 1 2 3 4 5 ;;; 4씩 증가하는 수열 (1988년부터 올림픽이 개최되는 연도) IDL> print, indgen(4)*4 + 1988 1988 1992 1996 2000 ;Scale 4와 Offset 1988 지정 IDL> print, [1988:2000:4] ;콜론 연산자는 [시작:끝:간격] 의 형태로 사용함. 1988 1992 1996 2000 ;;; 2씩 감소하는 수열 IDL> print, 10-indgen(5)*2 10 8 6 4 2 IDL> print, [10:2:-2] ;간격을 음수로 지정 10 8 6 4 2 ;;; 참고) [시작:끝:간격] 에서 시작보다 끝이 작은 경우, 간격은 반드시 음수 IDL> print, [10:2:2] % Number of elements must be greater than 0. % Execution halted at: $MAIN$ ;;; 로그 스케일의 축 눈금값 생성 IDL> print, 10^indgen(5) 1 10 100 1000 10000 IDL> print, 10^[0:4] 1 10 100 1000 10000 ;;; Double 형으로 간격 0.3 IDL> print, dindgen(5)*0.3d 0.00000000 0.30000000 0.60000000 0.90000000 1.2000000 IDL> print, [0d:1.2:0.3d] 0.00000000 0.30000000 0.60000000 0.90000000 1.2000000 ;;; 참고) double 정밀도를 원할 경우, 간격값 역시 double 로 설정할 필요 있음. ;;; 간격을 0.3d 가 아닌 0.3 으로 설정하여 낭패를 보는 경우 IDL> print, dindgen(5)*0.3 0.00000000 0.30000001 0.60000002 0.90000004 1.2000000 IDL> print, [0d:1.2:0.3] 0.00000000 0.30000001 0.60000002 0.90000004 1.2000000 |
상황에 따라 여전히 INDGEN이 편한 경우도 있습니다. 수열의 개수가 명확한 경우는 INDGEN 계열이 더 편할 것이고, 시작과 끝이 명확한 경우에는 콜론 연산자가 더 편하겠네요. 두가지 문법이 모두 지원되니 상황에 맞게 편한 쪽을 선택하여 사용하면 되겠습니다.
마지막으로, IDL을 만드는 사람들이 INDGEN 계열 함수에 몰래 추가해 놓은 키워드가 있어 소개하겠습니다. START 와 INCREMENT 키워드… 몰래 추가해 놓은 것 맞죠? 위 예제들을 이 두 가지 키워드를 이용하여 구현하면 다음과 같습니다.
|
1 2 3 4 5 6 7 8 |
IDL> print, indgen(5, START=1) 1 2 3 4 5 IDL> print, indgen(4, START=1988, INCREMENT=4) 1988 1992 1996 2000 IDL> print, indgen(5, START=10, INCREMENT=-2) 10 8 6 4 2 IDL> print, dindgen(5, INCREMENT=0.3d) 0.00000000 0.30000000 0.60000000 0.90000000 1.2000000 |
START 는 IDL 8.2.1 버전부터, INCREMENT는 8.3 버전부터 추가되었다고 도움말에 명시되어 있으니 몰래 끼워 넣었다고 소송을 걸 수도 없겠네요.
제가 3년이 지나도록 START와 INCREMENT 키워드를 모르고 살아온 것은 전혀 부끄럽지 않습니다. 이미 곱하기와 더하기로 충분히 원하는 수열을 생성해 왔기 때문에 필요를 못느꼈던 것입니다. 그리고, 이제와 새삼 INDGEN 함수에 대한 도움말을 열어볼 기회는 사실상 없었습니다. 국어사전에서 ‘얼굴’이나 ‘하늘’ 같은 단어를 찾아볼 기회가 없는 것과 마찬가지 아닐까요. (제가 지금 변명을 하는 것 처럼 보이십니까? ^^)
일반적인 글을 쓸 때는, 표현의 단조로움을 피하기 위해 문장 형태나 사용되는 단어들을 일부러 바꾸어가며 반복되지 않게 쓰는 수사법이 있지만, 프로그래밍에서 같은 목적의 문장을 작성할 때는 같은 패턴으로 작성하는 것이 가독성을 높이는 옳은 방법입니다. 하나의 프로그램 안에서 위의 방법들을 바꾸어 가며 사용하는 것은 좋은 방법은 아닌 것 같습니다. 프로그래밍은 문학작품을 쓰는 일이 아니니까요. 다만, 상황에 따라 더 효율적으로, 더 편리한 방법을 사용자가 선택할 수 있게 되는 것, 그 자체는 거부할 이유가 없지요.