GHTS

셀 분할 : <Ctrl+Shift+'-'>

셀 병합

- 병합할 셀 다중선택 : <Shift+(화살표 위아래)>

- 선택된 셀 병합 : <Shift+M>

Jupyter는 1줄을 따로 실행하는 게 귀찮은 문제가 있는 반면,

RStudio는 코드 블록을 실행할 때마다 해당 코드 블록을 선택해줘야 하는 게 귀찮은 문제가 있다.

Jupyter로 1줄씩 별도의 셀로 분할한 후, 필요하면 병합하는 방법이 해결책이 될까??

한국인 출신으로 뉴욕 월스트리트 금융기관에서 알고리즘 트레이딩 업무에 종사한 경험담을 기록해 놓은 책이다.

후반부는 기술적인 내용이 많아서 일반인이 읽기에는 조금 부담스러울 수 있지만,

전반부는 알고리즘 트레이딩이니, 퀀트이니 하는 단어가 뜻하는 바를 알기 쉽고 담백하게 설명해 놓았다.

읽다가 가장 인상깊었던 문구.

1. 직관 없는 데이터 분석은 무의미하다.

2. 컴퓨터가 하는 트레이딩도 일반 펀드처럼 운용자가 공포와 탐욕의 감정의 영향을 똑같이 받는다.

이 분야의 한글 서적이 그다지 많지 않은 상황에서

저자의 경험의 희귀성으로 인해 읽어볼 만한 가치가 있다고 본다.

글로만 배운 사람이 하는 말과 다른 실전에서 닳고 닳은 사람만이 알려줄 수 있는 내용을 접할 수 있다.

Go언어에서 GOPATH 의존성 시스템에서 Go모듈(Module) 시스템으로 넘어가면서,

그간 각각의 독립된 패키지에서 개발하던 기능들을

하나의 패키지로 모두 통합하고,

각각의 기능은 서브디렉토리에 분류하게 되었다.

GHTS 라이브러리를 불러다 쓰는 입장에서도

Go모듈 방식을 채용할 경우 버전 관리등이 한결 편해질 것으로 예상된다.

예전에 개발하던 개별 패키지들은 모두 삭제했으며,

통합된 패키지의 주소는 다음과 같다.

https://github.com/ghts/ghts

과거 데이터 통계 분석에 유용한 R언어의 개발환경인 Jupyter의 설치법을 기록해 둔다.

R 설치

https://www.r-project.org/

Python 설치

https://www.python.org/

Jupyter 설치 

최신 정보는 https://jupyter.org/install 참조

python -m pip install --upgrade pip

python -m pip install jupyterlab 

python -m pip install notebook

Jupyter용 R 패키지 설치

<R 커맨드 창에서 실행>

install.packages('IRkernel')

IRkernel::installspec()

IRkernel::installspec() 실행할 때 'In system2("jupyter", c("kernelspec", "--version"), FALSE, FALSE) :
  명령을 실행하는 도중 에러가 발생하였습니다.'라는 에러가 발생하는 경우 jupyter 및 jupyter-kernelspec 실행화일이 위치한 디렉토리를 실행경로에 포함시켜야 한다.

리눅스에서는 ~/.profile 파일에   PATH=$PATH:<추가할 경로> 를 추가해 주면 된다.

윈도우에서는 고급 시스템 설정의 환경 변수 설정에서 PATH 환경 변수에 추가해 준다.

Jupyter 노트북 실행

<cmd 창에서 실행>

jupyter lab 혹은 jupyter notebook

P.S> Jupyter 관련 내용에 jupyterlab과 함께 클래식 notebook도 함께 넣음.

Xing API 현물 주식 주문 TR 기능 구현 후,

테스트를 진행하던 중 정정 및 취소 주문에서 에러가 발생해서,

오랜 시간동안 디버깅을 진행했다.

증상

정상 주문TR 실행 후 즉시, 정정 및 취소 주문 TR을 실행할 경우 에러가 발생.

정상 주문TR 실행 후 0.5초 가량 지난 후, 정정 및 취소하면 에러가 없음.

이유

정상 주문TR을 실행한 후 증권사 서버에서 응답을 받았더라도,

거래소 서버에는 아직 등록이 되지 않은 상태에서,

정정 및 취소 주문 TR이 오면 에러가 발생함.

0.5초 가량 기다리면 거래소 서버에도 등록이 되므로,

에러가 발생하지 않음.

해결책 

1. 0.5초 기다린다.

   : 0.02초에 주문이 실행되는 컴퓨터 매매 세계에서 0.5초는 기다리고 있기에는 너무 긴 시간.

   : 뭐라도 해야 한다.

