본래 쿼티자판덕분에 참 잘쓰던 모토쿼티인데, 사실 좀 느린감이 없지않아 있었습니다.
오늘자인지 프로요 업데이트가 나왔길래 바로 달렸습니다.
업데이트 후에 버벅버벅 하시길래 그냥 아무생각없이 공장초기화를 수행 했습죠;

애초에 포맷하려고 마음 먹었던지라... 아무 미련없이 질러주시고, 부팅하고 나니 신세계네요
공장초기화 방법 - http://blog.naver.com/PostView.nhn?blogId=ajg147&logNo=100116711177


1. 기본 런처도 꽤 빠르게 반응함

  이거 별거 아니지만 좀 충격입니다. 처음에 모토쿼티 부팅후에 버벅버벅 거리는 그 기본 런쳐를 보고 엄청난 실망감이 들었었는데, 이번엔 아니군요. 런쳐프로 깔았을때 느끼는 그 속도 수준으로 잘 움직여서 상당히 놀랐습니다;; 프로요빨인가요 뭔가요 이건;

2. 퀵오피스 업데이트

 겁나 후즐근했었던 관상용 퀵오피스가 업데이트하면서 확 달라 졌네요. 심지어 문서편집도 된다니...;;

3. 키보드 패턴 일부 변화

  이전과 달리 한영 전환이라던가, 하는 부분이 다르게 변했습니다. 물론 애초에 쿼티자판만 두들겨대던 인간인지라 전혀 관계 없었지만... 어쨌든 변했습니다. 편해진건지는 애시당초 써보질 않아서 모르겠습니다 -_-;;;;;

4. 일부 기본앱 추가

 뉴스와 날씨라는 게 생겼는데.. 음.. -_-ㅋㅋ 뭐 그냥 왜추가했는지 ;;;

어쨌든...
각설하고 많이 좋아졌습니다;
확실히 더 빠르고 좋은건 틀림없네요 ㅋ

그러면서 다시 런쳐프로를 깔아서 쓰고있습니다
더빨라졌어요! ㅎㅎ

P.S. 저만 그런가... -_- 왠지 모토롤라는 사실 좀 불안하네요;;


추가!

맞다.. 테터링이 생겼습니다 !
이걸 빼먹을뻔했군요!! 3G 모바일 핫스팟 이라는게 생겨서 뭔가 했더니, 스스로 AP 역할을 하게 해주는 것이더군요
이젠 PDANET 안쓰고 테터링할 수 있네요 ㅎㅎ
해보니까 PC에서도 인식 잘되고 아주아주 좋습니다 ㅋ
Posted by SHHyun
  CGP는 본래 논리 회로에 대해서 많이 사용되기 때문에, 별 관심이 없다가 최근에 몇가지 가능성을 보고 찾게된 이론이다. Linear GP 나 CGP 등 사실 Tree 기반의 GP 보다 구현이 쉽기 때문에 찾아보게 된 이유도 있다. 우선 기법에 대해 살펴보면 아래와 같다.

  기존의 Tree 기반의 Genetic Programming과는 약간 다른 Integer String 으로 개체를 구성한다. 하나의 개체는 아래의 그림과 같이 구성할 수 있는데,


  (1) (2) 는 입력을 의미하고, (3) 은 해당 노드의 연산자를 의미한다. 즉, 1, 2 로 부터의 입력을 3 의 처리를 거쳐 output 1 을 만들어내는 식인데, 이때 CGP 에서 출력은 사용자가 지정하는 것이 아니라 자동으로 지정되는 형태를 갖는다. 이는 CGP 가 Feedforward 형태의 흐름을 갖기 때문이며, Feedback 에 의한 루프 구성을 막기 위함이기도 하다. 만약 루프가 구성될 경우, 조건의 역할을 하는 함수가 아닐 경우, 이를 빠져나갈 방법이 묘연하여 무한 루프에 빠지게될 수 있고, 일정 횟수를 반복시킨다고 할 경우에 발생하는 효과는 오히려 루프를 이용하지 않는 것 보다 못할 수 있다.
  그리고 이러한 형태의 블록이 여러개가 다중으로 연결될 수 있으며, 아래와 같이 구성될 수 있다.



  이와 같이 여러개의 블럭을 사용하여 프로그램을 구성할 수 있으며, 점선으로 표시한 부분과 같이 연결이 이어지지 않는 부분도 발생할 수 있다. 이는 자동으로 할당된 출력이 다음 블럭의 어떠한 부분에도 연결되지 않는 경우 발생한다. 그리고 CGP 는 기존 트리기반의 GP 와 달리 항상 고정된 행과 열의 크기 만큼의 프로그램을 가지고 있는데, 초기에는 거의 모든 노드들이 연결된다. 그러나 시간이 지나면 지날 수록 이와 같은 연결되지 않는 부분이 발생하고, 이러한 작용에 의해 일종의 잉여 혹은 중복 공간(Redundancy)의 제거 효과가 나타날 수 있다. 
  CGP 는 위와 같은 다중의 형태로 인해 기존 GP와는 달리 단일 표현의 개체를 통해 다중의 출력을 얻어낼 수 있는데, 내가 이를 활용하게 된 이유는 바로 이것 때문이다. 기존의 로봇 게이트 진화에 사용했던 다중트리(Multi-tree) 기법은 서로 각각의 트리가 어떠한 관계도 없이 진화한다. 그러나 CGP 에서는 은연중에 서로간의 연결이 공유될 수 있기 때문에 완벽하게 독립된 형태가 아닌 어느정도 의존성을 갖는 형태로 진화하게 된다. 그러므로 각각의 관절의 움직임에 대해 기존의 GP 보다 효율적이며 유기적인 움직임을 보여줄 수 있을 거라고 기대할 수 있다.
  물론 멀티트리를 사용할 경우에도 이에 추가적으로 ADF(Automatic Defined Functions)를 적용할 경우, 비슷한 효과를 낼 수 있지만, ADF의 개수나 크기에 대한 정의를 어떻게 할 지가 큰 문제가 될 수 있다. 이 경우 크기와 개수가 커질 경우, 해공간의 크기가 매우 크게 확장될 수 있고, Koza 외의 다른 사람들이 ADF 를 잘 적용하지 않는 데에는 그만한 이유가 있다고 생각해볼 수 있다.
  그러나 CGP에도 단점은 있는데, 일반적인 GP에서는 ERC(Ephemeral Random Constants)라 하여 임의의 상수값이 트리의 어느 부분에나 적용될 수 있지만, CGP 에서는 그럴 수 없다. 제한된 입력값을 사용하기 때문에 발생할 수 있으며, 이 부분이 극복되지 않는 한 아래의 논문[1]에서도 언급한 것과 같이 Symbolic Regression 문제에 대해 완벽하게 적용되긴 어려울 것이다.
  그럼에도 CGP 는 하나의 표현으로 다중의 출력을 낼 수 있다는 면에서 충분히 매력적이다. 시뮬레이션 로봇 모델을 통해 실험을 하고 있으며, 기존의 GP 보다 더 빠르며 안정적인 보행 자세를 몇가지 얻어낼 수 있었다.

[1]       Miller J. F, Thomson P., Cartesian Genetic Programming, In Proceedings of the 3rd European Conference on Genetic Programming, Springer, LNCS 1802, 2000, 121-132.

(*) 위의 그림들은 논문에 사용될 그림이기 때문에, 만약 사용하신다면 반드시 코멘트를 남겨 주셔야합니다.

Posted by SHHyun
ReadyFor4GB 라는 프로그램을 사용해서 윈 7 32비트에서도 메모리를 4기가 모두 사용할 수 있는 것으로 알려져 있습니다.
4GB(3.11GB 사용가능) 과 같이 4GB를 쓰는데 왠지 4GB를 다 못쓰는것 같아서 좀 아까운 기분도 들고 저도 한번 사용해 봤는데, 부작용이 발생했습니다. 

Firewire 관련 부작용인데, PCMCIA Express 타입의 IEEE1394 카드에 Firewire 형태의 외부 카메라를 연결했는데, 인식만 되고 사용이 전혀 되지 않았습니다.

PC <-> IEEE1394 상의 데이터 전송 대역폭이 모자라서 데이터 전송이 불가능하다는 메세지가 계속 나타나더군요. 본래 잘 쓰던 카메라라 당연히 잘 될거라 생각했는데 안되니 좀 어이가 없었습니다. 원인을 한시간 가까이 찾아 헤메다가 이전에 쓰던거라 그 중간에 바꾼게 뭔가 찾아보니 ReadyFor4GB 설정 외에는 없더군요.

다시 본래 윈도우로 부팅해서 해보니 아무 이상없이 잘 됩니다. 이전에 어딘가 글에서 4GB(3.11GB 사용가능) 등의 메세지가 나타날때 나머지 공간이 나타나지 않는 이유가 사전에 장치를 위한 메모리 할당이라는 글을 본 거 같은데, 이런일을 겪어보니 왠지 그 이유가 아닌가 생각이 듭니다.

혹시라도 Firewire 형태로 연결되는 카메라를 쓰시는분이 문제가 생긴다면 한번쯤 의심해보셔도 될 것 같습니다.
Posted by SHHyun
이전에 간단하게 만들어두었던 SGA의 Fitness Evaluation 동작만을 CUDA 에서 실행하는 코드

난 지금까지 이걸 올렸다고 생각하고 있었는데, 다시보니 그게 아니었다.
이건 뭐 XX도 아니고...;;

(*) 일단 코드는 최적화는 전혀 되어 있지 않은 상태이며, 오히려 기본 GA보다도 Evaluation 성능이 떨어질 수 있다.

컴파일 환경은 쓰고싶은대로 아무거나 써도 이상이 없을 코드이며, 이전엔 Visual Studio 2008 에서 작업했었다.

CUDA에 대해서 가장 기본적인 코드라고 생각해도 될 코드이기때문에
혹시라도 이런 종류의 알고리즘을 다뤄보고 싶으신분은 살펴보면 좋을 것 같다.
Posted by SHHyun

로봇 게이트 생성 기법을 4족 보행 -> 휴머노이드로 이전하면서, 해공간의 특성 분석이 필요해서 몇가지 샘플트리에 대해 적합도 공간 변화가 어떤지 체크해본 그래프이다. 4족 보행 로봇의 경우 네 발로 지탱하는 특성 때문에, 안정성에 대한 지표가 크게 변하지 않지만, 휴머노이드는 넘어짐이라는 특성이 발생하기 때문에 아주 작은 변화에도 결과에 매우 큰 영향을 주는 현상이 나타날 수 있다고 생각했고, 그것을 증명하기 위한 그래프 자료이다.

