Mega sena database

[SMcNeill]

And, to bring it all together:

Code: QB64: [Select]

1. DIM RecordOn AS LONG
2. IF _FILEEXISTS("temp.txt") THEN
3.     OPEN "temp.txt" FOR INPUT AS #1
4.     SEEK #1, LOF(1) - 18 'records are 19 bytes each, but last line won't have a CRLF.
5.     'Instead, the file ends with a EOF single byte character, so back up 18 spots instead of 19
6.     'I'm such an idiot not to notice the difference!  GAHHHH!!!
7.     RecordOn = LOF(1) \ 19 + 1
8.     INPUT #1, num1start
9.     INPUT #1, num2start
10.     INPUT #1, num3start
11.     INPUT #1, num4start
12.     INPUT #1, num5start
13.     INPUT #1, num6start
14.     num6start = num6start + 1
15.     PRINT "Resuming count from old file."
16.     loaded = -1
17.     CLOSE
18.     OPEN "temp.txt" FOR APPEND AS #1
19. ELSE
20.     OPEN "temp.txt" FOR OUTPUT AS #1
21. END IF
22. IF RecordOn < 50063830 THEN
23.  
24.     PRINT "Calculating further values..."
25.     PRINT "Press <ANY KEY> to stop."
26.  
27.     FOR num1 = 1 TO 55
28.         IF loaded THEN num1 = num1start
29.  
30.         FOR num2 = num1 + 1 TO 56
31.             IF loaded THEN num2 = num2start
32.  
33.             FOR num3 = num2 + 1 TO 57
34.                 IF loaded THEN num3 = num3start
35.  
36.                 FOR num4 = num3 + 1 TO 58
37.                     IF loaded THEN num4 = num4start
38.  
39.                     FOR num5 = num4 + 1 TO 59
40.                         IF loaded THEN num5 = num5start
41.  
42.                         FOR num6 = num5 + 1 TO 60
43.                             RecordOn = RecordOn + 1
44.                             IF loaded THEN num6 = num6start: loaded = 0
45.                             s$ = LTRIM$(STR$(num1)) + ","
46.                             IF num1 < 10 THEN s$ = "0" + s$
47.                             IF num2 < 10 THEN s$ = s$ + "0"
48.                             s$ = s$ + LTRIM$(STR$(num2)) + ","
49.                             IF num3 < 10 THEN s$ = s$ + "0"
50.                             s$ = s$ + LTRIM$(STR$(num3)) + ","
51.                             IF num4 < 10 THEN s$ = s$ + "0"
52.                             s$ = s$ + LTRIM$(STR$(num4)) + ","
53.                             IF num5 < 10 THEN s$ = s$ + "0"
54.                             s$ = s$ + LTRIM$(STR$(num5)) + ","
55.                             IF num6 < 10 THEN s$ = s$ + "0"
56.                             s$ = s$ + LTRIM$(STR$(num6))
57.                             LOCATE 5, 1: PRINT "Writing Record"; RecordOn; "of 50,063,860 combinations: "; s$
58.                             PRINT #1, s$
59.                             IF INKEY$ <> "" THEN PRINT: PRINT: PRINT "Terminated Program.  Calculation paused; run it again to resume list generation.": END
60.                         NEXT
61.                     NEXT
62.                 NEXT
63.             NEXT
64.         NEXT
65.     NEXT
66. END IF
67.  
68.  
69. PRINT "Dataset is fully created.  You can now work with it as you wish."
70. CLOSE
71. 'And now to add in the search routine to the same program, just for completeness.
72. 'Free free to modify this section so it can be used for whatever you need it to be for your own needs.
73.  
74. _DEFINE A-Z AS _INTEGER64
75. RANDOMIZE TIMER
76.  
77.  
78. OPEN "temp.txt" FOR INPUT AS #1
79.  
80. 'A demo of just listing all the numbers/combinations for us
81. FOR recordnumber = 1 TO 50063830
82.     SEEK #1, (recordnumber - 1) * 19 + 1
83.     LINE INPUT #1, t$
84.     PRINT "RECORD"; recordnumber; ":"; t$
85.     IF INKEY$ <> "" THEN EXIT FOR 'Escape to quit
86. NEXT
87.  
88.  
89. 'And a demo of how to get one particular value from the list:
90. DO
91.     PRINT
92.     PRINT
93.     DO
94.         INPUT "Give me a record number from 1 to 50063830 (0 quits):"; recordnumber
95.         IF recordnumber = 0 GOTO OutsideLoop
96.     LOOP UNTIL recordnumber > 0 AND recordnumber < 50063831
97.     SEEK #1, (recordnumber - 1) * 19 + 1
98.     LINE INPUT #1, t$
99.     PRINT "RECORD"; recordnumber; ":"; t$
100. LOOP
101.  
102. 'And a demo of randomly generating values using our list:
103. OutsideLoop:
104. PRINT
105. PRINT
106. FOR i = 1 TO 10
107.     recordnumber = INT(RND * 50063830) + 1
108.     SEEK #1, (recordnumber - 1) * 19 + 1
109.     LINE INPUT #1, t$
110.     PRINT "Random Drawing #"; i; ": "; t$
111. NEXT

