반응형
우연히 어떤게임을 알게됐다.
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자리 유사한 숫자와 기타 몇가지 특징이있는 숫자들을 제외할 생각인데...

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

반응형
경우의 숫자 815만여건을 모두 만들었다.

아무래도 1부터 45까지 6자릿수의 경우의수를 반복해서 만드는 건 너무 오래걸리는 것 같아서

그냥 숫자생성로직을 초기화했다.

중복되는 숫자체크 확인 함수도 없애고 그냥

a,b,c,d,e,f에 대한 초기값1 대신

앞자리 + 1을 초기값으로 설정하고 한잠자고 일어나니 815만건정도의 데이터가 모두 입력돼있었다.

물론... 어찌된 영문인지 일주일넘게 켜놨던 데탑이 뻣어버리는 사태가 발생해서

회사출근도 째고 부시럭부시럭 거리며 서버를 살려놓고 DB에 접속해보니 내가 만들려고 했던 데이터가

완성되 있는 것이 아닌가...

바로 로또사이트 들어가서 로또 당첨기록 엑셀파일로 다운받아서 경우의 수에 당첨 회차 업데이트 했다. 

후후후 기본 소스는 만들어졌으니 슬슬 분석단계로 넘어가야 하는데...

사실 지금까지 만들어 놓은 것들은 기본 소스에 불과하고 지금부터가 진짜 라는거...

젠장 경우의 수 만들기는 정답이라도 있지만 이제부터는 답도 없는 아이디어의 세계다... ㅠ_ㅠ
반응형
너무 느린 것 같아서 로직을 살짝 바꿨다.
조금 빨라진 것 같긴한데 그래도 속도가 마음에 안들어서 
(대충 보니까 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나 동일한 숫자는 순서에 상관없이

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

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

오늘 컴백홈해서... 마무리를 지어야지.... (ㅠ_ㅠ)
반응형

큐브리드를 테스트해볼겸...
로또경우의 수 누적프로그램을 만들어서 돌려봤다.

결과? C#으로 프로그램을 좀 엉성하게 짜서그런지... 125만건 정도 입력하는데 하루가 넘게 걸렸다.
125만건을 누적하는데 걸린 시간이야 DB의 문제라기 보다는 내가 컴파일한 프로그램의 속도문제이니
별것 아닌데 문제는 큐브리드에서 125만건 정도 데이터가 누적되니...

DB메니져에서 조회쿼리를 날리면 메니져가 뻗어버린단 거다...
아마 언젠가 결과는 나오지 않을까 싶은 생각이 들기도하지만...
그걸 언제 기다리고있냔 거지...

로또발생프로그램은 그래도 계속 돌아가고 있는데 count(*)조회해보니 데이터 누적은 순조롭게 이뤄지는 듯 하다.
근데 누적이 순조로우면 뭐하나...

정작 메니져에서 조회도 못하는데...

따라서... 로또경우의 수 발생 프로젝트 잠정 보류.
다음번엔 MSSQL2005로 테스트해볼까?
반응형

C#으로 작성중인데...
내가 구상한 알고리즘은 아직 구체적이지는 않다.
단순히 [로또 6자리 45번까지 중복되는 수 없이 발생할 수 있는 모든 경우의 수를 DB화 한다.]는 것을 1차 목표로 삼고...
몇차례 테스트 후(이상하게 중복되는 수가 한개 정도 생기긴 하는데 귀찮아서 그냥 넘어가고 나중에 수동으로 지울 생각이다.)
루프를 돌려서 무한반복생성하고 있는 중이다.

보너스 숫자는 무시하고 6자리만 생성하는 것으로 하고 있는데...보너스는 어차피 6자리 선택이 우선시 되는 것이기 때문에
보너스 숫자까지 염두하기엔 나의 능력부족인지라... 아무튼 경우의 수를 발생하기 시작한지 2시간에서 3시간 정도 지난 지금...

DB에 생성된 데이터는 11만8천건 정도 되는데... 예상데이터의 1/10도 안되는 수치이다... ㅠ_ㅠ
내일 출근할때 까지도 생성이 안될 것 같다는 생각이 들 정도이니...

큐브리드를 C#에 붙여서 사용할 수 있게 된김에 테스트 삼아 돌리고 있긴 한데...
일단 연동은 잘되는 것 같다만 큐브리드 DB메니져가 조금 불편한 인터페이스다.
쿼리조회를 하니 한화면에 100건씩 조회가 되고 그이후는 페이지 넘김 방식이다.(쿼리 질의화면 에서)
게다가 한번에 5천건 단위로 조회할 때 마다 5천건이 넘는데 조회할거냐고 물어보는데 은근히 귀찮다.

옵션에서 메세지를 죽이는 기능을 찾으려고 했으나...

DB Manager에... 옵션이 없다... ㅠ_ㅠ

...
로또를 예상할 수 있는 경우의 수는 대략 800만건정도 이고...
현재 까지 14만5천건 생성됐고... 14만5천건 생성하는데 대략 2시간반정도 걸렸으니까...
경우의수 생성완료 예상 시간은 대략 4.8일 (115시간 정도) 되시것다...

시바... 경우의 수 생성 알고리즘이 후진건가 보다...

+ Recent posts