아래와 같은 각각의 트리에서 ERC 값, 즉 실수값을 P1, P2, ... ,P8 의 변수로 표현하여, 각각 0.001 씩 증가시키면서 해공간의 변화를 나타낸 것이다. x 축은 0.001씩 몇번이나 증가 시켰는지를 의미하며, y 축은 적합도값을 의미한다.

HP:
 (/ (/ X -1.23399)
    (- X -0.34431))
KP:
 (/ (+ (sin 0.41949)
       (* -0.09291 X))
    (/ (cos 0.20874)
       (sin 0.41949)))
AP:
 (- -0.44653 -0.39964)

적합도 함수는 거리를 기반으로 한 형태이며, fitness = 0.8 * 전진거리 - 0.2 * 좌,우 틀어짐 으로 사용한다. 또한, 넘어지거나 유도한 방향으로 움직이지 않을 경우, 적합도를 0 으로 할당한다.


결과를 보면 실수값의 아주 미묘한 변화에도 해 특성이 매우 심하게 변동됨을 확인할 수 있다.
그러나 P5 변수 후반부를 보면, 크게 변동하지 않는 후반부(71~이후)가 발생하는데, 이는 조금은 의외의 결과이다. P4, P5, P6 모두 초기값이 양수이며, 동일한 형태로 증가하고, 최종적으로 증가된 결과가 시뮬레이터에 정밀하게 반영되기 어려울 수 있는데, P4, P6 는 중간에 적합도값이 음수값으로 크게 가라앉는 형태를 확인할 수 있다. 그러나 P5 에서는 71~이후 의 결과가 계속적으로 동일한 결과가 나타났으며, 생각과는 다른 해공간 특성을 가지는 것을 확인할 수 있다.

결론적으로 저러한 예외가 발생함에도 불구하고, 아주 미묘한 실수값에 의해 매우 큰 변동 수치의 적합도를 갖는다는 사실에는 변함이 없다. 즉, GP 자체의 구조적 튜닝도 매우 중요하지만, 이러한 문제의 경우 파라미터 수치의 중요성도 매우 높다는 사실을 확인할 수 있다.
Posted by SHHyun
내가 주로 연구하는 것은 최적화(Optimization)이다. 학습에 대해서는 분명 최적화만큼의 지식이 없으며, 이에 대해 여전히 상당한 혼란을 겪고 있음을 사전에 밝힌다.

최적화는 일반적으로 수학에서 많이 쓰이는 용어이며, 가장 대표적인 예로는 실수 최적화가 있다. 어떠한 주어진 함수 f(x) 의 최대 혹은 최소 값을 찾아내는 문제로서, 미분이 가장 대표적으로 사용되는 기법이다. f'(x) = 0 인 지점을 변곡점이라 하고, 이 변곡점들에서 최대, 최소값이 발견될 수 있다. 유전 알고리즘이나 진화 전략(Evolutionary Strategies) 혹은 PSO(Particle Swarm Optimization) 기법들 또한 이런 최적화를 위한 도구이며, 종종 최적화라는 이름으로 언급되곤 한다.

학습(Learning)이라는 이름으로 불리는 기법들이 있다. 일반적으로 최적화 라는 의미와 비교되는 것은 Machine Learning 에 대한 이야기 인데, 상당히 애매한 부분이 있다. 유전 프로그래밍(Genetic Programming)은 분명 최적화 기법이다. 그런데 어떤 의미로서는 Machine Learning 의 한 부류로 분류되기도 한다[각주:1]. 신경회로망(Artificial Neural Network)은 어떤 의미에서는 학습도 최적화도 아니라고 생각할 수 있다. 그것 자체로는 아무것도 할 수 없고, 이를 특정한 트레이닝 모델에 대해 "학습"을 시켜야 이를 하나의 알고리즘으로서 적용할 수 있다.

사실 학습과 최적화에 대한 경계에 대해 가장 큰 의문이 생긴 이유가 "신경회로망" 때문이다. 분명 신경회로망은 어떠한 학습 데이터에 대해 최적의 가중치값을 갖게 하기 위해 "학습" 이라는 과정을 수행한다고 한다. 문제는 여기서 발생하는데, 신경회로망의 대표적인 학습 방법으로는 오류역전파 알고리즘(BP, Back-Propagation)이 있고, 이는 특정한 트레이닝 세트에 대해 발생하는 오차를 앞에 있는 노드에 반영 시켜 해당 오차를 점점 줄여나가는 것이다. 그리고 LMA(Levenberg-Marquardt Algorithm)이 있는데, 이는 가우스-뉴튼 메소드의 확장으로서 Non-linear least square problem 을 해결하는데 사용한다.

바로 여기서 발생한 문제다. 분명 LMA 알고리즘은 Non-linear least square problem 에 대한 최소의 error 값을 찾아내기 위한 알고리즘이다. 또한, 이 알고리즘은 최적화 알고리즘의 성능 테스트에 대표적으로 사용되는 Rosenbrock Problem 을 해결하기 위한 방법으로도 사용된다. 그런데 이를 신경회로망에서는 학습 알고리즘으로 분류하기도 한다[각주:2].

분명 어딘가에선 "학습" 이라는 이름으로 불리고 있지만, 이것들이 엄밀히말하면 "학습"이라고 할 수 있을까? 만약, 위의 논문에서 사용하는 바와 같이 신경회로망의 "학습"을 위한 도구로서 사용된 알고리즘을 "최적화"라는 기법으로 말하지 않고, "학습"이라는 기법으로 소개한다면, 그렇다면 NEAT(Neuro-Evolution of Augmenting Topologies)와 같은 기법[각주:3] 또한 최적화라 분류하지 말고, "학습" 이라는 형태로 분류해야 하는가? (NEAT는 유전 알고리즘을 통해 신경회로망을 구축하고 가중치값을 조절하는 기법이다.)

학습이건 최적화건 본질적으로는 중요하지 않을 수도 있다. 어디까지나 내 생각이지만, 사람이 느끼기에 학습이라 불린다면, 어떠한 것이든 적응할 수 있을 것 같고, 인간이 학습한다는 것을 생각하기 때문에 보다 나은 어떠한 결과물을 만들어낼 것이라는 일종의 기대감 같을 것을 줄 수도 있다. 그런데 최적화라 한다면, 분명 이는 어떠한 특정한 환경에 대해 최적의 결과를 만들어낼 것 같은 기대감을 갖게 한다. 분명 하나의 기법에 대해 다른 용어를 사용해서 나타낸 것이지만, 이것이 적용될 환경에 대해 나타날 결과가 다르게 느껴질 수 있다는 것이다. 나만 그렇게 생각할 수도 있지만 말이다.

어쩌면 학습과 최적화라는 용어는 좀 더 명확하게 표기해야되는 것이 아닐까? 어떤것들은 어떠한 특정 목적에만 딱 부합될 수 있는 최적화의 접근방식인데도 학습이라는 표현을 사용하곤 한다. 물론 최적화 접근 방식인데도 학습이라는 용어를 쓰는데는 그만한 이유가 있겠지만, 이것에 대해 적용된 기법 자체에 초점을 두고 명확하게 표현하는 것이 좋지 않을까?

  1. http://en.wikipedia.org/wiki/Machine_learning 물론 위키의 신뢰성을 봤을 땐, 누군가 편집한 사람의 개인적인 의견일 확률도 높다. [본문으로]
  2. Bogdan M. Wilamowski, "Neural Network Architectures and Learning Algorithms, How Not to Be Frustrated with Neural Networks", IEEE INDUSTRIAL ELECTRONICS MAGAZINE, DECEMBER 2009. [본문으로]
  3. http://www.cs.ucf.edu/~kstanley/neat.html [본문으로]
Posted by SHHyun
GAlib 가 가볍고 잘 만든 Genetic Algorithm Library 인데

개발 중단된지도 오래되었고, 현재 최신버전의 컴파일러에서 컴파일은 되지만 링크가 되지 않는 문제가 있다.

http://www.hyperdrifter.com/software/tutorial/compiling_galib_using_microsoft_visual_cpp.html

위의 링크에서 말하는대로 컴파일하면 링크이상없이 잘 수행되는 것을 확인할 수 있고,

첨부된 파일은 귀찮고 단지 library 파일만 쓰고싶은 사람을 위한 것이다.

Posted by SHHyun

GP 의 해가 가지는 특성을 파악하기 위해 실험을 통해 대규모의 데이터를 수집하였다고 가정하자. 그리고 대부분의 해에서 나타나는 어떠한 특성이 발견 되었다면, 과연 여기서 대부분의 해는 반드시 그 어떤 특성을 갖게 되는 것일까?

GA, GP 의 조기수렴이 해의 다양성에 악영향을 끼치고, 좋은 결과로 수렴하는 것을 방해한다고 했을 때, 조기수렴을 막으면 반드시 해가 다양성을 폭넓게 가지면서, 좋은 결과로 수렴할 것인가?

어떠한 명제를 가정했을 때, 그 역이 반드시 참일것이라는 보장 같은 것은 없다. 결국 우리가 일반적으로 데이터를 수집하여 하는 일은 대부분이 그러한 특성을 보인다는 것에서 끝나는 것인데, 이것의 역을 증명해낼 좋은 방법은 없을것인가?

몇년째 계속 고민해보지만, GA, GP 쪽에서는 이를 어떤 수로 증명할 것인지 딱히 머리속에 떠오르는 것이 없다. 실험을 통해 명제 자체가 참임을 증명해낼 수는 있지만, 그 명제를 토대로 알고리즘을 구성하고 타당성을 갖기 위해서는 반드시 그 명제의 역이 참임을 증명해야 하는데 아직까지는 부족한게 많은지 딱히 좋은 방법이 떠오르지 않는다.

하지만 이 부분이 해결되지 않는 한, 결국 어떠한 알고리즘을 만든다 하더라도 이것이 타당성을 갖기는 어려울 것이 분명하기 때문에 앞으로도 계속 고민할 것 같다. 뭔가 좋은 방법은 없는 것일까?