EDIT:  One more correction, just because I'm an idiot and can't remember how files are structured on the drive -- even after all these years of working with them.

Our file here holds records which are 19 bytes in length -- 2 bytes for each number, 5 bytes for each comma, and (in Windows) 2 bytes for the CRLF after....

WITH ONE GLARING EXCEPTION: 

The last record doesn't have a CRLF at the end of it.  It has an EOF (CHR$(26) character, I think) character at the end of it -- which means we don't back up 19 spots from the end to get our last written value...  NOR do we back up 17 spots from the end to get our last written values...

We back up EIGHTEEN bytes from the end to get our last values!!

GAH!!  I feel like such an idiot now that I've sorted out what my biggest glitch was.  I knew this.  I just didn't think about it when writing the program and since the values are so large, I didn't do enough testing to catch the issue myself earlier...

Values like 12,13,14,15,16,17 were being read in as 2,13,14,15,16,17 as our restart point -- and that wasn't correct at all.  One byte offset makes a world of difference in file storage!

I'm thinking it works now.  Let's wait for Bplus to double test the results and confirm it, so I can I rule out I don't have other simple glitch that I've inadvertently got to sort out and correct still.  :P

[carloscordeiro]

Perfect, Steve

You two are great Programmers.
In the line "recordnumber = INT (RND * 50063830) + 1" I changed to 50063861 because it was not showing the ending. I'm learning more each day with you two.
Thank you very much.

CarlosCordeiro

[bplus]

Reply to #44, I see you've both posted since.

Hey Steve! I think you got it. Nice, and not terribly complicated.

I had given up after a couple more attempts tonight.

[SMcNeill]

Hey Steve! I think you got it. Nice, and not terribly complicated.

I had given up after a couple more attempts tonight.

I did have to edit it one more time to finally sort out my biggest gremlin with the code, which I edited the post above to reflect the changes.  You might want to go back and reread that message (you guys posted while I was editing and correcting the issue), and it explains what the main issue with getting our last values back for us was. 

I think it's all working as intended now, unless you can find an issue where it isn't.  ;)

[bplus]

If the last edit was -17, I did get that.

I ran your code first uninterrupted. Right record counts and a couple checks in file like 1000000th

Then ran your code with like 6 interruptions and then let it run to finish, last lines looked right, 1000000th and 2000000th were good.

OH! I wonder if the -17 was why I was getting weird results. I was going on -18... :)

[SMcNeill]

One interesting thing I noticed:  Over 80% of the numbers have  a value less than 15 in them, so if you start your lotto ticket with 15 being the lowest digit you bet on, that's already a 4 in 5 chance that you're going to lose right off the bat!

The reason?   

The higher the starting values, the less combinations you can make with those numbers...

Take a lotto with 4 digits from 1 to 6.

Start with 1 and it can show up in a lot of places:
1,2,3,4
1,2,3,5
1,2,3,6
1,3,4,5
1,3,4,6
1,3,5,6

But, start with the minimal value of 2, and it can't be in as many numbers:
2,3,4,5
2,3,4,6
2,4,5,6

And, if you start with the number 3, there's only one possible combination:
3,4,5,6

Of course, only one number is actually drawn, so all values have the same chance to appear...  It was just an odd quirk which I noticed, which I just thought I'd share, completely for the heck of it.  :P

