Menu
Home
Home / Links / Resume
Photo
Photo
BBS
Writing / Programming
Salsa / Guestbook
Wiki
Home / NDS HomeBrew

Search

Calendar 2020/12
< 2020 / 12 >
  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

Calendar 2021/1
< 2021 / 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

Recent Comments
* https://www.cricketw...
* hi
* gkagm2@gmail.com 이...
*
* jkj,k
*
*
* Test
*
*
*
* 승익
*
* 일본어글자앱이요 껏...
* 죄송

Get XML
Articles RSS
Photos RSS
Wiki New Pages
Wiki Changes

Counter
Today: 23
Month: 1164
Total: 746456
Statistics

BBS
Board: BBS (407 Articles) Page 79 / 82 pages.



5. [Programming] by GyonG at 2005-05-19 20:27:31 from 210.91.42.253
음력 코드에 버그가!

예전에 음력 관련 코딩을 할 때 인터넷을 뒤져서 찾은 코드로 JScript 코딩도 하고 C 코딩도 하고 PHP 로도 포팅을 했었다. 그런데 알아보니 이 음력 변환 소스에 버그가 있었다.

음력(태음태양력)은 19년에 7번의 윤달을 넣는 방법으로 계절을 쫒아 가는데, 이것이 일정한 규칙이 없다. 어찌어찌 자료를 찾다 보니 계산법을 통해 대략적인 날짜를 구하는 공식을 찾았지만, 이것은 오차가 있는 계산법이다. 그래서, 현재 음력 날짜를 구하기 위하여 사용되는 코드는 모두 매 달마다 큰달(30일)/작은달(29일)의 정보와 어느 달이 윤달인지 저장하는 방법을 사용한다.

뉴스검색을 해 보니, 이 DB 에 문제가 있었던 모양이다. 그래서 작년에 한번 기사가 난 것 같은데, 2004년 11월 15일이 음력 10월 3일이라고 나오는 코드는 잘못된 DB 를 바탕으로 한 코드이다. 10월 4일이 맞다. 주위에 있는 폰들을 다 알아보니 제대로 나오는 폰이 절반 정도 된다.

또, 2006년 설날이 1월 30일(월)로 나오는 코드도 오류다. 1월 29일(일)이 맞다. 내년 설 연휴를 알아보는 사람이 생기면서 이 문제도 조만간 터질 조짐이다. 내년 설이 정확히 나오는 폰은 딱 한 개였고, 모두 월요일이 설날인 것으로 나왔다.

우리 회사에서 Application 을 만드는 JINOS 폰 (일명 CanU 시리즈) 은 작년에 이 버그를 알고 모두 패치 했다고 한다. (나는 아직 패치를 받지 못해서 아직 버그가 있다) 그리고, 지금 개발중인 (JINOS 가 아닌) 프로젝트에서도 업데이트된 버전을 써서 개발을 진행하고 있다.

불만인 것은, 이게 DB 를 바탕으로 하고 있다 보니 소스의 데이터 부분이 참 길다는 거다. 윤달이고 아니고 하는 정보를 기억하는 정도일 뿐인데 달마다 하나의 바이트(혹은 그 이상)씩을 차지하고 있다. 게다가 더 불만인 것은, 양/음 변환 부분인데, 계산 첫 날을 정해 놓고 그 날 이후 지금까지 흐른 날 수를 센 뒤에, 그 날만큼을 다시 음력 날짜에 더하는 방법을 사용한다. JINOS 에 사용된 소스는 약간 더 똑똑한데, 이것은 매 해 며칠인지까지 기억해 두어서, 매 달을 계산하지 않아도 되게 했다.

어차피 DB 로 찾는 것인데, 좀 더 다른 방법을 연구하면 어떨까 하는 생각이 든다. 예로, 현재 JINOS 코드에서 한 해에 대한 정보는 (1 byte x 13 달) + 2 byte 해서 총 15 byte 이다. 이 정보는 달별로 최소한의 bit 씩만 쓰는 경우 3 bit * 13 + 9 bit = 48 bit 면 모두 표현이 가능하다.

bit 계산을 좀 더 달리 하게 되는 경우 2 bit 로 줄이는 코드도 작성해 보았다. 이 경우 26 bit 로 모두 처리 되었다. bit 를 좀 더 아끼려면, 큰달/작은달 정보만 기록하고 윤달인 달과 그 달이 큰달인지 작은달인지를 별도로 저장한다면, 1 bit x 12 + 4 bit + 1 bit 는 17 bit 로 모두 처리된다.