Posted by SHHyun
병렬처리는 결국 필수 불가결한 요소가 될 것임에는 분명하다. 확실히 단일 코어 발전 대비 성능 비율이 언젠가부터 매우 낮아진다는 것을 확인할 수 있다. CPU 를 듀얼 혹은 쿼드로 쓰는 것도 꽤 매리트가 있지만, 알고리즘을 연구하는 사람으로써 그런 한 두개의 병렬을 가지고 큰 효과를 보기에는 그 한계가 명확하다.

결국 요래저래 살펴보다가 또다시 GPU 쪽으로 눈이 돌아가게 되었는데, 그 당시에는 그렇게 어렵게만 느껴지던 CUDA 라는 것이 그렇게 어려운 녀석이 아니었다.

일련의 흐름에 따라서 프로그래밍을 하면 되는데,

1. 디바이스의 초기화
2. GPU 상의 메모리 할당 ( cudaMalloc )
3. CPU 상에서 GPU 상으로 처리할 내용을 복사 ( cudaMemcpy )
4. 커널을 수행함으로써 원하는 연산 처리 ( function <<< blocks, threads, sharedmem >>> ( parameters ) )
5. GPU 상에서 처리된 내용을 CPU 상으로 재 이동 ( cudaMemcpy )
6. 할당했었던 메모리를 모두 해제 ( cudaFree )
7. 디바이스 종료

이러한 큰 흐름을 순서로 움직이면 된다.
얼마나 쉬운가?

마치 포인터를 처음 볼때의 그런 느낌이었다. 어라? 별거 아니네?
그런데 이놈도 포인터랑 똑같은 놈이더라. 결국 잘 쓰려고 하다보니 메모리 구조에 대한 것을 다시 확인해야 했다. CUDA 의 처리는 Block 단위의 다수의 스레드를 어떻게 관리하느냐, 그리고 이들이 처리될 때의 Shared Memory 를 잘 관리해 줘야 올바른 결과를 얻을 수 있고, 획기적인 병렬처리의 성능을 만끽할 수 있다는 것. 게다가 망할 포인터보다도 하나 더 많은 요소가 있었으니, Block 과 Thread 의 숫자를 결정해주는 것이다.

하지만 확실한 건 포인터와 마찬가지로 이놈도 쉽게 생각하면 될 것 같은 기분이 든다.
다음 번엔 SGA 에 Evaluation 과정을 CUDA 를 이용해 처리한 소스나 올려봐야 겠다. 아직 Thread 동기화에 문제가 있는지, 자꾸 마지막 변수값만 들어가는 현상이 발생하던데 요고만 해결하고 나서 하나씩 또 정리해봐야겠다.

Posted by SHHyun

#include <windows.h>

#include <math.h>

   

void wait(double sec)

{

unsigned int msec;

   

assert(sec > 0);

msec = (unsigned int) floor(sec * 1e3);

assert(msec >= 10);

Sleep(msec);

}

 