[SMcNeill]

If the last edit was -17, I did get that.

I ran your code first uninterrupted. Right record counts and a couple checks in file like 1000000th

Then ran your code with like 6 interruptions and then let it run to finish, last lines looked right, 1000000th and 2000000th were good.

OH! I wonder if the -17 was why I was getting weird results. I was going on -18... :)

Last edit was to fix the -17 to the proper -18:

Code: QB64: [Select]

1.     SEEK #1, LOF(1) - 18 'records are 19 bytes each, but last line won't have a CRLF.
2.     'Instead, the file ends with a EOF single byte character, so back up 18 spots instead of 19
3.     'I'm such an idiot not to notice the difference!  GAHHHH!!!

The reason why it worked for 1,000,000 and 2,000,000, is the values returned:

01,04,13,23,30,60
01,07,16,42,44,26

If those were the last records written, and we backed up 17 spots from the end of file, what'd we retrieve would be:
01,04,13,23,30,60
01,07,16,42,44,26

Cutting off the 0 in these instances doesn't break anything, but it does once we end up getting to a value such as:
11,04,13,23,30,60

Not much difference between 01 and 1, but there's a huge difference between 11 and 1.  That single byte was throwing everything off, and I just couldn't seem to notice where the glitch was!  :)

[bplus]

Last edit was to fix the -17 to the proper -18:

Code: QB64: [Select]

1.     SEEK #1, LOF(1) - 18 'records are 19 bytes each, but last line won't have a CRLF.
2.     'Instead, the file ends with a EOF single byte character, so back up 18 spots instead of 19
3.     'I'm such an idiot not to notice the difference!  GAHHHH!!!

The reason why it worked for 1,000,000 and 2,000,000, is the values returned:

01,04,13,23,30,60
01,07,16,42,44,26

If those were the last records written, and we backed up 17 spots from the end of file, what'd we retrieve would be:
01,04,13,23,30,60
01,07,16,42,44,26

Cutting off the 0 in these instances doesn't break anything, but it does once we end up getting to a value such as:
11,04,13,23,30,60

Not much difference between 01 and 1, but there's a huge difference between 11 and 1.  That single byte was throwing everything off, and I just couldn't seem to notice where the glitch was!  :)

Hi Steve,

Crap! It WAS supposed to be -18??? I need a much better checker, maybe code one, maybe it was too late at nite and I was eager to wrap it up. I was thinking being off a byte was why the record counts were way off.

Well if it is supposed to be -18 I have to say, I don't like your CRLF theory/explanation.

To find a record you do this (from your own example):
SEEK #1, (recordnumber - 1) * 19 + 1

so get number for totalRecs = LOF(1) /19,
and it's
SEEK #1, (totalRecs-1) * 19 + 1 >>  19*LOF(1)/19 - 19 +1  >> LOF(1) - 18

which was how I was coming up with - 18.

We can easily verify one explanation or the other by reading the last 19 bytes of file. I bet there is a CRLF on last two.
yep,
 

WITH ONE GLARING EXCEPTION: 

The last record doesn't have a CRLF at the end of it.  It has an EOF (CHR$(26) character, I think) character at the end of it -- which means we don't back up 19 spots from the end to get our last written value...  NOR do we back up 17 spots from the end to get our last written values...

We back up EIGHTEEN bytes from the end to get our last values!!

GAH!!  I feel like such an idiot now that I've sorted out what my biggest glitch was.  I knew this.  I just didn't think about it when writing the program and since the values are so large, I didn't do enough testing to catch the issue myself earlier...

So Steve, your head must be spinning as badly as mine when I see it was suppose to be -18 not -17. Yikes!

I do like your explanation of why I didn't catch -17 wasn't working and will run another check running and interrupting much later, should throw record numbers off, I think.

Update: confirmed on -17, interrupted when running 11, 12..... and it started back up doing 1, 12, .... over again!

[bplus]

Update: confirmed on -18 and interrupted a number of times with double digit first numbers (including 10) and it started back at the correct position and wrote the correct amount of total combinations.