2. 주문 체결 실시간 정보 확인

  : 거래소 서버에 등록이 된 것을 확인해 주는

   실시간 정보(SC0, SC1, SC2, SC3, SC4)를 수신한 이후에 정정 및 취소하면 에러 없음.

  : 실시간 정보가 UDP로 전달되므로, 패킷 로스로 인해서 제대로 전달되지 않을 가능성 존재.

  : 알고리즘이 복잡해 짐.

3. 단순 무식 반복.

  : 정정 및 취소 주문을 낼 때, 

    '잘못된 원주문번호' 내지 '주문 등록 대기 상태'라는 에러가 발생하면,

    정정 및 취소 주문TR 재실행.

 : TR 실행 및 응답은 TCP로 전달되므로, 항상 정확하게 응답을 받을 수 있다.

 : 에러 메시지를 보고 단순 재실행하기에 알고리즘도 간단하다.

3번 '단순 무식 반복' 방식을 채택하여 정정 및 취소 주문 TR 에러 해결.

이로써, 현물 주식 주문에 대한 내부 테스트 및 디버깅을 완료하고,

안정적인 주문 실행을 확인하였다.

처음에 에러 메시지를 제대로 확인하지 않아서 원인을 알지 못해,

DLL방식과 COM방식을 모두 시도해 보다가,

COM방식에서 에러 메시지를 확인하면서 실마리가 풀렸고,

테스트 서버의 에러 메시지에 버그가 있었던 것을 뒤늦게 발견하고 증권사에 수정 요청을 하는 등,

온갖 우여곡절을 겪은 기나긴 디버깅 이었다.

현 상황 : 2018년 6월 25일자로하도록 수정 및 디버깅을 마치고, 소스코드 커밋 완료.

이제 데이터 수집 및 분석을 시작할 단계...

Xing API를 DLL 방식으로 사용할 경우, 

초기화 과정에서 LoadLibrary() 호출은 반드시 Xing API DLL파일이 존재하는 디렉토리에서 해야 한다.

풀어서 쓰자면,

1. Xing API DLL이 설치된 디렉토리로 이동 (기본값은 C:\eBEST\xingAPI\)

2. LoadLibrary() 호출

3. 원래 작업 디렉토리로 복귀.

이렇게 반드시 Xing API 디렉토리로 이동하는 과정이 필요하다.

그렇지 않으면, 서버 접속은 되는 데, 로그인이 안 된다.

(당해보면 상당히 갑갑하다.)

COM방식에서는 이런 문제가 없다.

CSPAT로 시작되는 주식 현물 주문 TR의 경우,

거래소에 주문이 등록되지 않은 상태에서도 

주문번호가 부여되고 TR에 대한 응답이 돌아온다.

그래서, 해당 주문번호에 대해서 정정 내지 취소 TR을 실행할 경우,

해당 주문번호가 존재하지 않는다는 에러가 발생하기도 한다.

그래서, 정정 내지 취소 주문 TR을 실행할 때는

SC0~4 실시간 정보를 확인하거나,

에러가 발생하면 재실행 하는 등의 보완이 필요하다.

t1102 소진율(exhratio : float 6.2)는 수신값이 '265' 이런 식인데,

소수점이 없더라도 float 6.2 형식이니 2.65로 해석해야 한다.

그런데, 항상 이런 식이 아니며, float 자료형의 개별 항목마다 다를 수 있다고 한다.

소숫점이 포함된 값이 수신되기도 하고,

자의적으로 소수점을 추가하는 것이 오히려 에러를 유발할 수도 있다.

Xing API 개발자 간에 서로 협의가 제대로 않은 채 서로 다른 포맷을 사용하다가,

API가 공개된 이후에는 고칠 수가 없어서 지금껏 이대로 흘러온 것 같다.

Xing API에서 float 값을 쓸 때는 확인이 필요하다.

무료 웹버전 : https://wikidocs.net/book/110

공짜를 좋아해서 처음에는 웹버전으로 읽었지만, 

웹의 특성 상 읽다보면 어느 새 딴 짓을 하고 있게 되는 관계로

집중도를 높이기 위해서 종이책을 구입했다.

가격이 살짝 세고 (4만원, 실구입가 3.6만원)

1부는 평이한 파이썬 입문서 내용이라서 약간 낭비적 느낌이 들기도 하지만,  

2부에서는 COM으로 증권사 API를 사용하는 것에 대한 예제코드와 설명이 곁들여져 있고,