리눅스용 프로그램을 윈도우로 변환하다가 가끔씩 애를 먹었던 부분인데 ( 나만 그런지 모르겠지만…;;

윈도우에서 Sleep 함수는 저런 형태로 사용할 수 있다.

 

리눅스에서는

 

#include <unistd.h>

#include <math.h>

   

void wait(double sec)

{

unsigned int msec;

   

assert(sec > 0);

msec = (unsigned int) floor(sec * 1e3);

assert(msec >= 10);

usleep(msec);

}

 

단지 usleep (리눅스) -> Sleep (윈도우) 로 변경했을 뿐…

서로 호환 안되는 부분은 역시 짜증난다.

 

별 것 아니지만 자꾸 까먹는 관계로 정리를 =ㅠ=

Posted by SHHyun

로보틱스 시장을 선점하기 위한 각계의 노력이 이어지고 있는 가운데, 두각을 나타내는 프레임워크들이 속속 나타나고 있다.

 

대표적 로봇 프레임워크

MSRDS, OROCOS, RTC, OPRoS

 

MSRDS 는 아직 전폭적인 지원을 받으며 개발되고 있는 상태는 아닌것으로 보임

가장 큰 특징은 .NET Framework, Service Oriented Architecture, 즉 DSS, CCR 로 구분되는 Run-time 환경

 

ERSP - Evolution Robotics 사에 의해 모바일 로봇을 개발하기 위한 소프트웨어 플랫폼(상용임)

http://www.evolution.com/products/ersp/

 

OROCOS - 유럽 프로젝트, Component based Robot Software

http://www.orocos.org/

   

RT Middleware - 일본의 AIST 에서 주력

http://www.is.aist.go.jp/rt/OpenRTM-aist/html-en/FrontPage.html

   

OPRoS - 국내에서 개발중, 기존의 로봇소프트웨어 플랫폼에 비해서 매우 방대함

로봇, 내 외부를 모두 포괄하는 프레임워크

Thin Client Robot

Roboid Studio, OSGiFramework 기반 Action 이 Design 되고, Device map Protocol 을 통해 로봇에 전달

대부분은 로봇 내부에 집중되어 있는 것에 반해 서버, 평가기술이나 SE 도구 등 차이가 있음

아직 OPRoS 는 그 실체가 완전히 드러나지 않았는데, 8월 중에 공개한다는 이야기가 있음

 

사실 현재의 로보틱스 프레임워크들은 후에 열릴 로봇시장을 대비한 것들이지만, 과연 이것들이 로봇시장의 폭발력을 가져다 줄까?

내 생각에는 로봇을 도입함으로써 획기적으로 개선이 되는 것이 없다면, 시장의 폭발적 증가 같은 건 없을 것 같다.

Posted by SHHyun

이번에 이매진컵 임베디드 부분에서
U-Boat : Automated Navigation Boat for Water Inspection and Analysis
라는 작품으로 2차 라운드까지 진출한 U-Boat 팀의 메인 프로그래머랍니다 -_-
(대체 뭐임 이 병맛 소개는 ㄲㄲ)

네.. 저희 작품 그래도 한국대표 선발전에서 2위 했어요 ㅜㅜ (감격임 정말 -_-)

이매진컵이라는 대회를 처음 알게된 것이 작년 12월이었군요.
그때부터 참가를 한번 해볼까 망설이고 있었는데, 사실 작품의 아이디어가 안떠올라서 계속고민을 하다가 결국은 2월 초에 결정을 짓고 참가하게 되었습니다.

처음 1차 라운드 통과를 하게되어서 사실 긴가민가 하더군요.
통과는 할 수 있겠지라고 생각했지만, 워낙에 많은 학생들이 참여하는 대회라서 조금은 의심이 들었더랍니다.

어쨌든, 그렇게 1차 라운드를 통과하고 나서 E-BOX 가 왔는데... 이걸 할까말까 엄청나게 망설였거든요.
그 당시에 제가 하던일이 대규모 병렬처리용 유전 프로그래밍 프레임워크를 만들고 있던거랑 4족 보행 로봇의 제어기법인 GP 기반의 4족 보행 로봇 걸음새 생성 기법 과 CPG 의 실제 적용 및 비교라는 테마로 연구를 하고 있었기 때문입니다.

결국 대규모 병럴처리쪽을 잠시 접는쪽으로 가닥을 잡고, 4족 보행 로봇 쪽은 지속적으로 연구를 해가면서 동시에 정보처리기사 시험에 합격하는 바람에 실기 준비.... 후덜덜...

그리하여 2월부터 시작된 충분한 휴식없는 하루하루가 시작되게 되었습니다.

네... 그렇게 시간은 마구마구 가더군요.
그리고 2 라운드 진출자들끼리의 워크샵이 있었습니다.

사용자 삽입 이미지

(*) 한국 MS 의 서진호 차장님 블로그 갔다가 제가 발표하던 사진이 있더군요 -_- 앞에있는 저게 접니다;

이날은 정말 많이 놀랐습니다.
이번에 한국대표로 나가게된 Wafree (? 스펠이 맞는지 잘...) 팀에서 곤충을 식량으로 한 그런 계획에 대해 이야기를 들었을 때, 솔직히 좀 충격이었습니다. 만년 공돌이로 지내다보니 사실 이런 발상의 전환이 전혀 되지 않았던 탓일까요?
아이디어 자체가 워낙에 참신해서 도저히 할말이 없었습니다. 게다가 몇년씩 꾸준히 연구를 해오고 있다는 그... 신윤지님인가요.(제가 기억력이 워낙 안좋습니다.) 정말 많이 놀랐습니다. 지금와서 써놓지만 나중에 선발전에서 나이가 믿기지 않는다고 했던건 난 그나이때 뭘 생각했지 라는 생각이 들었기 때문이랍니다 -_-

그리고 휠체어에 RF기반의 안내 시스템에 대해 설명했던 M2I 팀이었나요? 사실 그당시에 조금 아쉬웠던건 휠체어 자체도 완전히 자동주행을 하는 시스템은 어떨까 라는 생각이었습니다. 그러나 아이디어 자체는 훌륭하다고 생각합니다. 분명 그런 부분이 도움이 될 수는 있다고 생각하거든요.

또, 24시간 건강 감시라고 해야하나 이런 것을 구상한 Rising Edge 팀도 아이디어는 참 좋았습니다. 문제는 실현 가능성과 소형화라고 생각했습니다만, 최대한 소형화하여 사실 몸에 칩으로 내장할 수 있다면 기계화에 대한 부담감이 존재하지만 귀찮음과 실시간 감시등 여러모로 좋은 아이디어가 아닐까 생각했습니다.

마지막으로 카풀 시스템을 보조해줘야 한다고 하나... Here Rose Season 2 팀의 발상도 놀라웠습니다. 그런 생각은 해본적이 없었거든요. 그런데 발상은 놀라웠지만, 사실 그자리에서도 그렇고 지금도 그렇고 카풀 시스템 자체가 혜택이 주어진다고 활성화 될 것인가에 대한게 계속 머리속에서 빙글빙글 맴돌고 있습니다.

저 외의 다른 여러 학생들은 어떤 생각을 가지고 있으며, 어떠한 발상의 전환들이 있는지 그런것들에 대해서 보게 된 것만으로도 사실 엄청난 충격이라고 할 수 있었습니다. 궁금하기도 했고, 기술 구현적인 측면에 대해서만 공부를 하다가 이런 아이디어들을 보니 정말이지 이 세상은 역시 넓다라고 생각했습니다.

제가 뭐 그렇게 사교성이 뛰어난 인간이 아니라 친하게 지내지는 못했지만 그래도 그때 봤었던 분들을 어딘가에서는 다시 뵙겠죠;;

워크샵때 여러모로 기술적인 하자나 이런것들에 대해 지적을 좀 받기도했고, 검토할 사항을 무지무지하게 늘려주셔서 고맙기도 했고... -_- 덕분에 2주라는 시간을 추가적인 검증에 투자해버렸습니다...;;;

그렇게 워크샵이 끝나고나서 다시 연구실로 돌아와서 좀 고민을 많이 했습니다.
과연 어떻게 진행하는 것이 이 짧은 시간안에 프로젝트의 프로토타입을 완성시킬 수 있을것인가?

기존부터 해오던 팀이 아니라면, 사실 이매진컵의 2차 대회의 주어진 시간이란 무지하게 짧은 시간입니다. 하나의 프로젝트를 1개월 반이 좀 넘는 시간안에 완성해야 하는 것이지요. 혹시라도 다음 이매진컵을 준비하시는 분들이 계신다면, 미리미리 준비하시는게 좋지 않을까 생각되네요.

사실 저희에게는 이 문제보다 더 큰 문제가 있었습니다. "자금" 이죠.
만드는 건 사실 문제가 아니었습니다. 문제는 자금이었습니다. 하고자 하는 일이 워낙 스케일이 크다보니 자금이 들어가는게 장난이 아닌데 이를 어떻게 수급할지가 최대 고민이었지요. 이 부분에서 역시 교수님께서 많이 도와주셨습니다. 물론 저희에 지원을 해주신 NT Research 분들도 정말정말 감사드립니다.

그런데도 추가적으로 또 하나의 문제가 생겼습니다. 수질측정용 센서들의 가격이었습니다... 이 부분은 솔직히 이렇게 비싸리라고 예상할 수 없었거든요. 결국 최소비용으로 프로토타입을 만들어야하니 pH Sensor 를 선택하였고, 이에 대한 당위성을 증명하기 위해서 수많은 자료를 또 찾아 해맸습니다. 다행히도 pH 자체가 완전한 수질 측정의 척도는 될 수 없지만, 상대적 척도로는 사용 가능하다라는 자료를 찾게되었습니다.

사용자 삽입 이미지OLYMPUS IMAGING CORP. | SP560UZ | Creative program (biased toward depth of field) | Pattern | 1/20sec | F/2.8 | 0.00 EV | 4.7mm | ISO-125 | Off Compulsory | 2009:05:16 15:59:21

(*) 결국 구매하게된 EGA133 무보충형 전극과 phidgets 사의 phSensor Interface 보드 입니다. Windows CE 6.0 드라이버 및 .NET Framework 용 Library 들을 제공해줘서 쉽게 작업할 수 있었습니다.

여차저차 해서 결국 RC 보트를 구매하고 보트의 개조에 돌입하게 되었습니다. 당초 스케쥴은 4월에 모든 제작을 끝내는 것 이었습니다. 그러나 자금 문제때문에 헤메이다 결국 5월 3일 정도가 넘어서야 모든 작업이 시작되었습니다.

이때부터 지옥이 좀 시작되었습니다. 아주 그냥 지옥도 아니고 생지옥 -_-;;;;;;;;
당초 한달을 기획했던걸 고작 2주 정도 안에 끝내야 했으니 말입니다... 물론 설계는 이미 끝나있었습니다. 그리고 MSRDS Compact Framework 를 통한 작업같은 것도 다 테스트 되었었죠. 해보고나니 워낙 딜레이가 커서 파기 해버렸지만... 어쨌든, 가장 시간이 많이 드는 작업은 이미 끝난 상태라서 구현만 남아있었는데, 이 구현이라는게 구현 중간에 나타나는 오류들을 생각하면 얼마나 시간이 걸릴지 예측할 수 없었던 상태였습니다.

참 다행히도 웹부분이 현재도 조금 불완전하지만, 보여주기 용으로는 충분히 모든 기능이 구현 되었습니다. 그리하여 웹 -> 임베디드 -> 웹과 임베디드시스템의 링크 -> 데이터 저장 및 전달과 같은 식으로 작업 순서가 진행 되었습니다.

이와 동시에 하드웨어의 제작도 들어갔습니다. 이 부분은 선배님들이 많이 수고해주셨습니다. 회로쪽이나 하드웨어쪽은 손이 좀 많이 가는 작업에다가 당초 예상대로 안될경우 무슨일이 생길지 모르기 때문에 상당히 애를 먹었습니다.

여차저차해서 결국 발표를 2주 앞두고, 프로토타입이 완성되고 제어 알고리즘의 검증을 위해 서경대학교 한림관 앞 코딱지 만한 폭포에서 테스트를 했지만, GPS 라는놈이 가지는 오차가 그리 만만한놈이 아니더군요;;
그정도 폭가지고는 택도 없는... 그런 오차라서 왕복테스트는 무리였습니다. 회전을 할 반경이 마련되지 않은탓에 직선거리에 대해서 편도로 몇일이나 테스트하고, 결국 한강으로 나갔습니다.

사용자 삽입 이미지OLYMPUS IMAGING CORP. | SP560UZ | Creative program (biased toward depth of field) | Pattern | 1/3sec | F/3.5 | 0.00 EV | 9.8mm | ISO-125 | Off Compulsory | 2009:05:18 19:10:52

  (*) 그렇게 만들어진 U-Boat Prototype 입니다. 참 조촐하지만 그래도 나름 깔끔하게 정리해두었습니다;

네... 그날의 한강은 지옥이었습니다. 비는 뭐가그렇게 많이 왔는지 물은 넘실대고 칠흙같은 어둠속에서 배의 실체를 알아보는건 참으로 어려웠습니다 -_-... 파도는 지가 강이라는 사실을 망각한것처럼 넘실대고 있고;;

그래도 일단 배니까 띄우자 라는 마음으로 띄웠습니다. 다행입니다. 배는 무사합니다. 그때 느꼈습니다. RC 보트가 그리 만만하게 전복되는 놈이 아니구나 -_-;;;;  그리고 그날은 그렇게 이런 환경도 버틸수 있다는거에 만족하며 돌아왔습니다. 제어는 안되더군요. 물살이 너무 쌘데 모터힘이 너무 약하다보니까 될리가 있나요?

그리고 며칠뒤 다른 장소를 물색해서 찾은 곳이 중랑천이었습니다. 사실 건대호수가 최적이죠. 그런데 역시 거긴 출입불가 상태라;; 결국 중랑천으로 향해서 모든 준비를 끝내고 그렇게 배를 띄웠습니다.

와우... 대성공입니다.

사용자 삽입 이미지

(*) 그렇게 중랑천의 수질측정을 하겠다고 헤집던 U-Boat 의 프로토타입 입니다 -_-

그런데 문제가 생겼죠. 혹시나 배를 잃어버릴지 몰라 묶어놓았던 낚시줄이.... 중간에 나무에 걸려버리는 바람에... 배가 갑자기 전진을 못하게 되었습니다 -_-;;;;;; 그래서 배를 되찾기 위해.... 저는 다리를 걷고 중랑천 한가운데에서 배를 건지고자 1시간정도 씨름한듯...

사용자 삽입 이미지

(*) 그렇게 대치 상태에서 멍하니 바라보던 저 입니다. -_-... 제기랄 -_-;;;

흑흑 -_- 그러나 성공이 더 감격 ^^
그렇게 테스트도 완료되고 무사히 수질측정도 잘 되었고, 결과물도 잘 남게 되었습니다.

그리고 또다시 며칠간 밤샘작업을 하며, 2차 라운드 최종 레포트 작업에 돌입하게되었습니다. 난 영어가 싫습니다 -_- 그리고 결국에는 한국대표선발전의 그날까지 다가오게 되었습니다.

2차라운드때 봤었던 분들이 다시 보이고, 어느덧 발표더군요. 그동안 준비했던것들 생각하면서 정말 열심히 발표했습니다. 전 원래 발표같은건 꽤 즐기는 편이라 재미있게 잘 즐겨줬습니다 -_-;;; (죄송합니다. 정신상태가 좀 이상해서...)

그런데 정말 다들 만들어 오셨더군요. 조금 어렵지 않을까 싶었던 분들도 완성하셨고, 결국 그렇게 다들 다시 모이게 되었습니다. 상상하던 그것들이 진짜 만들어져서 눈앞에 있다는 사실이 정말 놀라웠습니다. 그리고 이분들이 나와 경쟁하게될 분들이라는 사실이 뿌듯했습니다.

그렇게 발표가 진행되고, 결국 저희는 1위를 하지는 못했습니다. 역시 처음에 가장 강력하다고 생각했던 Wafree 팀이 1위를 하셨습니다. 사실 이 당시에는 축하해드리고 싶은 기분보다는 뭔가 아쉽다는 안타까움이 더 컸기때문에 축하한다고 말은 해 드렸던거 같은데, 참 뭔가 많이 아쉽더라구요. 뭐... 패자의 그런거니 이해해주심이;; 그러나, 확실히 그 아이디어는 정말 대단하다고 생각합니다. 좀 늦었지만 다시 축하드린다고 말씀드리고 싶네요.

이래저래 상당히 오랜 기간 진행되었던 대회였습니다. 덕분에 즐거웠던 것도 많고 힘들었던 것도 무지 많았지만, 무사히 프로젝트를 진행할 수 있었다는 것에 놀라웠고, 저희들이 가진 어떤 가능성에 대해 다시한번 생각해볼 수 있는 정말 좋은 기회였다고 생각합니다. 거기에 수많은 학생들이 이렇게 경쟁하고 있다는 사실이 긴장감을 더욱 주기도 했구요.

다음 대회에 참가할지는 사실 잘 모르겠습니다. 제가 뭘 하고 있을지 아직 예측할수가 없기 때문에 정확히 말씀드릴 수는 없지만, 그래도 만약 이런 기회가 다시 또 온다면 그때는 또다시 뭔가 새로운 도전을 하고 있지 않을까 싶네요.

다른 많은 분들도 이런 대회 많이 참가하셔서 재미있는 시간 보내셨으면 합니다.

무지 긴 후기였습니다 ㅡㅠㅡ
대한민국 만세;; Wafree 팀은 꼭 세계 1위 먹으세요 :)
Posted by SHHyun
http://www.shabdar.org/google-maps-user-control-for-ASP-Net-part1.html

