바로 그냥 매매중독

나스닥선물은 47분에 거래량이 터지는겁니까

슬라이딩윈도우에서 직접 lstsq의 해를 계산하며 vandermonde matrix를 마구마구곱하고 그 행렬의 역까지 계산해야하는 과정이 있는데 그러면서 x좌표값이 너무큰상태에 그 사이간격이 x의절대값에비해 좁으면 마구마구 곱하는과정에서 뻥튀기되어 float64의 정밀도한계를 뛰어넘는것으로 보이는(100%확인은 안했지만 대충봐도 그런 것 같다) 문제가 있었다 x좌표들을 normalize하면 해결되는데 이게 또 슬라이딩윈도우에서는 그게안대서 잠재적으로 추후에 문제가발생할수 있다 아마 안발생할것같긴하다, 아주연속적이고 장기간의 세세한데이터를 대상으로 추세관련피쳐, 그중 특히 적은 데이터를 사용하는 피쳐들을 프로세싱하지 않는 이상... 비트코인 분봉데이터정도 넣게될 때 유의하면 될 듯 하다. lstsq를 numpy가 제공하는 polyfit으로 진행해서 polyfit과 커스텀함수의 오차를 일정주기로 확인하여 차이가 크면 로그하는 파트를 넣었다 그 외 x[i][-1] 이랑 x[-1][i] 이랑 거꾸로 쓴거 하나때문에 상당히 오랫동안 디버깅 했었다 실제로 매매를 실행하는 프로그램을 드디어 만들때가 왔다 알고리즘이 완성되지 않았지만 일단 만들어서 매매를 시작하면 큰 동기부여가 되어 줄 것이고 기본적인 피쳐들만 고려해도 최소한 큰 손실을 보지는 않을 것이라고 생각한다. 베팅사이즈와 빈도도 적절히 제한하여 실행하면 될 것이다. 이론적으로 매매를 실제로 실행하는 프로그램은 어려운 파트가 아닐 것이다 키움 api에 접속하여 데이터를 받아들이거나 처리하는 기본적인 뼈대는 일전에 만들어보았기 때문에 초반에 헤메는 일도 이론상 없을 것이다 그러나 늘 그렇듯이 작업시간은 예측시간을 훨씬 넘어갈 ...

이번엔 트렌드처리하는 옛날에만든함수가 오작동하고 있다 데이터가 비어서 중간중간에 점프하는 구간이 있는데 거기서 슬라이딩윈도우가 정신을 못차리는것으로 추측된다 빨리 고치고 실전으로 좀 진입해보자...

데이터 10만개정도 처리하는데 세월아 네월아 하고있길래 아니도대체뭐가문제지 하고 구간마다 시간을 기록해서 더해서 합해서 어디서 차가막히는지 찾으려하는데 이걸 자주 반복하게되는 것 같아 이미 쓰던 디버깅에 도움을 주는 클래스를 좀 수정해 보았다 from datetime import datetime, timezone import inspect import time def QDEBUG(comment, variable): qDebug = DEBUGREPORT() qDebug.GING = True qDebug.report(comment, variable) class DEBUGREPORT: def __init__(self, GING=False, TEMP=False, timeCounterLabel=None): self.GING = GING # variable name can be DEBUG so that expression as DEBUG.GING == True can be used self.TEMP = TEMP self.ERR = "FLAG_ERROR_DEBUGREPORT" if timeCounterLabel == None: timeCounterLabel = inspect.currentframe().f_back.f_lineno self._timecounter = {timeCounterLabel: 0} self._lastRecordedTime = time.perf_counter() def timeMarker(self, flag_reset=False, timeCounterLabel=None): if flag_reset: self._timecounter = {} if timeCounterLabel == None: timeCounterLabel = inspect.currentframe().f_back.f_lineno # Get the current frame, then the caller's frame # Get the caller's line number currentTime = time.perf_counter() if timeCounterLabel in self._timecounter: ...

좀더 체계적인 기능테스트와 테스트결과를 기록하는 클래스의 필요성을 느꼈다 A기능 테스트-수정하고 다음 B기능을 테스트-수정하는 과정에서 A기능을 건드려버리면 A기능 계속 정상적으로 작동할지 아님 새로운 오류나 오차가 생겼을지 애매해진다 만약에 테스트를 그냥 다 모아서 한방에 해버려도 그 결과가 옳고 그름을 명백히 구분할 수 있는 프로그램이라면 그렇게 해도 괜찮겠지만, 큰 불확실성을 동반하는 예측 태스크는 프로그램이 올바르게 작동해도 결과적으로 실패하거나 그 반대의 경우도 발생하며 결과값 자체에 불확실성과 예측 불가성을 동반하기 때문에 중간중간에 들어가는 기능들이 정상적으로 작동하는지를 꾸준히 확인해줄 필요가 있는 듯 하다 이 때 과거 테스트 기록을 돌이켜 볼 필요가 있는 것 같아 testReport 클래스를 ...