3부에는 데이터 분석에 대한 이야기도 있다.

이 책에 새로운 알고리즘이 있다거나, 혁신적인 내용이 있는 것은 아니지만,

증권사 API 사용에 있어서 진입장벽을 크게 낮추어 주는 의미가 있다.

원래, 처음 시작이 가장 힘든 법인데, 그 시작을 쉽게 해 주는 것은 나름대로 의미가 있다고 본다.

Go언어를 쓰면서 느끼는 가장 큰 불편은 '에러처리'이다.

try-catch 같은 예외처리 기능이 없으며, if문에서 일일이 에러발생 여부를 확인해야 한다.

if 반환값, 에러 := F실행할_함수(인수1, 인수2....); 에러 != nil {

<여기에서 에러처리....>

}

이 방식은 다음과 같은 문제점이 있다.

1. 실행할_함수()는 if문에 파묻혀서 잘 보이지 않는다.

2. 소스코드가 지저분해진다. 소스코드 중간중간에 if문이 끼어들어서 흐름을 끊어놓는다.

그럼에도 불구하고 장점도 있다.

1. 예상하지 못한 동작이 발생하는 것이 예방된다. -> 오작동이 치명적인 경우에는 장점이 된다.

2. 각 에러마다 정확한 개별 대응이 쉽다.

이런 장점에도 불구하고, if문을 사용하는 에러처리 패턴이 불편하게 느껴지는 것은 사실이다.

defer, recover, panic을 조합하면 예외처리 기능처럼 에러를 뭉뚱그려서 한 번에 처리할 수 있다.

try-catch문은 예외가 발생하면 실행이 중단되고, catch문 내용이 실행된다.

go언어에서는 panic이 발생하면 실행이 중단되고, defer문으로 등록한 함수가 실행된다.

실행 흐름은 다음과 같으며 소스 코드에서 번호를 매겨놨다.

1. 에러발생

2. 패닉발생

3. defer

4. recover

5. 에러처리

func F함수_정의(인수A, 인수B,...) {

defer func() {    // 3 : 함수 실행이 종료될 때 자동으로 실행된다. 패닉이 발생해도 실행된다.

if r := recover(); r != nil {    // 4 : recover함수를 실행해서 패닉된 경우 복구한다.

<여기에서 뭉뚱그려서 에러처리>

}

}()

.....

반환값, 에러 := F실행할_함수(인수1, 인수2....)

if 에러 != nil {    // 1 : 에러가 발생하면 패닉을 발생시켜서 함수의 실행을 종료하도록 한다.

panic(에러)    // 2  :  패닉이 발생하면 실행이 중단되고,  defer로 함수로 넘어간다.

}

....

}

언뜻 보면 소스코드가 오히려 더 복잡해진 느낌이다.

그러나, 다음 2개의 도우미 함수를 사용해서 반복되는 부분을 제거할 수 있게 된다.

func F에러2패닉(에러 error) {

if 에러 != nil {    // 에러가 발생하면 패닉 되도록 한다.

panic(에러)

}

}

func F패닉_처리(함수 func(r interface{}) {

if r := recover(); r != nil {    // 패닉이 발생한 경우 패닉을 복구하고 지정된 함수를 실행한다.

함수(r)

}

}

도우미 함수를 이용해서 소스코드를 간단하게 수정하면 다음처럼 된다.

func F함수_정의(인수A, 인수B,...) {

defer F패닉_처리(func(r interface{}) {

<여기에서 뭉뚱그려서 에러처리>

})

.....

반환값1, 에러 := F실행할_함수_1(인수1, 인수2....)

F에러2패닉(에러)    // 에러는 패닉으로 전환되고, defer에 등록된 패닉처리 함수가 실행됨.

// 여기까지만 보면 크게 좋은 점을 모르겠으나, 

// 처리해야 할 에러가 많아지면 이러한 방식의 장점이 드러난다.

....

반환값2, 에러 := F실행할_함수_2(인수1, 인수2....)

F에러2패닉(에러)

....

반환값3, 에러 := F실행할_함수_3(인수1, 인수2....)

F에러2패닉(에러)}

...

}

타 언어의 try-catch 방식의 예외처리문보아야 여전히 불편하긴 하지만,

if문을 사용해서 모든 에러를 일일이 확인하는 기존의 방식보다는 훨씬 간편하다.

GHTS에서는 lib.S예외처리{}.S실행() 으로 되어 있으며

S예외처리의 필드값을 변경하여 실행 옵션을 선택할 수 있다.