http://www.codeproject.com/KB/custom-controls/LatLaysFlat-Part1.aspx

개인적으로는 위의 것을 더 추천한다.
훨씬 사용하기가 간단하고 수월하다는 이유 하나만으로.
아래쪽의 것은 더 체계적으로 잘 되어 있는 듯 싶지만, 사실 좀 복잡하다.

음...
이걸 찾아서 사용하게 된 이유라면
C# 이 왠지 손에 익숙해지기 시작했고,
작업속도가 C#을 쓰는것과 JAVA 를 쓰는것 중에 C# 을 쓰는것이 월등히 빨라졌기 때문이랄까...
거기에 Dreamspark 덕분에 공짜로 IIS 를 맘놓고 사용하고 있으니...

혹시라도 구글맵을 ASP.NET 으로 제어하기를 원하신다면, 위의 링크들을 따라가시면 도움이 될듯.

P.S. 아차차... 이 내용이 중요한데 빠졌군요. 위의 것의 목적은 말그대로 구글맵 자체의 제어고, 아래것의 목적은 Display 에 해당 하는 부분들 입니다. 즉, 동적으로 입력을 받아 이를 제어하기 위해서는 천상 위의 것이 낫습죠;; 아래 것은 또 수정해야하니;;
Posted by SHHyun
페도라 10 에서 네트워크 관리자에서 계속 DNS 재설정하는 현상이 발생하는분은 요렇게 해보시면 아마 해결될 것 입니다.

/etc/sysconfig/network-scripts/ifcfg-eth0
혹은 ifcfg-eth1
또는 ifcfg-개인이 지정한 프로파일 이름

위의 파일을 여시면

# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
GATEWAY=XXX.XXX.XXX.XXX
TYPE=Ethernet
DEVICE=eth1
HWADDR=XX:XX:XX:XX:XX:XX
BOOTPROTO=none
NETMASK=255.255.255.0
IPADDR=XXX.XXX.XXX.XXX
ONBOOT=yes
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=yes

이런식으로 구성이 되어 있을것 입니다.
여기다가 아래와같이 DNS 구성을 추가하신 후에

DNS1=168.126.63.1
DNS2=168.126.63.2
(*) 주소는 평상시에 쓰시는 DNS 를 입력해주시면 됩니다.

저장 하시고 터미널에서

service network restart

그 후부터는 DNS 재지정없이 잘 될 거예요. :)

무...물론 안될수도 있습니다 -_-
저의 경우는 이렇게 해결 했습니다 ^^;

Posted by SHHyun
1. 개요

병렬처리 시스템은 최근에 가장 주목 받고 있는 컴퓨팅 성능 향상 기술 중에 하나입니다. 물론 과거에도 병렬처리 시스템이 주목 받아 왔지만, 그 당시에는 CPU 의 업그레이드 만으로도 50%, 100% 이상의 성능향상을 이룰 수 있었기에 지금보다는 적은 관심을 보였었습니다. 그러나 현재의 CPU 가 가진 한계에 거의 다다름에 따라, 성능 개선의 기법으로 병렬처리 기법들이 주목을 받고 있습니다. 즉, 하드웨어적 한계를 소프트웨어 적인 기법으로서 넘어서려고 한다고 표현할 수 있겠습니다.

이 병럴처리 시스템은 크게 내부, 외부의 두 가지 요소로서 존재한다고 볼 수 있겠습니다. 내부 요소로서는 CPU 의 멀티 코어화, GPU 의 발전 등을 들 수 있겠고, 외부적으로는 대규모 네트워크로 구성된 컴퓨팅 환경을 제공하는 것이 되겠습니다. 대표적으로는 근래에 각광을 받고 있는 클라우드 컴퓨팅이 있겠습니다.

진화연산은 기존의 알고리즘 들에 비해 엄청난 반복작업이 필요하며, 거대한 리소스를 갖출수록 더 좋은 효과를 가질 수 있는 특징이 있습니다. 이 거대한 리소스에 대한 것은 반박의 여지가 충분히 존재하며, 각 문제에 따른 특화된 알고리즘의 적용으로 이를 개선할 수 있습니다만, 그렇다고 해도 아주 오랜시간에 걸쳐 반복작업이 이루어져야 그에 따른 최적값을 기대해 볼 수 있다는 것은 부정할 수 없는 사실입니다.


2. 진화 연산에 적용된 병렬처리기법
2.1 다수의 CPU 사용

초창기 유전프로그래밍(이하 GP)의 창시자라고 언급되는 John. R. Koza 의 경우에는 천 대의 컴퓨터를 하나의 클러스터로 활용해 GP를 수행하였으며, 이를 통해 과거에 발표되었던 특허들을 그대로 GP의 결과물로서 만들어내는 결과를 보여주었습니다.[1] (첫 페이지의 팔짱을 끼고 있는 그의 모습 뒤로 펼쳐진 것들이 수많은 컴퓨터의 클러스터입니다.)

그러나 일반적인 연구자들이 이러한 리소스를 활용할만한 능력을 갖추기는 어려웠기 때문에 사실상 대규모 클러스터링을 활용한 연구는 Koza 의 이후로 거의 나타나지 않고 있었습니다. 소수의 연구자들에 의해 소규모의 분산 처리 시스템[2]이나 여러 개의 CPU 를 사용한 연구[3]는 이루어지고 있었습니다. ([3] 논문은 가상의 병렬 처리 머신을 통해 데이터를 주고받는 것에 대한 논문입니다만, 저 논문의 결과물로서 lil-gp 의 병렬화된 형태를 언급하는 데 이것은 다중의 CPU 를 사용하는 병렬 처리 기법이 사용되어 있습니다.)


2.2 GPU

시간이 흐른 뒤, nVidia 에서 GPU 가 나오게 되었습니다. 이것은 벡터 연산에 특화되어 있고, CPU 에 비해 압도적인 처리성능을 보여주기에 수 많은 알고리즘이 이를 해당 알고리즘에 적용시키기 시작하였습니다. 물론 진화연산에서도 절대 예외일 수는 없었습니다.

대표적인 논문으로 몇가지를 언급하자면, 우선은 진화 연산을 타겟으로 삼은 것은 아니지만, GPGPU(General-Purpose computation on Graphics Processing Units) 의 개념을 활용해 알고리즘에 적용하는 것이 좋겠다고 제안한 논문이 있습니다. [4] 그리고 실제 GPU 를 사용해서 GP를 수행하고, 이에대한 성능 비교를 수행한 논문이 발표되게 되었습니다. [5,6,7]

일반적으로 생각하기에 GPU 를 통해 병렬적으로 개체의 해석을 수행하게 되면 CPU 만을 사용하는 현 GP 에 비해서 엄청난 속도 향상을 기대 하지만, 실제로는 모든 문제에 대해서 그렇지는 않았다는 내용이 [6] 논문에서 나타나고 있습니다. 그러나 위의 논문에서 사용된 컴퓨터의 사양은 T2400 (1.83 Ghz), 1.5GB ram, GeForce 7300 GO with 512 RAM 으로서, 노트북 컴퓨터라고 보시면 됩니다. 즉, 일반적으로 사용하는 GPU 에 비해서는 그다지 좋은 성능을 보여주는 것은 아니었던 것입니다.

그리고 [7] 논문에서는 GPU 에 최적화된 GP 연산 기법을 소개하고, SIMD 처리 형태에 알맞은 데이터 처리 방식을 사용하여 더 좋은 효율을 보여준다는 것을 나타내고 있습니다. 또한, 이 논문에서 더 주목해 볼 수 있는 것은 Geforce 8800 GTX 라는 고사양의 GPU를 사용했다는 것과 이를 통해 CPU 의 오버헤드가 0.1%에 근접한다는 내용, 그리고 기존에 해결하는데 매우 오랜 시간이 걸렸던 거대한 형태의 Regression 문제를 해결했다는 것에 있습니다. 1024 x 1024 x 1000 의 크기의 문제를 200번 수행하는데 6시간 46분 17초가 걸렸다는 건, 기존에 우리가 처리할 엄두도 못 내던 거대한 크기의 문제들을 GPU 를 사용하여 처리한다면 더 큰 효율과 빠른 결과를 얻을 수 있다는 것을 의미합니다.

[8] 논문에 이르러서는 Xbox360 이라는 이 종의 하드웨어를 통해 GP를 수행하게 됩니다. 컴퓨터의 GPU 를 통한 결과와 Xbox 360 의 GPU 를 통한 결과를 서로 비교하는 내용이 있는데, 특이할 만한 점은 C# 과 XNA Framework 를 통해 구현된 동일한 프로그램(GP)을 Xbox360 과 PC 에서 변환 없이 수행할 수 있었다는 것, 그리고 결국 성능은 PC 가 더 좋았다는 것이 되겠습니다.


2.3 기타 웹이나 네트워크 기반의 진화연산 기법

이렇듯 GPU 의 등장과 함께 진화 알고리즘은 매우 빠른 병렬처리 알고리즘을 통한 복잡한 문제의 해결, 그리고 GPU 에 걸맞는 형태의 알고리즘의 변화 등이 이루어져 왔습니다. 그러나 사실 GPU 를 통한 GP 의 발전은 아직은 한계가 있습니다. 가장 큰 한계점이라면 단순 Regression 문제나 디지털 논리회로를 벗어나는 문제에 대해서는 아직 그 위에서 해석할 방법이 없다는 것 입니다. 즉, 단순한 문제지만 거대한 데이터 셋을 갖는 문제에 대해서는 그 효율을 극대화 하여 이용할 수 있지만, 복잡한 시뮬레이션의 경우에는 아직 GPU 에서 그것을 수행하기에는 많은 무리가 따르게 됩니다.

GPU 의 진화 연산보다는 살짝 앞선 시기에 웹을 통한 진화 연산의 수행기법들에 대한 연구가 이루어 졌습니다. [9] 논문의 경우에는 웹을 통해 사람이 어떠한 평가를 내리고, 이를 서버에서 모아서 진화연산을 수행하는 형태에 대한 연구기법에 대해 논하고 있습니다. 이는 기계로 평가를 내리기 어려운 적합도 함수, 즉 좋은 음악이나 색의 조합 등 인간의 주관이 개입되어야 하는 문제에 대해서도 진화연산의 수행이 가능하다는 것을 보여준 사례가 되겠습니다.