Carlos, I'd recommend reply #45 as best of this thread (except Steve's explanation of why -18 and not -17 is incorrect).
To get the Append Method to work, to pickup exactly where the code had left off in the listing of combinations, is a really smart demo! And ideally, you might want to say ahead of time exactly where you want to interrupt and investigate the file at your pre-specified stop point.

[carloscordeiro]

Hello bplus
Good morning, here in Brazil.
I'm passionate about Qbasic programming, even though I'm a beginner. I would like you to explain to me, in layman's words, what your image code get_bplus is showing, which does not show in the get_02 image.
Is there any flaw in Steve's # 45 code? Please, I'd love to know what the numbers in the Get_01 image mean. I do not want a ready code only, I want to understand a bit about the code.
We are human and we are wrong.
I noticed that Steve recognizes his mistakes, worthy of a human being.
Please take some time to answer my debts.


I apologize to the administrator for not having taken care to translate before posting. This will not happen again.

CarlosCordeiro

[odin]

Hi Carlos. The main language for forum discussion is English, please.

[Pete]

Fortunately, for you guys, I'm hard at work on my QB64 Universal Translator. Here's what I have so far...

Code: QB64: [Select]

1. LINE INPUT "What language do you want to say hello to the world in? "; lang$
2. PRINT "Type, " + CHR$(34) + "Hello World!" + CHR$(34) + " in the " + lang$ + " language: ";
3. LINE INPUT ; trans$
4. PRINT
5. PRINT "Translating, please wait..."
6. _DELAY 2
7. PRINT "Hello World!"
8. END

Pete :D

[bplus]

 

Code: QB64: [Select]

1.  
2. DIM fl AS _INTEGER64, i AS _INTEGER64, b AS STRING * 1 '<< len(b) is 1 byte always
3.  
4. IF _FILEEXISTS("temp.txt") THEN
5.     OPEN "temp.txt" FOR BINARY AS #11
6.     PRINT "file exits last 19 bytes are:"
7.     fl = LOF(11) '                 > this tells me the "temp.txt" file size in bytes = (single string characters)
8.     FOR i = fl - 18 TO fl '        > for the last 19 bytes in the temp.txt file
9.         GET #11, i, b '            > get here is not getting an image, it is getting a number of bytes = len(b) = 1
10.         PRINT b, ASC(b) '          > OK print the string then ASC(b) translates the character string to it's Ascii code number
11.     NEXT
12.     CLOSE #11
13. END IF
14. END
15.  
16. ' note on output:
17. ' CHR(13) = CR, Carriage Return, when printed it starts a new line , ASC(CR) = 13
18. ' CHR(10_ = LF, Line Feed, when printed it also starts a new line, ASC(LF) = 10
19. ' So the last two bytes of the file turn out to be a CR+LF
20.  
21.  

 

To sum this up, the temp.txt file does end with the CR+LF combination of characters.
Steve had determined the correct place where the last record starts but his explanation of why it is -18 was incorrect.

[SMcNeill]

So Steve, your head must be spinning as badly as mine when I see it was suppose to be -18 not -17. Yikes!

You’re right.  My explanation was incorrect.  The actual solution is so simple, I feel like an idiot now that I’m awake and have my morning coffee in me...

Files start count at position 1, not 0.  To get to ANY particular point, we need to add 1 to OFFSET that difference in position.

We see this when we SEEK #1, RecordNumber * 19 + 1.

When moving backwards, we do the same thing:  SEEK #1, LOF(1) - NumberOfBytes + 1.....

Which, in this case is with a 19 byte record:   SEEK #1, LOF(1) - 19 + 1....

Which, of course, simplifies down to SEEK #1, LOF(1) - 18

**************************

And, WHY my poor befuddled brain didn’t realize this sooner is beyond me.  I blame it on the stupid meds which I’m taking for my heart — ever since I’ve been on them, I’ve been in a stupor; living life with my brain in a fog.  Luckily, I’m down 64 pounds now, with only 56 more to go, before I can discuss surgery and getting off these damn medications... 

So here’s to hoping next year will be the year of my surgery, and then life can get back to a semblance of normality after.  ;)

[bplus]

Steve, to me, the more important issue of getting the Append Method to work far out weighs a mistaken explanation.
Pretty darn good for a "poor befuddled brain". :)

But we do have have to try and keep the record straight about how the file ends.