Post by: carloscordeiro on March 26, 2019, 08:22:59 pm
I'm trying to create a database with 50 million dozens of Mega Sena. But when it arrives at a certain point, the program will no longer check the number generated in the database. I ask for your help.
Follow the code in TXT.
Below is the purpose of this program.
1) Generate combination
2) Check if it already exists
3) If it does not exist, save
4) Return to step 1
thanks in advance
Post by: bplus on March 27, 2019, 09:54:39 am
I looked at your code and can not figure what is going on?
If you are generating combinations or permutations, there are certainly better ways than randomly making one up and then checking if you have it already.
Quote
But when it arrives at a certain point, the program will no longer check the number generated in the database.
This is likely caused by exceeding a limit for a variable type. If you can put a number on when the "certain point" occurs, it might indicate which variable needs a bigger type.
I noticed the program uses DEFINT A-Z making any undeclared variable type an integer which is pretty small for a program involving "millions". I would drop that line and let the default then be SINGLE precision which will give much more range.
For instance:
Code: QB64: [Select]
tamArq was NOT declared with a type so it takes default integer, my guess is the binary file will soon exceed integer limit of 32 thousand plus so use of the variable will cause errors.Welcome to the forum!
Append: I have looked up Mega Sensa, a Brazil Lottery pick numbers 1 to 60
https://en.wikipedia.org/wiki/Mega-Sena
Quote
When 6 unique 2 digit numbers are drawn, the drawing is concluded.Yikes! that seems complicated.
Betting
Contestants may bet in the range of 6 to 15 numbers, out of 60, and scoring 4, 5 or 6 points will grant prizes. Bet prices escalate depending on how many possible groups of 6 numbers exist within the numbers chosen, so they vary between R$3.50 for 6 numbers (only 1 game possible) to R$17,517.50 for 15 numbers (5005 games possible). The chances of winning the biggest prize when placing a minimum bet are 1 in 50,063,860.
As I understand this lottery:
So if you pick 6 numbers and they all hit, that's a bigger (the biggest prize) but if you pick 12 numbers and 6 hit that's a way smaller prize. ?
Post by: johnno56 on March 27, 2019, 05:32:47 pm
One can hardly use a program, such as this, to actually generate lottery number ticket entries. If this program generates 'millions' of combinations, it would be self defeating, as the shear cost of the tickets... ('millions' x $ per ticket).... I'm over-thinking this again aren't I? (beat ya to it bplus... lol)
Post by: carloscordeiro on March 27, 2019, 06:37:24 pm
Thanks for answering.
I am generating combinations to confront Brazilian mathematicians. They say the chance to win the lottery is from 1 to 50,063,860. I decided to develop this program to generate 50,063,860.
I'm having a hard time making it generate without repeating any combination. I do not have much experience with Qbasic.
I removed the DEFINT AZ line, and continued generating repeated combinations
I ask for help on how to do it better than mine.
Attached is the code that checks whether 50,063,860 will fall into the draw of the week.
Post by: bplus on March 27, 2019, 07:23:35 pm
It is 60! (which is 60*59*58*57*56*.... *3*2*1) divided by (6!)*(54!) my Windows calculator tells me this is 50,063,860 (Thanks Qwerky for alerting me to N! in the Window's calculator.)
Why do you need to write every one down?
Generating them randomly will never assure you have every one.
Post by: carloscordeiro on March 27, 2019, 09:10:27 pm
I have no hurry. Even if the PC takes 3 months to run RANDOMIZE TIMER, I hope it will exit this sequence.
I'd love your help, to change some line of code that is not as it should.
Post by: bplus on March 28, 2019, 09:08:46 am
There is a way to systematically list 60! Permutations* BUT 60! permutations is:
But to systematically list combinations for r groups in smaller sets of n elements (say, 10 with 3,628,800 permutations or less) is interesting program challenge.
Challenge is to code this system of counting in order Combinations!
Code: QB64: [Select]
- 4 elements
- 1, 2, 3, 4 taken 2 at a time
- systematic and ordered
- 1, 2
- 1, 3
- 1, 4
- 2, 3
- 2, 4
- 3, 4
- 6 combinations: check rCn = 4! / (2! * 2!) = 4*3*2 / (2*2) = 6
- 5 elements 3 at a time
- 1, 2, 3
- 1, 2, 4
- 1, 2, 5
- 1, 3, 4
- 1, 3, 5
- 1, 4, 5
- 2, 3, 4
- 2, 3, 5
- 2, 4, 5
- 3, 4, 5
- 10 combinations: check rCn = 5! /(3! * 2!) = 5*4*3*2 / (3*2 * 2) = 5*2 = 10
- 7 elements 3 at a time rCn = 35
- 1, 2, 3
- 1, 2, 4
- 1, 2, 5
- 1, 2, 6
- 1, 2, 7
- 1, 3, 4
- 1, 3, 5
- 1, 3, 6
- 1, 3, 7
- 1, 4, 5
- 1, 4, 6
- 1, 4, 7
- 1, 5, 6
- 1, 5, 7
- 1, 6, 7 16
- 2, 3, 4
- 2, 3, 5
- 2, 3, 6
- 2, 3, 7
- 2, 4, 5
- 2, 4, 6
- 2, 4, 7
- 2, 5, 6
- 2, 5, 7
- 2, 6, 7 +10
- 3, 4, 5
- 3, 4, 6
- 3, 4, 7
- 3, 5, 6
- 3, 5, 7
- 3, 6, 7 +6
- 4, 5, 6
- 4, 5, 7 +2
- 5, 6, 7 +1
- 35 combinations: rCn = 7*6*5 / 3*2 = 35
* The way is to count in base 60 and remove all numbers where a "digit" was used more than once.
Post by: bplus on March 28, 2019, 09:51:41 am
This is doable!
Post by: SMcNeill on March 28, 2019, 10:06:26 am
Code: QB64: [Select]
- PRINT "Calculating..."
This will generate all the possible 50 million possibilities and save them to a file called "temp.txt" on your hard drive. From just a little output, it's quite easy to see how it's working:
Code: QB64: [Select]
- 01,02,03,04,05,06
- 01,02,03,04,05,07
- 01,02,03,04,05,08
- 01,02,03,04,05,09
- 01,02,03,04,05,10
- 01,02,03,04,05,11
- 01,02,03,04,05,12
- 01,02,03,04,05,13
- 01,02,03,04,05,14
- 01,02,03,04,05,15
- 01,02,03,04,05,16
- 01,02,03,04,05,17
- 01,02,03,04,05,18
- 01,02,03,04,05,19
- 01,02,03,04,05,20
- 01,02,03,04,05,21
- 01,02,03,04,05,22
- 01,02,03,04,05,23
- 01,02,03,04,05,24
- 01,02,03,04,05,25
- 01,02,03,04,05,26
- 01,02,03,04,05,27
- 01,02,03,04,05,28
- 01,02,03,04,05,29
- 01,02,03,04,05,30
- 01,02,03,04,05,31
- 01,02,03,04,05,32
- 01,02,03,04,05,33
- 01,02,03,04,05,34
- 01,02,03,04,05,35
- 01,02,03,04,05,36
- 01,02,03,04,05,37
- 01,02,03,04,05,38
- 01,02,03,04,05,39
- 01,02,03,04,05,40
- 01,02,03,04,05,41
- 01,02,03,04,05,42
- 01,02,03,04,05,43
- 01,02,03,04,05,44
- 01,02,03,04,05,45
- 01,02,03,04,05,46
- 01,02,03,04,05,47
- 01,02,03,04,05,48
- 01,02,03,04,05,49
- 01,02,03,04,05,50
- 01,02,03,04,05,51
- 01,02,03,04,05,52
- 01,02,03,04,05,53
- 01,02,03,04,05,54
- 01,02,03,04,05,55
- 01,02,03,04,05,56
- 01,02,03,04,05,57
- 01,02,03,04,05,58
- 01,02,03,04,05,59
- 01,02,03,04,05,60
- 01,02,03,04,06,07
First, all the possible numbers starting with 1, 2, 3, 4, 5...
Then all the possible numbers starting with 1, 2, 3, 4, 6...
And so on, until we generate the whole list and save it on our drive as single line text combinations.
Post by: bplus on March 28, 2019, 10:14:05 am
If you want a list of all the possible combinations, then what you want is something like the following:Code: QB64: [Select]
This will generate all the possible 50 million possibilities and save them to a file called "temp.txt" on your hard drive. From just a little output, it's quite easy to see how it's working:Code: QB64: [Select]
First, all the possible numbers starting with 1, 2, 3, 4, 5...
Then all the possible numbers starting with 1, 2, 3, 4, 6...
And so on, until we generate the whole list and save it on our drive as single line text combinations.
There you go carloscordeiro, there's your program! ^^^^^^^^^^^^^^^^^^^^^^^^^^^
You not only have a list of Combinations, you have an ordered list!
Thanks Steve, my project for this morning is done. :) (Back to Star Wars crawl.)
Post by: SMcNeill on March 28, 2019, 10:40:34 am
Code: QB64: [Select]
- PRINT "Calculating..."
- n = n + 1
Note the total percent completion isn't correct -- it's mainly there to give you something to look at while its generating combinations for you. Our numbers start with 1 (and whatever digits next) and percentages start at 0%, and 1/55 isn't going to give us a 0% completion starting point. It can be corrected easily enough, but I figure the program is slow enough already just generating all the possible combinations and printing what it does to the screen -- no need for it to do any more math than necessary.
From start to finish, I guesstimate that this will take about an hour to generate all the possible combinations and store them in memory for you, so if you're actually going to use these values for some lotto program, then you may want to save them in a file as I did originally so all you have to do is access it to get the corresponding combination. (For example, a random access file of 50 million values, and then you just need a single RND call to look at that record and see what all 6 numbers would be.)
Memory requirements, in this case, is 50 million records * 8 bytes per record (I'm using an integer64 to hold the values), so about 400MB (plus a little internal overhead) to hold them all in memory, so keep that in mind for whatever else you might need to do with the rest of your program. ;)
Post by: bplus on March 28, 2019, 01:34:27 pm
But access to the end of the file was tricky, NotePad++ kept crashing when I do something like Crtl + End or GO line number near the end.
So I tried access by INPUT, way to slow!
So I had to figure out Random access again, it's been years! Got it fast!
Code: QB64: [Select]
- 'since Notepad++ dies when I try to access lines past 50 million but it does say there are the right amount of lines
- ''this method way too slow
- 'OPEN "6 Combos from 60 Numbers.txt" FOR INPUT AS #1 'I changed name of file from temp.txt
- 'WHILE NOT EOF(1)
- ' LINE INPUT #1, fline$
- ' i = i + 1
- ' IF i > 50063830 THEN
- ' PRINT i, fline$
- ' ELSEIF i < 40 THEN 'chck a print
- ' PRINT i, fline$
- ' ELSE
- ' IF i MOD 1000000 = 0 THEN
- ' CLS
- ' PRINT i \ 1000000; "millions lines"
- ' END IF
- ' END IF
- ' '_LIMIT 1000
- 'WEND
- TYPE record
- PRINT i, rec.f1
- CLOSE #1
Post by: SMcNeill on March 28, 2019, 03:57:42 pm
To make use of that sequential text file, I’d suggest using SEEK to go directly to the proper record.
Each record is a fixed size: 2 digits for each of the six numbers, five digits for the comma, 2 digits for the CRLF at the end of the line (for files created in WINDOWS, else CRLF is 1 digit).
19 characters per result, and we start at byte 1 for file access, instead of 0, which gives us:
RecordPosition = (RecordNumber - 1) * 19 + 1
First Record starts at byte (1 - 1) * 19 + 1 = 1
Second Record starts at byte (2 - 1) * 19 + 1 = 20
So to go directly to a record in that file:
OPEN “temp.txt” FOR INPUT AS #1
.... stuff
SEEK #1, (RecordNumber - 1) * 19 + 1
FOR i = 1 TO 6
INPUT Ball(i)
NEXT
.... CLOSE
Post by: bplus on March 28, 2019, 04:20:47 pm
But I am happy to have successfully reviewed Random access.
Post by: carloscordeiro on March 28, 2019, 07:07:04 pm
I am very grateful to bplus and SMcNeill for responding and creating ways to generate the combinations.
Like bplus, I used the first listing, I had a file written in about 10 minutes!
I got wheel bplus Random Access, now for the SMcNeill query
OPEN "temp.txt" FOR INPUT AS # 1
.... stuff
SEEK # 1, (RecordNumber - 1) * 19 + 1
FOR i = 1 TO 6
INPUT Ball (i)
NEXT
CLOSE
I gave a mistake
I ask SMcNeill, is your code incomplete?
Following is an image of the error,
I will be very grateful if you can send the code for consultation
Post by: carloscordeiro on March 29, 2019, 06:27:00 pm
OPEN "temp.txt" FOR INPUT AS # 1
.... stuff
SEEK # 1, (RecordNumber - 1) * 19 + 1
FOR i = 1 TO 6
INPUT Ball (i)
NEXT
CLOSE
Thank you very much for your help, and for SMcNeill.
CarlosCordeiro.
Post by: SMcNeill on March 29, 2019, 07:03:13 pm
bplus, please, please, tell me what comes before .... dot
OPEN "temp.txt" FOR INPUT AS # 1
.... stuff
SEEK # 1, (RecordNumber - 1) * 19 + 1
FOR i = 1 TO 6
INPUT Ball (i)
NEXT
CLOSE
Thank you very much for your help, and for SMcNeill.
CarlosCordeiro.
The ...stuff was there so you could insert whatever you needed into your code to work with the values on hand.
For a working illustration of how to handle the text file using SEEK and INPUT, here's an example for you:
Code: QB64: [Select]
- 'A demo of just listing all the numbers/combinations for us
- 'And a demo of how to get one particular value from the list:
- INPUT "Give me a record number from 1 to 50063830 (0 quits):"; recordnumber
- 'And a demo of randomly generating values using our list:
- OutsideLoop:
Note: You'll need the temp.txt file which was generated previously to run this demo.
Post by: bplus on March 29, 2019, 07:22:41 pm
bplus, please, please, tell me what comes before .... dot
OPEN "temp.txt" FOR INPUT AS # 1
.... stuff
SEEK # 1, (RecordNumber - 1) * 19 + 1
FOR i = 1 TO 6
INPUT Ball (i)
NEXT
CLOSE
Thank you very much for your help, and for SMcNeill.
CarlosCordeiro.
Hi CarlosCordeiro.
Yes I was hoping Steve would fill in about the "... stuff". Thanks Steve
Post by: carloscordeiro on March 29, 2019, 07:25:22 pm
A great evening.
CarlosCordeiro
Post by: carloscordeiro on April 02, 2019, 08:33:10 pm
Not wanting to be Inconvenient, could you exemplify how do I end part of the sequence and start over again where She stopped? Let's say I want to populate the temp.txt file with Intervals without it losing its order.
I mean, insert 1 million today, then 2 million more, until you reach 50 million.
It is very important to me.
Appreciate.
PRINT "Calculating..."
OPEN "temp.txt" FOR OUTPUT AS #1
FOR num1 = 1 TO 55
LOCATE 5, 3: PRINT num1,
FOR num2 = num1 + 1 TO 56
LOCATE 5, 5: PRINT num2,
FOR num3 = num2 + 1 TO 57
LOCATE 5, 7: PRINT num3,
FOR num4 = num3 + 1 TO 58
LOCATE 5, 9: PRINT num4,
FOR num5 = num4 + 1 TO 59
LOCATE 5, 11: PRINT num5,
FOR num6 = num5 + 1 TO 60
LOCATE 5, 13: PRINT num6
s$ = LTRIM$(STR$(num1)) + ","
IF num1 < 10 THEN s$ = "0" + s$
IF num2 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num2)) + ","
IF num3 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num3)) + ","
IF num4 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num4)) + ","
IF num5 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num5)) + ","
IF num6 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num6))
PRINT #1, s$
NEXT
NEXT
NEXT
NEXT
NEXT
NEXT
Post by: bplus on April 03, 2019, 09:53:15 am
Good night, Steve.
Not wanting to be Inconvenient, could you exemplify how do I end part of the sequence and start over again where She stopped? Let's say I want to populate the temp.txt file with Intervals without it losing its order.
I mean, insert 1 million today, then 2 million more, until you reach 50 million.
It is very important to me.
Appreciate.
PRINT "Calculating..."
OPEN "temp.txt" FOR OUTPUT AS #1
FOR num1 = 1 TO 55
LOCATE 5, 3: PRINT num1,
FOR num2 = num1 + 1 TO 56
LOCATE 5, 5: PRINT num2,
FOR num3 = num2 + 1 TO 57
LOCATE 5, 7: PRINT num3,
FOR num4 = num3 + 1 TO 58
LOCATE 5, 9: PRINT num4,
FOR num5 = num4 + 1 TO 59
LOCATE 5, 11: PRINT num5,
FOR num6 = num5 + 1 TO 60
LOCATE 5, 13: PRINT num6
s$ = LTRIM$(STR$(num1)) + ","
IF num1 < 10 THEN s$ = "0" + s$
IF num2 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num2)) + ","
IF num3 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num3)) + ","
IF num4 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num4)) + ","
IF num5 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num5)) + ","
IF num6 < 10 THEN s$ = s$ + "0"
s$ = s$ + LTRIM$(STR$(num6))
PRINT #1, s$
NEXT
NEXT
NEXT
NEXT
NEXT
NEXT
Hi carloscordeiro,
I see your question addressed to Steve, but Steve not answering (yet). So I will try to assist.
You can create more files or applications based on using the file created from code above as a source of data.
For example create a file with first million, then create a file with 2nd million and so on... or just load an array with a million items randomly selected or in blocks and do what you want with it.
Steve gave you the code, keys to accessing that file's data, for whatever purpose you might use that data for (see reply #16).
Post by: carloscordeiro on April 03, 2019, 08:12:44 pm
Thanks for answering for Steve.
I want to create a single temp.txt file, which I support inserting every million in intervals. For example, I enter 1 million today, another 2 million tomorrow until I get 50 million in the same temp.txt file.
CarlosCordeiro
Post by: jack on April 03, 2019, 09:26:22 pm
Post by: bplus on April 03, 2019, 09:42:07 pm
Do you think this will do that?
Code: QB64: [Select]
- PRINT "Calculating..."
- count = count + 1
Edit: I was off by 1 when I tested by 10's, fixed.
Post by: FellippeHeitor on April 03, 2019, 09:50:55 pm
Post by: bplus on April 03, 2019, 10:02:25 pm
I have nothing to do with this, but why again?
;-))
I have the 2nd day ending with
01,07,16,42,44,46
the 2 millionth entry
Post by: carloscordeiro on April 03, 2019, 10:22:01 pm
Thanks again to bplus. The code resumes where it stopped, but does not continue to count 1 million, it returns to the beginning.
CarlosCordeiro
Post by: bplus on April 03, 2019, 10:37:04 pm
Thank you very much, that's exactly what I want Jack. Write 1 million lottery numbers in a text file and then suspend the operation, so the next few days pick up where you left off and add another million numbers a day until you finish.
Thanks again to bplus. The code resumes where it stopped, but does not continue to count 1 million, it returns to the beginning.
CarlosCordeiro
On day 2 enter 2 not 1, here is my transition: [ This attachment cannot be displayed inline in 'Print Page' view ]
Post by: carloscordeiro on April 03, 2019, 11:10:29 pm
I'm sorry if I'm getting inconvenient
CarlosCordeiro
Post by: bplus on April 03, 2019, 11:19:31 pm
Bplus, on day 2 it will resume the sequence of 1,2,3,4,5,6. If the code could start from 01,04,13,23,30,59. So there would be no need to go back to the beginning. My intention would be this.
I'm sorry if I'm getting inconvenient
CarlosCordeiro
Start Over!
Erase temp.txt
day 1 enter 1 at this prompt
INPUT "Enter which million we are appending today ", millions 'day 1 say 1, day 2 say 2...
day 2 enter 2 at this prompt
INPUT "Enter which million we are appending today ", millions 'day 1 say 1, day 2 say 2...
then all will work. :)
If you mess up, the code will just keep adding the new section onto the old reguardless if it is where you wanted it or not.
The code is NOT rewriting the file but only adding on to the end of it.
BTW the code has been fixed, because it was 1 off of a million, use the current code in my last code listing posted in this thread, Reply #23.
Post by: bplus on April 03, 2019, 11:45:58 pm
Now it does rewrite the file every day!
Code: QB64: [Select]
Post by: SMcNeill on April 03, 2019, 11:53:12 pm
First, look to see if the file exists. If not, all the loops numbers start at 1. If it does, read the last set of numbers into the program and continue:
Code: QB64: [Select]
- num6start = num6start + 1
Now change the loops to start with that start variable value:
FOR num1 = num1start to 55
FOR num2 = num2start to 56
.....so on for 3,4,5,6
Then after the NEXT statements, reset the start values to their proper value:
NEXT num6
num6start = num5 + 1
NEXT num5
num5start = num4 + 1
NEXT num4
num4start = num3 + 1
....and so on.
Add an exit condition in the middle loop after the PRINT #1 statement such as:
IF INKEY$ <> “” THEN END
Then you can build, stop, and resume building that list whenever you want.
Post by: carloscordeiro on April 05, 2019, 06:36:33 pm
Thanks to bplus and Steve for the kindness to create the codes I needed.
Thanks also for taking the time to help. Both codes are working the way I wanted them to.
If Mr. FellippeHeitor does not feel uncomfortable. I wanted to ask for a final help from bplus or Steve.
I want to modify the line: IF INKEY $ <> "" THEN END without the end and without goto.
I want it to continue in Steve's reading code in reply (Reply # 16 from the forum).
Here's the image of bplus and Steve codes working perfectly.
It also follows the only code with the creation of the file and reading for bplus or Steve shows how to redirect the "Esc" to the reading line.
I reiterate the apology to Mr. FellippeHeitor if he feels uncomfortable.
Thanks Bplus and Steve
CarlosCordeiro
Post by: FellippeHeitor on April 05, 2019, 11:15:02 pm
If Mr. FellippeHeitor does not feel uncomfortable. I wanted to ask for a final help from bplus or Steve.
(...)
I reiterate the apology to Mr. FellippeHeitor if he feels uncomfortable.
I imagine this comes from my comment:
Quote
I have nothing to do with this, but why again?
I just asked because I honestly wanted to understand the purpose of the number generation, not because the thread bothered me in any way, shape or form.
Mr. FellippeHeitor just happens to be a forum member with elevated privileges, but this community is something on its own, meaning I have no veto powers whatsoever (nor do I want them). You are welcome and free to discuss your code, request help and get help from others. This is your community too.
All the best,
Fica tranquilo, bicho grilo.
Fellippe.
Post by: bplus on April 06, 2019, 10:05:20 am
Quote
Mr. FellippeHeitoris better than gold!
Easiest fix:
First, look to see if the file exists. If not, all the loops numbers start at 1. If it does, read the last set of numbers into the program and continue:Code: QB64: [Select]
Now change the loops to start with that start variable value:
FOR num1 = num1start to 55
FOR num2 = num2start to 56
.....so on for 3,4,5,6
Then after the NEXT statements, reset the start values to their proper value:
NEXT num6
num6start = num5 + 1
NEXT num5
num5start = num4 + 1
NEXT num4
num4start = num3 + 1
....and so on.
Add an exit condition in the middle loop after the PRINT #1 statement such as:
IF INKEY$ <> “” THEN END
Then you can build, stop, and resume building that list whenever you want.
"Easiest fix" ? :-))
Carlos, if I fix this:
Code: QB64: [Select]
- num6start = num6start + 1
- 'Those values are all set to 1, 2, 3, 4, 5, 6
- PRINT "Calculating..."
- num6start = num5 + 1
- num5start = num4 + 1
- num4start = num3 + 1
- num3start = num2 + 1
- num2start = num1 + 1
- CLOSE #1
- 'Apenas listar todos os numeros / combinacoeses
- 'Para obter um valor especifico da lista:
- INPUT "Digite um Numero de 1 a 50063830:"; recordnumber
- 'Gerando aleatoriamente valores usando nossa lista:
- OutsideLoop:
and if it helps you win the jackpot, you will remember me right? ;-))
and the person who helps me help you by translating the comments to the code blocks, so I know what it is exactly the code is trying to accomplish, remember that person too.
Post by: bplus on April 06, 2019, 12:58:20 pm
Going back to fool proof method!
Post by: bplus on April 06, 2019, 02:14:31 pm
Code: QB64: [Select]
- 'remove Steve's Append Method, replace with B+ Fool Proofed Method
- recsDesired = maxRecord
- PRINT "press any to continue..."
- PRINT "Calculating records..."
- count = count + 1
- GOTO skipOut
- skipOut:
- CLOSE #1
- ' What really should happen is to write the data file once with something like the above code
- ' and then access the file whenever with the code below.
- 'Apenas listar todos os numeros / combinacoeses >>> List all combinations, yuck too many!
- ' show last 10 listings
- 'Para obter um valor especifico da list >>> to get a specific value from the list, why? eh... OK
- 'Carlos, you can not access record 50063860 unless you have that many in file
- INPUT " "; recordnumber
- 'Gerando aleatoriamente valores usando nossa lista >>> Randomly Generating values using our list:
- 'Carlos, can only access records up to number in file NOT 50063860
- 'recordnumber = 63074 'check one known record OK
But the mystery continues, why rewrite the data file?
Post by: SMcNeill on April 06, 2019, 05:11:52 pm
Holy ship! Steve's Append Method is a disaster, it does not end like this:
Going back to fool proof method!
Not a disaster; just off with a very tiny bit of file logic:
Code: QB64: [Select]
- num6start = num6start + 1
- PRINT "Resuming count from old file."
- num1start = 1
- num2start = 2
- num3start = 3
- num4start = 4
- num5start = 5
- num6start = 6
- PRINT "Calculating further values..."
- PRINT "Press <ANY KEY> to stop."
- num6start = num5start + 1
- num5start = num4start + 1
- num4start = num3start + 1
- num3start = num2start + 1
- num2start = num1start + 1
The above works as intended and allows you to stop and resume list generation however you want. The change necessary for the example I posted to work was this simple:
Change this:
Code: QB64: [Select]
To:
Code: QB64: [Select]
I would've thought all the lines in the program would have a CRLF set at the end of them, but that doesn't hold true for the last record in the list. It simply ends, so we back up 17 spots instead of 19 to get the proper values for us. An easy thing to overlook without actually running and testing the code, but it seems to fix the issue for me, (Unless further testing shows another glitch somewhere that I just haven't found yet, which is always possible...)
Post by: carloscordeiro on April 06, 2019, 05:24:57 pm
Good night
Should I win the prize? Of course I will remember you bplus. You and Steve deserve it, for dedicating yourself to a newcomer like me. Just send the account number. :)
I am not trying to rewrite the data file.
I was trying to put in the only code, the two codes that you and Steve created for me.
The code that generates the combinations and the code that read the combinations.
In a single code, the two codes together into one.
With a Loop, more with the IF INKEY $ <> "" THEN END in the end for when I want to leave.
I ran the latter and it made a mistake on the line that is Seek
CarlosCordeiro
Post by: carloscordeiro on April 06, 2019, 05:32:26 pm
Post by: SMcNeill on April 06, 2019, 05:48:50 pm
Code: QB64: [Select]
- num6start = num6start + 1
- PRINT "Resuming count from old file."
- num1start = 1
- num2start = 2
- num3start = 3
- num4start = 4
- num5start = 5
- num6start = 6
- PRINT "Generating values in new 'temp.txt' file."
- PRINT "Calculating further values..."
- PRINT "Press <ANY KEY> to stop."
- num6start = num5 + 1
- num5start = num4 + 1
- num4start = num3 + 1
- num3start = num2 + 1
- num2start = num1 + 1
Post by: bplus on April 06, 2019, 08:45:06 pm
Slight correction to remove some duplicate values from our list generation. It's a little bit trickier than I first imagined, but I think this does it properly for us:Code: QB64: [Select]
Ran your code uninterrupted and it seems to be ending correctly but the record numbers are way, way off!
There should be 50,063,860 combinations, this shows less than 34 millions.
Note: my last 10 lines shown above include 0 combinations starting at 52, you have 4.
The way I count, missing by 15 million is a disaster.
Post by: bplus on April 06, 2019, 09:00:58 pm
Hello bplus
Good night
Should I win the prize? Of course I will remember you bplus. You and Steve deserve it, for dedicating yourself to a newcomer like me. Just send the account number. :)
I am not trying to rewrite the data file.
I was trying to put in the only code, the two codes that you and Steve created for me.
The code that generates the combinations and the code that read the combinations.
In a single code, the two codes together into one.
With a Loop, more with the IF INKEY $ <> "" THEN END in the end for when I want to leave.
I ran the latter and it made a mistake on the line that is Seek
CarlosCordeiro
Yes having code that reads the file you just made is fine! But you can not skip making the file first before trying to read it. :-))
Your snapshot shows the last line to be the first record. If you input only 1 line in at the beginning, that is only 1 combination you had the code make. To show last 10 lines, you need to enter at least 10, at the beginning of program. It is no longer doing millions but exactly how many lines you want.
You are right, you never said anything about rewriting file. I slipped into that thinking having so much trouble working with Steve's Append method.
Steve, It is a valiant and intriguing attempt, it was not easy to go back to fool proof which apparently was not fool proof enough. ;-))
Good luck to us, Carlos! :)
Post by: carloscordeiro on April 06, 2019, 11:11:33 pm
Another question I have, is it possible to put a line with some command to show the number of combinations registered in the temp.txt file?
For example:
If I want to add in a variable A = numbers of combinations registered in temp.txt.
How to create this line?
Regardless of having reached the end of the 50 million
It seems like I'm asking too much. Oo
Post by: SMcNeill on April 06, 2019, 11:37:28 pm
Really bplus, there's a little flaw in Steve's last code, but I think he'll be fixing it.
Another question I have, is it possible to put a line with some command to show the number of combinations registered in the temp.txt file?
One more shot at this -- I was overthinking my process on loading the values and getting things glitched with complexity. Let's see if this doesn't do what it's supposed to, and what you asked for it to do with the number of combinations written:
Code: QB64: [Select]
Post by: SMcNeill on April 06, 2019, 11:48:40 pm
Code: QB64: [Select]
- 'Instead, the file ends with a EOF single byte character, so back up 18 spots instead of 19
- 'I'm such an idiot not to notice the difference! GAHHHH!!!
- num6start = num6start + 1
- PRINT "Resuming count from old file."
- loaded = -1
- PRINT "Calculating further values..."
- PRINT "Press <ANY KEY> to stop."
- RecordOn = RecordOn + 1
- PRINT "Dataset is fully created. You can now work with it as you wish."
- 'And now to add in the search routine to the same program, just for completeness.
- 'Free free to modify this section so it can be used for whatever you need it to be for your own needs.
- 'A demo of just listing all the numbers/combinations for us
- 'And a demo of how to get one particular value from the list:
- INPUT "Give me a record number from 1 to 50063830 (0 quits):"; recordnumber
- 'And a demo of randomly generating values using our list:
- OutsideLoop:
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
Post by: carloscordeiro on April 07, 2019, 12:18:39 am
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
Post by: bplus on April 07, 2019, 12:20:31 am
Hey Steve! I think you got it. Nice, and not terribly complicated.
I had given up after a couple more attempts tonight.
Post by: SMcNeill on April 07, 2019, 12:23:58 am
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. ;)
Post by: bplus on April 07, 2019, 12:36:05 am
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... :)
Post by: SMcNeill on April 07, 2019, 12:46:27 am
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
Post by: SMcNeill on April 07, 2019, 12:52:34 am
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]
- 'Instead, the file ends with a EOF single byte character, so back up 18 spots instead of 19
- '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! :)
Post by: bplus on April 07, 2019, 09:33:11 am
Last edit was to fix the -17 to the proper -18:Code: QB64: [Select]
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,
Quote
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!
Post by: bplus on April 07, 2019, 10:39:35 am
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.
Post by: carloscordeiro on April 07, 2019, 11:28:32 am
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
Post by: odin on April 07, 2019, 11:38:53 am
Post by: Pete on April 07, 2019, 12:06:23 pm
Code: QB64: [Select]
Pete :D
Post by: bplus on April 07, 2019, 12:34:35 pm
Code: QB64: [Select]
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.
Post by: SMcNeill on April 07, 2019, 01:48:49 pm
Quote
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. ;)
Post by: bplus on April 07, 2019, 02:10:42 pm
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.
Post by: carloscordeiro on April 07, 2019, 05:38:44 pm
I just have to thank you both, it's two being that showed dedication in creating a code for a newcomer in the forum.
Steve, I wish you well and get your health back.
Bplus continues to be this persevering guy, helping to discover code failures and tried to solve.
Thank you very much.
I reiterate the apology to the administrator for not having the care to translate before posting. This will not happen again.
CarlosCordeiro
Post by: carloscordeiro on April 15, 2019, 09:16:01 pm
Good evening, bplus and steve.
I thought a lot, a lot, before re-posting the same subject.
I do not want to be a nagging person. Even so, I came here this time, not to create a code.
I came to ask the Guro bplus and Steve an improvement in the modification of Steve's code, to complete my purposes.
Steve's code has been modified for the same purpose as my initial # 1 reply on: March 27, 2019, for bplus.
When Steve posted # 12 suggesting use the SEEK, to go directly to the appropriate record. I realized that Steve wanted to use a better knot code.
For all the knowledge of bplus and Steve. I make a request to analyze the modified code and if there is a possibility of some improvement in its performance.
I want to point out that Steve's code with bplus's willingness to find errors was a learning I only found in this forum.
Attached is a curiosity in the mega sena brazil contest 308 and 309
Sequence 04,11,25,39,55 repeated between contest 308 and 309
http://loterias.caixa.gov.br/wps/portal/loterias/landing/megasena/
Thank you for the reception and attention.
CarlosCordeiro