2007년에 발표된 [10] 논문의 경우에는 XML 과 Ajax 를 통해 웹브라우저로 데이터를 서로 주고받고, 적합도 함수를 평가하며 해결하는 시스템을 구축하였습니다. 이 논문에서 아쉬운 점은 비교할만한 대상이 없었기 때문에, 해당 기법이 기존의 기법에 비해 어느 정도 효율성을 갖는지가 나타나지 않았고, 매우 빠른 연산을 보여주었다는 시간만을 언급하고 있다는 것이었습니다.

그리고 ECJ Framework[11] 에서는 TCP/IP 상의 Asynchronous Island Model 을 지원함에 따라 기존의 진화 연산 문제를 대규모 네트워크를 통한 처리 형태를 쉽게 사용해 볼 수 있습니다. 이미 모든 구현이 이루어져 있기 때문에 약간의 파라미터 수정만 거치면 바로 네트워크를 통한 진화연산 기법의 연구가 가능하다는 장점이 있습니다. 관심 있으신 분은 한번쯤 해보시면 좋을 것 같습니다.


3. 정리

이보다도 이른 시기에 네트워크를 통한 데이터 교환을 통해 진화 연산의 병렬화의 효율에 대해 논하는 것들이 많이 있었지만, 사실상 GPU 와 같이 핵심 테마로서 자리를 잡을 만큼의 파급력을 갖출 수 없었습니다. 이는 어쩌면 진화 연산 자체를 병렬처리로 수행한다는 것은 하나의 연구테마로 갖추기가 어려운 것이었을 수도 있고, 기존의 방법들에 비해 획기적인 성능을 보여주는 사례가 없었기 때문일 수도 있습니다. 혹은 고도의 시뮬레이터를 통한 시뮬레이션을 필요로 하는 그런 문제가 정의되지 않았기 때문일 수도 있습니다.

진화연산에서는 알고리즘 자체가 적은 수행 횟수를 통해 더 개선된 성능을 보여주는 것은 여전히 중요한 테마입니다. 단위 시간에 대해 더 효율적인 공간의 탐색을 할 수 있다면, 성능 개선을 위한 가장 훌륭한 접근이 될 수 있겠습니다. 거기에 같은 단위 시간에 대해 두 배 아니 열 배 이상의 수행이 가능하다면 더 좋은 성능을 보여주기 위한 가장 좋은 해결책이 아닐까 생각이 듭니다. 물론 이렇게 말하게 되면, 병렬처리 자체는 기존의 알고리즘의 개선을 위한 접근 방법들에 비해서는 중요도가 떨어져 보이는 것이 사실입니다. 그러나 이전에는 접근해 볼 수 없었던 100만개~1억개 이상의 개체의 진화나 이로 인해 나타나는 현상들은 기존의 알고리즘으로 접근하는 방식들과는 다를 것이라 생각되기 때문에, 진화 연산 자체의 병렬처리 시스템은 기존의 방식들과는 별도로 매우 중요한 테마가 되지 않을까 생각합니다.


4. 참고문헌

[1] John. R. Koza – http://www.genetic-programming.com/johnkoza.html

[2] F. S. Chong and W. B. Langdon. Java based distributed genetic programming on the internet. In W. Banzhaf, et al., editors, Proceedings of the Genetic and Evolutionary Computation Conference, volume 2, page 1229, Orlando, Florida, USA, 13-17 July 1999. Morgan Kaufmann. ISBN 1-55860-611-4.

[3] F. Fernandez, J. M. Sanchez, M. Tomassini, and J. A. Gomez. A parallel genetic programming tool based on PVM. In J. Dongarra, et al., editors, Recent Advances in Parallel Virtual Machine and Message Passing Interface, Proceedings of the 6th European PVM/MPI Users' Group Meeting, volume 1697 of Lecture Notes in Computer Science, pages 241-248, Barcelona, Spain, September 1999. Springer-Verlag.

[4] J. D. Owens, D. Luebke, N. Govindaraju, M. Harris, J. Kruger, A. E. Lefohn, and T. J. Purcell. A survey of general-purpose computation on graphics hardware. Computer Graphics Forum, 26(1):80-113, March 2007.

[5] D. M. Chitty. A data parallel approach to genetic programming using programmable graphics hardware. In D. Thierens, et al., editors, GECCO '07: Proceedings of the 9th annual conference on Genetic and evolutionary computation, volume 2, pages 1566-1573, London, 7-11 July 2007. ACM Press.

[6] S. Harding and W. Banzhaf. Fast genetic programming on GPUs. In M. Ebner, et al., editors, Proceedings of the 10th European Conference on Genetic Programming, volume 4445 of Lecture Notes in Computer Science, pages 90-101, Valencia, Spain, 11 - 13 April 2007. Springer.

[7] W. B. Langdon and W. Banzhaf. A SIMD interpreter for genetic programming on GPU graphics cards. In EuroGP, LNCS, Naples, 26-28 March 2008. Springer.

[8] G. Wilson, W. Banzhaf, Linear Genetic Programming GPGPU on Microsoft’s Xbox 360, in Proceedings of 2008 IEEE World Congress on Computational Intelligence, Hong Kong, 2008.

[9] W. B. Langdon. Pfeiffer - A distributed open-ended evolutionary system. In B. Edmonds, et al., editors, AISB'05: Proceedings of the Joint Symposium on Socially Inspired Computing (METAS 2005), pages 7-13, University of Hertfordshire, Hatfield, UK, 12-15 April 2005a.

[10] J. Klein and L. Spector. Unwitting distributed genetic programming via asynchronous javascript and XML. In D. Thierens, et al., editors, GECCO '07: Proceedings of the 9th annual conference on Genetic and evolutionary computation, volume 2, pages 1628-1635, London, 7-11 July 2007.

[11] ECJ - http://cs.gmu.edu/~eclab/projects/ecj/

Posted by SHHyun
사랑하지 않으면 떠나라!사랑하지 않으면 떠나라! - 8점
차드 파울러 지음, 송우일 옮김/인사이트
1. 간략한 내용

IT 업계에 종사하는 자들에게 필자가 충고하는 내용들.

2. 책에 대한 개인적 의견

개발자로서 살아가야 한다는 것이 부담이 되는, 혹은 두려운 사람들이 보면 좋을 듯한 책. 이 책의 의도는 자신의 개발자로서의 가치를 높히는데 게으르지 말라는 말이지만, 보고나면 과연 저렇게 만능으로 살아가야만 하는 것일까? 라는 의문이 좀 생깁니다. 정말 완전한 만능 멀티플레이어가 아니고는 살아남지 못할거라는 느낌이랄까요?

개인적으로 이 책을 구매한다면 살짝 말리고 싶은 기분? 다른 조언류의 책이 그렇듯, 이 책 역시 교보문고나 대형 서점에서 한번쯤 읽어보고 ' 아 ~ 그렇 구나! ' 라고 느낀다면 그걸로 충분할 법한 책. 하지만 이 책의 뜻을 바이블로 삼고 싶으신 분이라면 반드시 "읽어보고" 사시길 권해드립니다.
 
Posted by SHHyun

MSRS(Microsoft Robotics Studio) 가 정식버전이 나오면서 MSRDS(Microsoft Robotics Developer Studio) 로 이름이 바뀌어 발매가 되었더군요. MSRS 이던 시절부터 이 툴 에 대한 기대는 매우 컸고, 소개나 이런 것들을 봤을때 정말 로봇 연구 분야에 있어서 최적의 툴이 아닌가 생각을 했었습니다.

CCR(Concurrency and Coordination Runtime) 과 DSS(Decentralized Software Services) 를 통해 비동기적 처리 방식에 실시간 반응이 가능하도록 하였고, VPL(Visual Programming Language) 이라는 Labview 와 같은 GUI 형태의 언어를 통해 누구나 쉽게 로봇을 제어할 수 있다는 것을 주로 장점으로 부각하였습니다. 여기에 서비스의 추가만 이루어지면 확장할 수 있다는 것, 사실적인 물리엔진 등등 많은 장점이 부각되고 있었습니다.

뭐... 참 좋은 툴임에는 틀림 없습니다만, 두가지 확실히 눈에 보이는 단점들이 있더군요. 각각에 대해서 한번 간단하게 정리해볼까 합니다.

1. 높은 사양

사용자 삽입 이미지

(*) 저도... 시뮬레이션을 돌리고 싶어요... ㅠㅠ


  MSRS 1.5 -> MSRDS 2008 로 넘어오면서 픽셀쉐이더와 버텍스쉐이더를 지원하는 GPU 를 시뮬레이션 환경에서 요구합니다. 물론 고화질의 시뮬레이션을 얻는다는것이 나쁘다는 건 아닙니다. 꼬우면 돈주고 사면되지 않느냐라고 해도 딱히 할말은 없죠. ( 모 게임에서는 돈이 없는건 죄가 아니다라고 하더군요;;; 아..아스트로레인저 잊지않겠다 -_- )
  그러나 MSRS 에서는 분명 소프트웨어적으로도 그런 시뮬레이션 환경을 지원 했었습니다. 그래서 상대적으로 사양이 낮은 PC 에서도 시뮬레이션을 수행해보는데 큰 무리가 없었습니다. 하지만 MSRDS 2008 로 넘어가면서 시뮬레이션 화면자체가 검은 상태로 아무것도 나타나질 않습니다. 제가 알기로는 현재 MSRDS2008 에서 GPU 의 내장 물리 엔진을 사용하는 것도 아닌걸로 알고있습니다만(이부분은 명확하지 않습니다.), 어떤 이유에서인지 반드시 GPU 의 엔진을 요구하고 있습니다. 덕분에 저는 다른 사양 좋은 컴퓨터에서 작업을 해야되지 말입니다.....
  그리고 이 높은 사양에 대한것은 하나 우려되는 점이 있습니다. CCR 과 DSS 를 통해 비중앙화된 전송형태와 동시성을 확보할 수 있다고 하는데, 이 역시 멀티코어 기반의 환경을 주로 테스트 벤치마크로서 보여주고 있습니다. 단일 코어 기반은 쓰지 말라는 것 같습니다. -_-