데이터의 단위를 32 bit 로 하게 되면 자리가 좀 더 남으므로, 여기에 다른 정보를 더 저장할 수 있다. 예를 들면, 첫해부터 계산하는 짓을 하지 말고, 매 해 1월 1일부터 계산하면 좀 더 빠른 계산을 할 수 있다.

2005 년 1월 1일은 음력 2004년 11월 21 일이다. 이 2004년 11월 21을 저장하는 방법은 여러 가지가 있겠지만, 이것도 7bit 면 표현이 가능하다. 양력 1월 1일은 음력으로 하면 반드시 11월 아니면 12월이다. 따라서 11월이면 0, 12월이면 1 을 저장하는 bit 하나와 그 달이 윤달인지 여부를 저장하는 1 bit 가 필요하다. 연도는 반드시 1 작으므로 저장할 필요가 없다. 그리고 날짜는 1~30 까지이므로 5 bit 가 필요하여 총 7 bit 가 된다.

이 7 bit 와 앞의 17 bit 를 더하면 24 bit 가 된다. 이렇게 계산된 값을 2001 년부터 2010 년까지로 나타내면

0x4E9527,0x24052B,0x3A0A5B,0x54535A,0x2A0B6A,0x44FB54,0x1A0BA4,0x2E0B49,0x4CBA93,0x220A95,

와 같이 된다. 아, 위 코드는 버그 있는 데이터를 바탕으로 만들어진 거라서 2004년 11월과 2006년 1월 정보가 틀리다.

위 데이터를 바탕으로 매년 1월 1일이 음력으로 몇월 몇일인지 출력하는 코드를 만들어 보았다. 시간이 없어서 m 월 d 일을 변환하는 코드까지 만들어 보지는 못했다. 나중에 시간이 나면 좀 더 해 봐야겠다.

그리고, 한국천문연구원 (http://www.kasi.re.kr) 에 가면 양력/음력 변환을 해 주는 페이지가 있다. 이 곳의 정보는 정확하리라 생각하고, 이 곳의 서비스를 이용하여 나만의 DB 를 구축하기로 했다. 위에 계산된 데이터 중 2004년 과 2006년이 틀렸다는 것은 알겠는데, 어디가 더 틀렸는지 모르니까.

예전에 만들었던 HTTP 연결 코드를 변형하여 y 년 m 월 d 일 을 음력으로 변환하는 HTTP POST Request 를 만들고 그 결과를 parsing 하여 텍스트 파일에 저장했다. 무슨 에러인지, 중간에 프로그램이 죽어 버려서 완료되지 않은 파일들이 있지만, 밤새 돌려놓고 집에 갔다 오니 1391 년 부터 2050 년 까지의 모든 해의 음력 정보를 저장해 주었다. 이제 이 데이터를 가공해서 위에 있는 것 같은 코드를 만들고, 음력변환 코드를 완성하면, 양/음 변환 코드의 새 장을 열 수도 있을 것 같다 : )

그러나...

시간이 있어야 이 짓을 계속 할 수 있다. 바빠서 못 한다...
Name: Comment:

4. [Guestbook] by 이현경 at 2004-06-07 17:10:07 from 211.174.107.212
호... 이전에 이런 비슷한 페이지를 즐겨 찾았던 기억이 있는데, 오랜만이네.
사진 보다 보니 눈에 익은 스티로폴 조각이 있어서 눈을 크게 뜨고 봤음 ^^
종종 들러서 요즘 어떻게 사는지 구경해야겠구만~
Name: Comment:

4. [Salsa] by GyonG at 2004-06-08 11:53:58 from 218.153.77.97
박자라는 것은 교육이 가능한가?

요즘 나를 빠져들게 하는 명제이다. 음악을 하는 친구들에게 물어보면, 뭔가 가능해 보이기도 하는데 말이다.

바에 가서 사람들이 춤추는 것을 보고 있으면, 1/3 정도는 박자를 틀리고 춘다. 박자가 맞는 것 처럼 보이는 사람들 중 또 절반은 1과 5가 반대다.

한 마디(measure, bar)는 4박으로 이루어져 있고, 살사는 이 4박 동안 반박자에 한 count 씩 8 count 를 센다. 그 중 3 과 7 은 slow 스텝이라 4 와 8은 세지 않고 1,2,3, ,5,6,7, , 로 한다. (외국 교재 어딘가를 보면 123 456 라고 해서 헷갈리기도 한다)

