반응형
우연히 어떤게임을 알게됐다.
1. 나는 그게임을 다운 받았다.
2. 게임을 실행하려고 하니 컴사양이 달려서 뽑아놨던 비됴카드를 다시 달았다.
3. 윈도우가 부팅이 안된다.
4. 포맷했다.
5. C:드라이브와 D:드라이브가 바뀐체로 포맷이 돼있었다.
 기존에 사용하던 파티션은 c:50G d:100G였는데 포맷하고 보니
 c:100G d:50G... ㅠ_ㅠ 젠장...
6. 로또프로젝트 자료는 전부 D:드라이브에 있었다.
7. 그냥 다시포맷했다. c:50G d:100G로...
8. 게임은 재밌었다... ㅠ_ㅠ
저작자표시 비영리
반응형
자, 경우의 수는 모두 입력했다.

이제부터 할일은 814만건 중에서 당첨확률이 낮아 보이는 숫자를 선별하는 일이다.

기존에 로또 분석사례를 보니 당첨숫자 빈도수를 점검하는 방식으로 진행되는 것 같더라.

내가 사용할 방법은 기존에 당첨된 번호와 기당첨번호와 매우 유사한 숫자등을 선별하여

814만건의 데이터에서 추려내는 것 이다.

사실... 이 발상에도 한계는 있다. 말이 선별이지 선별의 기준도 좀 모호하고...

아무리 선별한다고 하여도 로또의 확률은 매회 1/814만 이기때문이다.

단지 편의상 기존에 당첨됐던 번호와 그 유사한 번호를 제외하는 방법을 사용했을 뿐이지...

아무튼 기당첨 번호 355건을 입력했고 그와 유사한 5자리의 번호를 체크했더니

(예를 들어 당첨번호가 1,2,3,4,5,6 이라면 1,2,3,4,5가 들어가는 모든 수 1,3,4,5,6이 들어가는 모든 수들)

대략 4만건정도가 쌓인다. 4자리 유사한 숫자와 기타 몇가지 특징이있는 숫자들을 제외할 생각인데...

처음에 구상할땐 백만건 이상 선별할 것으로 기대했으나 실제로 해보려니 그정도는 힘들 것 같다.^^

저작자표시 비영리
반응형
너무 느린 것 같아서 로직을 살짝 바꿨다.
조금 빨라진 것 같긴한데 그래도 속도가 마음에 안들어서 
(대충 보니까 1초에 200에서 300건정도 입력되는 듯...)

그냥 기존 로직을 샥뜯어 고쳐서 돌리니 30분도 안돼서 백만건이 훌쩍넘어 버렸다...

어떻게 했느냐 하면...

그냥 기존에 중복확인 함수를 빼버렸다.
그리고 숫자생성부분 로직을 고쳐서 그냥 중복수가 발생하지 않게 바꿔버려서 속도가 엄청 빨라졌다.

근데 나중에 전부 입력하고 중복되는 수가 있는지 확인해봐야함...
(아마도 중복수가 안생기리라 기대하고 있지만... 개발이란게 원래 맘먹은데로 쉽게 되는게 없는 거다.
저작자표시 비영리
반응형

프로그램을 만들어서 무한반복(까지는 아니고) 반복문으로 
로또 경우의 수 생성하고있다.
좀 많이 무식한 방법인데...

6자리의 숫자를 생성해서
① 생성된 숫자가 DB에 존재하는지 존재여부를 검색
② 존재하면 건너뛰고 존재하지 않으면 6자리 숫자를 DB에 입력
하는 아주 단순한 로직이다.

문제는 너무 단순하다 보니까 무조건 돌리기만 한다는 거...

중복되는 숫자를 제거하고 돌리다 보니 DB에 쌓인 데이터의 양이  4,5일정도 
돌렸음에도 불구하고 30만건을 겨우 넘는 정도였다.

숫자를 생성하는 속도자체는 큰 차이가 없지만 그것을 일일이 DB에 접근해서
유효한 것인지 아닌지를 판단하다 보니 속도가 엄청 느려졌다고나 할까?

그래서...
유효성판단하는 함수에 한가지를 더 추가했다.

(a)01,(b)02,(c)03,(d)04,(e)05,(f)06 번째 자릿수의 특징 중 하나가
뒷자릿수가 앞의 자릿수보다 작은수가 올 수 없다는 것이니...

무한생성시키고 있는 숫자중에 뒷자리가 앞자리 보다 작은 숫자들은
이미 기존에 입력된 값이 있는 중복된 값이기 때문에 무조건 무시하고
생성하기로 했더니...

4,5일간 30만건 생성했던 속도가 하룻밤만에 30만건을 생성하는게 아닌가... -_-;
앞으로 추가할 로직이 몇가지 더있긴 한데... 쩝...
저작자표시 비영리
반응형
로또예측프로그램 1차단계로 로또 경우의 수 생성 프로그램을 작성했다.

애당초에 825만건 정도의 경우의 수를 예상했으나 실제로 프로그램을 돌려보니

실제 생성될 데이터의 1/10도 생성되지 않았는데 3천만건이 넘게 생성되는 것이 아닌가???

아, 물론 큐브리드는 바보같아서 MSSQL로 바꿨더니 3천만건정도 되니까 큐브리드랑 비슷한 바보증세가 MSSQL

에서도 보이더라... (큐브리드는 200만건에서 바보가 됐었고 그래서 큐브리드가 가야할 길이 멀었다는 의미다...)

그래서 천만건은 커녕 억단위의 경우의 수를 예상하고 있었는데 아뿔사!!!!!!!!!!!!

테이블 설계를 [순서],[1],[2],[3],[4],[5],[6],[당첨회차] 이런 식으로 하고 루프를 돌렸는데

전혀 예상하지 못했던 실수가 있었다... 그것은 다름이 아니라...

1,2,3,4,5,6 이라는 경우의 수를 예로 든다면 1,2,3,4,5,6 과 2,3,4,5,6,1이나 3,4,5,6,1,2나 동일한 숫자는 순서에 상관없이

결국 같은 하나의 값이라는 결론이 예상된다... 이런... 난감한 실수를 할 줄이야...

중복데이터를 회피할 쿼리까지 만들기는 했지만... 시간관계상 마무리를 못했다...

오늘 컴백홈해서... 마무리를 지어야지.... (ㅠ_ㅠ)
저작자표시 비영리

+ Recent posts

티스토리툴바