2. VPL

  VPL 은 초보자를 위한 언어이고, 간단한 테스트 정도를 위한 언어일 것이라고 생각됩니다. 이를 통해 복잡한 로직을 구현한다는 건 오히려 머리속에 방해가 될 것 같은 기분이 듭니다. 물론 Labview 를 통해 큰 규모의 프로그램을 봤을 때, VPL 도 그러한 가능성을 충분히 가지고 있다고 생각이 됩니다. 그러나 Labview 의 그것에 비해서 VPL 은 생각보다 많이 불편합니다.
  일단 깔끔해 보이기 위해서 큼직큼직한 서비스 아이콘을 만든건 좋습니다만, 오히려 좀 더 작고 가볍게 만들어서 쓸데없는 그래픽 효과가 나타나다가 다운먹는 현상을 좀 없애주는건 어떨까 생각합니다. 약간만 흔들어대도 공포의 오류메세지가 나타납니다만 이건 좀 아닌것 같죠? ( 제 PC 에서만 그런 건가 했는데, 그게 아니더군요 -_- )
  그리고 루프를 만드는 것이 상당히 지저분합니다. 아주아주 지저분합니다. 루프의 편의를 제공하기 위해 제공하는 서비스가 있긴 하지만, 그것을 이용한다 해도 지저분한 것은 어쩔 수 없죠. 물론, 그 더러운꼴 보기 싫다면 C#을 사용하면 됩니다.... MSRDS 하나를 사용하기 위해 새로운 언어를 쓰라. 이말입니다. ( 그렇다고 C#이 나쁘다는건 아닙니다. 써보니 편하고 좋습니다;; )

....

그냥 확실한 단점인 저 두가지만 지적해야겠습니다. 저 두가지만으로도 정이 뚝떨어지긴 합니다.( 특히 고사양은 정말... ㅜㅜ ) 물론 범용적으로 알려져 있는 로봇 시뮬레이터가 없고, VPL 로 몇가지 시뮬레이션 로봇을 돌려보시고 나면 정말 이렇게 쉬울수가! 라고 외치실 지도 모릅니다.

하지만... 뭔가 더 해보시려면 발버둥이 아니라 생난리를 쳐도 난감해지는 상황에 봉착하게 될것입니다. (아닐수도 있습니다 ^^) 어디까지나 현재로서는 말이죠. 기본 서비스를 제공하는 것 만으로는 고수준의 시뮬레이션을 하기는 어렵고, 실제 로봇과의 연동을 위해서는 일단 로봇이 필요하지만, 사실상 있다고 해도 이를 지원하는 로봇이 아직까지는 그렇게 다양하지는 않습니다.

C# 을 사용할 수 있고, 배울 수 있는 분이라면 MSRDS 가 가진 가능성은 무궁무진하다는 것만큼은 확실합니다. MSRDS 의 세부적인 서비스 개발에도 C#이 필요하고, VPL 로 할 수 없는 고수준 제어 역시 C#으로만 가능하기 때문이죠.

전체 내용을 정리를 하자면,
1. MSRDS 2008 로 업그레이드 되면서 사양이 무지하게 높아졌다. 그러므로 로우스펙의 유저는 그냥 VPL 로 덧셈뺄셈만 해보면 그걸로 끝, 시뮬레이션은 기대도 말고... ( Simulation Engine 이나 Simulation 관련 서비스 하나만 띄우시고 수행하셔보시면, 사용 가능 여부를 바로 알 수 있습니다. )
2. VPL 로 많은 것을 기대하지 마라. 그리고 VPL 로 복잡한 프로그래밍을 할 경우에 수시로 저장을 해야 중간에 다운먹어도 당황하지 않을 것이다.
3. MSRDS 2008 의 모든 기능을 사용해 보기 위해서는 C#을 배우세요. C#을 배우면 세상이 달라집니다.

네 이정도가 되겠습니다.

끝으로 몇가지 유용한 링크를 걸어놓도록 하겠습니다.

Microsoft 의 Express 버전의 도구들 다운받는 곳
http://www.microsoft.com/express/download/

드림스파크
http://www.microsoft.com/korea/msdn/dreamspark/ds_sub01.aspx

MSRDS(Microsoft Robotics Developer Studio)
http://msdn.microsoft.com/en-us/robotics/default.aspx

Naver MSRDS Korea 카페
http://cafe.naver.com/msrskorea/

(*) 개인 유저이시라면 가급적이면 불법복제품 쓰지 마시고, Express 버전을 사용하세요. 사실 개인이 Professional 버전 이상의 컴포넌트를 사용할일은 별로 없는것 같아요; Express 버전의 C# 으로도 여러가지 작업을 하는데 크게 부족함이 없었습니다. 대학생이시라면 드림스파크 링크로 가셔서 Professional 버전의 정품을 사용하시는것도 좋습니다 :)

Posted by SHHyun
촘스키 세상의 권력을 말하다 1촘스키 세상의 권력을 말하다 1 - 10점
노암 촘스키 지음, 강주헌 옮김/시대의창
- 간단한 내용 정리 -

전세계에서 일어나고 있는 수 많은 권력의 싸움과 투쟁, 그리고 그들이 하는 행동에 대한 치밀한 분석들이 담겨 있다. 주로 미국내에서 자유주의와 자본주의에 대한 이야기, 보수와 진보에 대한 이야기를 다루고 있다. 그러나 힘 있는 자들의 횡포와 없는 자들의 그것에 대응하는 자세, 힘 있는 자들의 얻어내려고 하는 것, 사회 보장 제도의 말도 안되는 모순 등 여러가지 사례와 그것에 대한 생각들이 있다.

- 책에 대한 생각 -

이 책이 담고있는 내용은 전 세계를 타겟으로 하고 있지만, 우리나라 사회 전반에 걸쳐 일어나고 있는 있는자와 없는자의 전쟁에 대해 이해하기에 부족함이 없다고 생각됩니다. 또한, 우리나라에서 권력을 가진자들이 어떠한 생각을 하고 있는지, 그들이 이야기하는 자유주의 시장경제나 무한 경쟁에 대한 것들이 사실 자신들의 배를 불리기 위한 허울뿐인 소리에 불과하다는 것을 이해할 수 있다랄까요?

가장 기억에 남는 내용은 언론이 결국 힘있는 자들을 보호하는데 집중할 수 밖에 없는 이유에 대한 것들인데, 이는 우리나라의 조중동과 같은 보수 언론들이 지금 무슨 작태를 부리고 있는지에 대해 이해하는데 꽤 도움을 줄 것이라고 생각합니다.

저같은 20대 분들중에서 정치에 관심이 없으신 분들이라도 무겁지 않게 보실 수 있다고 생각합니다. 중간 중간에 흔히 볼 수 없는 용어들이 사용되는데 이는 저같이 이 분야의 전문용어를 모르는 분들은 사전을 찾아보시면 알 수 있는 정도 입니다.(영어 아닙니다, 그리고 저만 몰랐을지도 몰라요;;)

촘스키라는 대학자의 식견을 접할 수 있고, 이 세계의 권력의 이동이나 변화, 대응들을 두권의 책을 통해서 약간은 이해할 수 있다는 것 만으로도 충분한 가치가 있다고 생각합니다.

(*) 제가 처음 촘스키에 대해 들었던 건 정치학자 였는데, 원래는 언어학자 였다고 하고 손을 대지 않고 있는 부분이 없는 사람으로 알려져 있네요. 대단합니다 정말 ;;
http://www.shhyun.com/tc2009-01-29T10:54:520.31010
Posted by SHHyun


1. 군집간 이주

GA 나 GP 와 같은 진화 알고리즘에서 무시할 수 없는 문제 중에 하나가 조기수렴 문제이다. 이를 해결 하기 위한 여러 가지 방법들이 제안되고 있으며, 대표적으로 유전 연산자의 조절, 선택 연산자의 조절, 군집 형태의 조절 등이 있다. 그 중에서도 다중의 군집 사용과 그것의 조절에 대해서 설명한다.


2. 다중 군집(Multi Population)

군집은 다수의 개체가 하나의 그룹으로 묶여있는 단위이다. 본래 GA 나 GP 에서는 단일의 군집을 사용하여 연산을 수행했었다. 그러나 단일 군집의 효율성을 증가 시키기 위해 군집을 여러 개로 나누어 사용하는 다중 군집 방식이 도입되기 시작했다. 초기에는 군집을 격리시켜 각각의 군집으로 분류해서 이를 발전시켜나가는 방식이 수행 되었으나, 후에는 이 군집들간의 몇몇 데이터를 서로 다른 군집으로 이동시켜서 이를 발전시켜 나가는 방식이 수행되곤 했다.

서로 다른 군집들간의 데이터가 어떤 원리에 의해 이동을 하는지에 따라 여러 가지 방식이 존재한다. 가장 기본적인 형태로 원형이주가 있고, 발전된 형태로 HFC 나 ALPS 와 같이 특정 조건에 의해 서로 다른 군집으로 격리 시키는 형태가 있다. 이 방식들은 전체적으로 알고리즘 자체의 조기수렴은 방지 하면서 최적해를 찾아가는 성능은 발전 시키는 방향을 염두로 설계한 방식들이다.



3. 원형 이주 방식(Ring Migration)

원형 이주 방식은 군집들 간의 데이터 이동 방향이 하나의 흐름을 가진다. 그리고 일정한 주기마다 특정 개체를 다음의 군집으로 이동시키는 방식이다. 이 때, 이동되는 개체들을 수용할 공간을 할당하는 방식과 이동 시킬 개체를 선택하는 방식의 조절이 가능하며, 이에 따라서 각기 다른 효과가 나타난다.

일반적으로 많이 쓰이는 방식은 가장 높은 적합도의 개체를 다음 군집의 가장 적합도가 낮은 개체로 대체 시키는 방식이고, 일반적으로 해당 군집의 10%의 개체를 변경하는 방식을 사용한다. 여기서 너무 많은 개체를 변경하는 방식을 사용할 경우 전체적으로 군집 전체가 비슷한 개체들로 수렴해버리는 현상이 나타나며, 이로 인해 오히려 더 빠르게 조기수렴하는 현상이 나타나는 경우도 있다.


4. 주입형 이주 방식(Injection Migration)

주입형 이주 방식은 여러 개의 개체군에서 최고의 적합도를 갖는 개체들이 한 군집으로 모여 경쟁을 하는 방식이다. 기본적인 원리는 가장 좋은 형질의 유전자들끼리의 교배를 통해 좀 더 좋은 결과를 기대하는 방식이지만, 여러 군집이 수렴될 경우에 오히려 비슷한 유전자들이 하나의 군집에 모이게 되어 조기에 수렴하는 결과가 나타나는 경우도 있다.