곡을 듣다 보면 나는 카운트 1 을 세어야 할 곳을 안다. 그런데, 내 기억에 나는 이걸 교육받은 기억이 없다. 그냥 그렇게 들리는 것이다. 어쩌면, 나도 모르게 교육을 받은건지도 모르겠다. 친구는 쉬운 음악부터 들으면서 연습하면 가능하다고 하니, 일단은 그런가보다 하고 있기는 하다.

나는 살사를 추다가 내가 1과 5를 틀리고 있다는 걸 알아채면 리드를 제대로 하지 못한다. 뭔가 어색함이 몸을 감싸면서 몸을 굳게 만든다. 이럴 때는 4턴을 돌리면 좋다던가 방법을 몇가지 들었지만 나는 Hand Push break 를 두 번 연속 해서 굳이 1을 찾아 나간다.

곡을 좀 더 들어 보면, 대부분의 곡은 마디가 4개가 모여 한 줄이 되고, 8마디가 한 소절(소절은 마디와 같은 뜻으로 쓰이기도 하는데, 여기서는 곡의 한 덩어리라는 의미로 썼다. 쓸만한 용어가 생각이 안 나기 때문에)을 이룬다.

간단히 학교종으로 예를 들어 보면,

[학교종이][땡땡땡][어서모이][자]
[선생님이][우리를][기다리신][다]

[]로 묶은 것이 한 마디이고 네 마디가 한 줄이 되는데, 네 마디로는 계속 이어질 듯한 음으로 끝난다.(학교때 뭔가 용어를 배운 것 같기도 하다) 여덟 마디가 되어야 뭔가 완결된 느낌이 난다.

쉽게, 가요를 들어 보면서도 위와 같은 것은 찾을 수가 있다. 문제는, 모든 곡들이 이와 같이 8마디의 배수로만 이루어지지는 않았다는 것이다. 곡 중간에 4마디가 들어가기도 하고, 2마디, 1마디, 심지어는 반마디가 들어가기도 한다. 반마디가 들어가는 경우가 바로 살사에서 1과 5가 바뀌는 경우가 되겠다.

사실, 춤을 제대로 추려면, 1 과 5 를 틀리지 말아야 하는 것 외에도 위의 8마디를 맞추는 것도 중요한 요인 중 하나가 된다. Right Turn 같은 것은 8 count 하나를 사용하지만, 우리가 Pattern 이라고 배우는 것은 잘 보면 8 count 8 개가 사용되는 것을 알 수가 있다. 위의 8 마디와 상당히 관련 있는 얘기다. 즉, 8마디짜리 패턴과 곡의 8마디가 일치해 줘야 한다는 것이다. 간혹 끼어드는 마디들은 Basic 이나 Crossbody 같은 짧은 것들로 채워 나가면서 말이다.

작년 1월 공연 준비로 보아의 발렌티를 분석해 놓은 것이 좋은 예가 될 것 같다. 다음 링크를 보자

Valenti 분석

색깔이 바뀌면서 진행하는 막대기가 1 count 이고 한 줄에 두 마디씩 표현되어 있다. 잘 보면 8 카운트 8 개를 중심으로 여러 가지 변형 형태가 나온다.

그런데, 공연용으로 준비하는 것이 아닌 이상 플로어에서 위와 같은 춤을 구사하기는 쉽지 않다. 마디 구성을 완벽하게 이해하고 있는 곡들만 나오는 것도 아니고 (사실 거의 모르는 곡들이 나온다)

조만간 기회가 되면 박자 교습법을 (있다면) 좀 공부한 뒤에 동호회 사람들에게도 전파했으면 하는 소망이 있다.
Name: Comment:

4. [Writing] by GyonG at 2004-06-25 15:05:11 from 218.153.77.97
아.. 오늘은 월급날이다.
보낼 거 다 보내고 카드 결재 다 하고 났더니 10 만원 남았다.

이번 달도 10만원 가지고 쓰다가 모자랄 때부터 카드깡 들어간다...
Name: Comment:

4. [Programming] by GyonG at 2005-01-07 00:46:59 from 218.153.77.97
6개월 전에 C++ 예찬론을 썼었네.

작년 말부터는 새로운 프로젝트를 하면서 C++ 을 쓰고 있다. 즐겁다 : )
Name: Comment:

Go To Page [ 1 ... 74 75 76 77 78 79 80 81 82 ]