주입형 이주 방식도 원형 이주 방식과 같이 일정 주기에 약 10% 의 개체를 주입 받아 사용하는 것이 대부분이며, 단일 적합도 함수를 가진 경우보다는 다수의 적합도 함수를 갖는 경우에 주로 사용된다.

5. HFC(Hierarchical Fair Competition)


HFC는 교육이론으로부터 파생된 군집의 교환 방식이다. 일반적인 교육 시스템은 같은 학년의 학생들, 즉 비슷한 수준의 학생들끼리의 경쟁을 모토로 한다. 그러나 일반적 진화연산의 경우에는 적합도가 높고 낮음에 관계 없이 모두 같은 환경에서 경쟁을 하게 된다. 이로 인해 적합도가 높은 개체만이 살아남고, 적합도가 낮은 개체가 비록 좋은 형질을 지녔더라도 이것이 보존되지 않는 현상이 발생한다.

HFC 에서는 이러한 불공정한 막기 위해 적합도에 따른 개체간의 분류가 이루어지고, 이를 이용해 적합도가 비슷한 개체들끼리만 공정한 경쟁을 하도록 한다. 이로 인해 조기수렴 효과가 억제되는 효과를 가지며, 적합도는 낮을 지라도 우수한 형질을 가지고 있는 개체들이 탈락되는 현상을 억제하는 효과를 가진다. 구체적인 알고리즘의 여러 가지의 파라미터 및 제한 요건은 아래에 정리되어 있다.


(*)HFC 모델의 구성요소


The Hierarchical Organization of Subpopulations to Establish a Fitness Gradient


낮은 적합도의 개체들은 낮은 레벨에 머무는 것을 허용한다.

낮은 적합도의 개체들은 더 낮은 레벨의 군집으로 이주할 수 있다.

허용 범위의 적합도 아래로 생성된 자손들은 해제시킬 수 있으며, 반복적으로 연산을 수행할 수 있다.

그들의 부모보다 낮은 적합도를 가진 생성된 어떠한 자손도 해제 당할 수 있다.

선택된 부모로부터 생성된 자손들은 적어도 한 부모의 적합도보다 높은 경우 생성될 수 있다.

   

Random Individual Generator : The Source of Genetic Material

   

최하위 레벨의 군집은 지속적으로 새로운 임의의 개체를 유입한다.

   

The Migration Policy from Lower to Higher Fitness Levels

   

몇몇 레벨의 군집에서 해당 군집의 허용 범위에 적합하며 이주되는 개체들은 몇몇의 적합도가 좋지 않은 개체들을 대체하게 된다.

만약에 허용된 버퍼로부터 개체가 이주된 후에 빈 공간이 생기게 되거나 혹은 그 허용 버퍼에 빈 공간이 생길 경우, 그것은 현재 멤버로부터 변이 연산을 수행하거나 두 개의 멤버를 크로스 오버 연산하여 필요한 만큼의 새로운 개체로 추가하거나, 더 낮은 레벨로부터 개체를 이주할 수 있다.(최 하위 레벨의 개체는 새롭게 생성하여 추가한다.)

이주는 오직 한 레벨에 대해서만 허용한다.

   

Setting the Parameters of the HFC Model

   

적합도 레벨의 개수,

각 레벨의 적합도 범위

6. ALPS(Age-Layered Population Structure) (2)

ALPS 는 HFC 와 비슷한 개념을 가지고 탄생한 알고리즘이다. ALPS 에서 공정한 경쟁의 요소로 사용되는 것은 개체의 나이가 된다. 여기서 나이란 해당 개체가 얼마나 오랜 시간 동안 진화가 되어 왔느냐를 의미하는 것이다. 즉, 비슷한 시간 동안 진화가 되어온 개체 들 간의 교배만을 허용하는 알고리즘이다.

마찬가지로 HFC 와 같이 조기수렴의 효과를 획기적으로 억제하는 효과를 보여주며, 특히 매우 어려운 문제에서 아주 오랜 세대에 걸쳐 진화연산을 수행할 때에 그 효과가 뛰어난 것으로 알려져 있다.


(*) 약 10만 세대까지는 비슷하지만, 그 세대수가 80만, 100만이 넘어서는 경우에는 확실한 성능차를 보여줌. ((2)참조)


이 ALPS 알고리즘의 구체적인 파라미터나 제한요소들은 아래에 정리되어 있다.


  1. 흐름
    1. 새롭게 임의로 생성되는 개체는 나이 0 을 부여 받는다.
    2. 변이나 재조합에 의해 생성된 개체는 가장 오래된 부모의 나이에 +1만큼 부여 받는다.
    3. 엘리티즘과 같은 방식에 의해 변형 없이 복사될 경우, 나이를 1 증가 시킨다.
    4. 만약에 한 개체가 그 세대에서 여러 번 선택되어 변이될 경우에는 오직 나이를 1만 증가시킨다.
    5. 각각의 개체들은 나이에 의한 계층으로 구분된다.
    6. Age-gap parameter 는 계층에 곱해지는 수치이다. 예를 들어 Polynomial Aging-scheme 에 age gap 20이 곱해질 경우, 20, 40, 80, 180, 320, … 이 된다.

         

  2. 기존의 EA와 다른 몇가지 형태
    1. 개체들은 오직 자신의 계층과 그 이전의 계층과 교배연산을 수행할 수 있다. 예를들어 layer n 의 경우 layer n-1 과 n 의 계층이 교배연산에서 선택될 수 있다.
    2. Layer 0 은 age-gap 세대 마다 새롭게 생성된 개체로 대치된다.
    3. 현재 계층의 개체가 너무 늙게 되면, 이것은 다음의 늙은 계층과 비교하게 되어 만약에 이것이 적어도 하나의 개체보다 좀더 좋은 적합도를 갖는다면 그것은 다음 계층의 개체와 교체하게 된다.
    4. 각각의 계층은 고정된 개체수를 가짐. 논문에서는 총 10개의 계층으로 구분 하여 100개씩의 개체를 갖도록 만들어졌음.
    5. 처음부터 모든 계층이 활성화 되는 것이 아닌, 초기 계층부터 age-gap 마다 새롭게 생성되는 계층에 대해 점증적으로 수행되는 방식. 만약 age-gap 이 20 일 경우, 초기 20 세대에는 첫번째 계층만 수행, 그리고 40세대 까지 첫번째와 두번째 계층만을 유전연산 및 수행, 60 세대 까지는 첫번째, 두번째, 세번째 계층만을 수행하는 방식.


7. 정리

이주 방식 자체는 조기수렴의 감소를 타겟으로 계획된다. 어떤 특정 문제에 대해 연산 자체의 획기적 성능 개선이나 전체적인 리소스의 점유와 같은 것을 염두 하는 것이 아니다. 이주 방식은 오히려 어떠한 문제에서든지 연산 자체의 효율성을 극대화 시켜주는 것을 타겟으로 하기 때문에 범용적인 사회적 문제나 현상을 토대로 알고리즘 화 된 것이 많다. 그러므로 실제적인 문제의 해결에 있어서 문제의 성질에 따른 연산자의 선택이 가장 우선적이며, 그 연산자의 올바른 발전 양상을 유도할 수 있는 이주 방식의 설정은 부차적인 문제가 될 수 있다.


참고 문헌

1. Jianjun Hu, Erik Goodman, Kisung Seo, Zhun Fan, Rondal Rosenberg The Hierarchical Fair Competition(HFC) Framework for Suitable Evolutionary Algorithms. Evolutionary Computation, 2005.

2. G. S. Hornby, "ALPS : The Age-Layered Population Structure for Reducing the Problem of Premature Convergence. " GECCO'06, pp. 815-822, July 8–12, 2006.



Posted by SHHyun

Neural Network 는 큰 관심이 있었던 분야는 아니었습니다. 이 녀석이 태생적으로 중간 계층의 Hidden Layer 와 오류역전파 알고리즘 이후로 뭔가 하나의 획을 그을만한 대단한 알고리즘이 나타나지 않았기 때문도 있었지만, 사실 저 둘만으로도 충분히 번거로웠기 때문이었습니다.

항상 중간의 숨겨진 계층의 개수를 조절해야 되고, 그에 따른 가중치 값의 튜닝이 이루어져야 합니다. 그것이 만약 상당한 트레이닝을 거치고서도 개선이 없을 경우에는 다시 계층의 개수 조절에 이은 가중치 값 튜닝이 이루어져야 했었습니다. GA 나 GP 라는 것은 지들이 몇 가지 변수만 대입하면 준 최적 값이라도 잘 돌려줘서 써먹는 데는 큰 지장이 없었기 때문에 주로 쓰고 있었습니다.

그런데 얼마 전부터 좀 관심이 가는 녀석이 생겼습니다.

NEAT 라는 것인데 NeuroEvolution of Augmenting Topoliges 의 약자 입니다. 이것은 GA 나 ES 와 같은 유전자형태를 가지면서 Neural Network(이하 NN) 를 구성하고 스스로 진화시켜나가는 모델입니다. 위에 제가 NN 에 관심을 두지 않았던 가장 큰 이유인 귀찮다! 라는 것을 아주 쉽게 개선시켜줄 수 있습니다.

게다가 인터넷에 소스와 논문들도 널려있습니다. 어쩌다 관심을 가지고 몇 가지를 찾다 보니까 정말 자료가 많이 있더군요. 특히 야후의 그룹에서는 상당히 활발하게 토론되고 발전되어가고 있더군요. NN 에 관심을 가지고 있고, 써볼 데가 있긴 있는데 귀찮아서 도저히 못해먹겠다 싶어서 고민하셨던 분이라면 http://tech.groups.yahoo.com/group/neat/ 이곳에 한번 가보시는걸 추천 드리겠습니다.

P.S. 써보니까 편하긴 한데 파라미터를 좀 많이 손봐야 제대로 성능이 나오는 게 아닌가 싶네요. 단순한 문제는 좀 풀어주는 것 같은데 복잡한 것에는 정말 엄청난 시간이 필요한 듯 싶어요;;


2017년도의 P.S. 이글을 쓴 것이 2008 년인데, 사실 해외에선 슬금슬금 CNN 에 관련된 내용들이 나오기 시작했던 것 같군요.

Posted by SHHyun