Home wrote in message <7fcuj8$e9...@mur2.odyssey.on.ca>... >Hi Lotto Enthusiasts!
>Does anyone have source code or an algorithm that will generate all possible >combinations for an 6/49 lottery, for example?
>Thanks for your help. >SC
= = = = = = = =
This newsgroup had some messages on this subject a couple of months ago. You might want to look back into the DejaNews archives to see if you can find them. I believe they were titled "Full Wheels", or "Full Wheel Generators", or something like that. You could do a text search on such a phrase, and you would probably find the messages.
Question to consider: Are you sure you want to generate every possible combination? Storing 13,983,816 lines as a basic Text (ASCII) file would give you a file of 280 megabytes in size. That's a good portion of your hard disk space. Further, no common data application (e.g., Word or Excel) would handle that file without an obscene amount of swap space (you probably do not have 280 MB RAM in your PC). If you intended to print the combinations (say, 6 across per line, 60 lines = 360 combinations on a page), I believe we figured that the printing would take several days and about 38,000 sheets of paper. I think Mike Sharkey calculated that out, perhaps he recalls the amounts.
If the intention is to *generate* all the possible lines, but to *keep* only selected ones, then you might explore some of the software programs which generate and filter your combinations according to the personal criteria you set up. Each combination gets made, but then is either rejected or kept in your final list according to your preferences. There are both freeware and commercial software which do this.
> Does anyone have source code or an algorithm that will generate all possible > combinations for an 6/49 lottery, for example?
> Thanks for your help. > SC
--------------------- The algorithm is really quite simple:
for i = 1 to 44 for j = i+1 to 45 for k = j+1 to 46 for l = k+1 to 47 for m = l+1 to 48 for n = m+1 to 49 ... ... now do what you want to do with the six mumbers ...(ie: for the total: tot = i+j+k+l+m+n) ...if it meets your criteria then save to disk ... next next next next next next quit -- Royce Penny Royce Penny's Money Machine http://www.geocities.com/wallstreet/7746
Sean B wrote in message <371cd5d9.332...@news.rapid.co.uk>... >Some time back, someone wrote saying they had a method >of saving something like the above to disk using only about >2-3 bits for each number.
>I tried to figure it out myself, but couldn't get it down anywhere >near even using binary trees.
>Does anyone know the most economical way of saving a lot >of lottery entries to disk? Perhaps it might be quicker just >to save them as an ascii file rather than spend time converting >to binary. e.g. 020817223449 This would take about 196mb >inc. CR and LF. Using just CR would only save 14mb... hardly >worth it. Saving to a Stacker mounted drive might be one possibility, >although 196mb of disk space is not too bad with todays >drives.
... >The reason I'm interested in saving a large quantity to disk >is that there are certain obvious combinations that never or >very rarely get drawn, so it would be interesting to see how >many would be left after eliminating all of these.
>Obviously the file can be split into smaller files using the >loops as start and finish points.
>Cheers
>Sean B
= = = = = = = =
Hi Sean,
There are a couple of options . . .
The more obvious one is simply to "zip" the text file before storage. ASCII files compress down to very small sizes because of the repetition within them (all or mostly the same numeric digits 0...9). So you could have quite a large assortment of the darned things, all on your disk at the same time. Just pop out the one you want for the job at hand, and "unzip" it.
The second option is to use a binary storage format, instead of text. Then, rather than using integers for the values, use something like "unsigned char" (in C). It has a range of 0...127, so encompasses all the values you would most likely want to use (e.g., 1 to 49 is feasible). Each value uses just one byte, and you do not need to store the "spaces" or "CR-LF" values. You simply insert them as needed when retrieving the information.
So for example, the combination:
1 8 19 25 38 49
... would require 17 bytes as text (including the CR-LF),
and the combination:
10 18 19 25 38 49
... would require 19 bytes.
However either one of them would require just 6 bytes if done as outlined above.
In article <371cd5d9.332...@news.rapid.co.uk>, myn...@whyspam.com wrote: >Royce Penny <lottoking.nos...@geocities.com> wrote:
>>Home wrote:
>>> Hi Lotto Enthusiasts!
>>> Does anyone have source code or an algorithm that will generate all possible >>> combinations for an 6/49 lottery, for example?
>>> Thanks for your help. >>> SC >>--------------------- >>The algorithm is really quite simple:
>>for i = 1 to 44 >> for j = i+1 to 45 >> for k = j+1 to 46 >> for l = k+1 to 47 >> for m = l+1 to 48 >> for n = m+1 to 49 >> ... >> ... now do what you want to do with the six mumbers >> ...(ie: for the total: tot = i+j+k+l+m+n) >> ...if it meets your criteria then save to disk >> ... >> next >> next >> next >> next >> next >>next >>quit
>Some time back, someone wrote saying they had a method >of saving something like the above to disk using only about >2-3 bits for each number.
>I tried to figure it out myself, but couldn't get it down anywhere >near even using binary trees.
>Does anyone know the most economical way of saving a lot >of lottery entries to disk? Perhaps it might be quicker just >to save them as an ascii file rather than spend time converting >to binary. e.g. 020817223449 This would take about 196mb >inc. CR and LF. Using just CR would only save 14mb... hardly >worth it. Saving to a Stacker mounted drive might be one possibility, >although 196mb of disk space is not too bad with todays >drives.
>Don McDonald has devised a way of numbering each of the >14m combinations which would make the file smaller. I'm >not sure if there is anyway of converting them back though, >short of running them through a loop similar to the above, >which would be very slow. Probably take about a year ;-(
>The reason I'm interested in saving a large quantity to disk >is that there are certain obvious combinations that never or >very rarely get drawn, so it would be interesting to see how >many would be left after eliminating all of these.
Ummm... not to nit-pick (well, ok, yes, I'm nit-picking here) but exactly *what* "obvious combinations" never or very rarely get drawn?
Keeping in mind that the "numbers" on the balls are just nifty splotches of ink - that have no meaning whatsoever, except to sentient beings with mathematical backgrounds. Ie, the *balls* can't tell each other apart - - because they do *not* have intelligence, nor any mathematical training whatsoever.
We could (in theory) rearrange the ink on each and every ball, such that the ink was in the silhouette of, say, a farm animal. Now, without >knowing< that the ball with the "sheep" outline used to be the "2" or that the "cow" outline used to be the "17" or that the "cat" outline used to be the "31" and in the full knowledge that this change makes *absolutely* no difference to the balls themselves (not having brains, y'know) can you tell me whether ( "dog", "chicken", "llama", "rabbit", "ox" ) is more rarely or never picked compared to, oh, say ( "pig", "ostrich", "goose", "duck", "ferret") ??
I mean, there would be an "obvious" difference, wouldn't there? Ummm, perhaps avians vs mammals? Or based on weight? Or perhaps cost per pound of buthered meat? Or...?
>Obviously the file can be split into smaller files using the >loops as start and finish points.
>Cheers
>Sean B
With a little bit o' luck, wi' a lil' bit o' luck...
to generate all the ~14 million lines of the 6/49 lotto on a file you need:
1.plenty of time. a couple days even with a 450Mhz PentiumII computer running on a full time basis, that means no games, no internet, no webchat. 2.a big enough disk to accomodate almost a huge 350Mb file 3.then after the file is created, it takes a lot of time to load into memory too, and if you dont have the required ammount of memory, windows will need to create a huge swap file, so things could become very slow on your machine.
So, the best way is to divide all the lines in small files, about 6Mb each that gives you about 60 smaller files of 3 collumn plain text files. to edit with word or a similar program.
> The more obvious one is simply to "zip" the text file before storage. ASCII > files compress down to very small sizes because of the repetition within > them (all or mostly the same numeric digits 0...9). So you could have quite > a large assortment of the darned things, all on your disk at the same time. > Just pop out the one you want for the job at hand, and "unzip" it.
Correct, Joe. Actually, there is a compression algorithm that utilizes only text (ie, numerical quantities from 32 (space) to 126 (tilde?)). I can't remember the name (MA?), but it compresses text files even lower than LZH compression. It reduces it to something like 3-5% the original. Of course, if you are compressing only digits (0-9), the space, and CR/LF, then I'm sure the compression can be much higher.
> The second option is to use a binary storage format, instead of text. Then, > rather than using integers for the values, use something like "unsigned > char" (in C). It has a range of 0...127, so encompasses all the values you > would most likely want to use (e.g., 1 to 49 is feasible). Each value uses > just one byte, and you do not need to store the "spaces" or "CR-LF" values. > You simply insert them as needed when retrieving the information.
> So for example, the combination:
> 1 8 19 25 38 49
> ... would require 17 bytes as text (including the CR-LF),
> and the combination:
> 10 18 19 25 38 49
> ... would require 19 bytes.
> However either one of them would require just 6 bytes if done as outlined > above.
> - - -
> Hoping this helps . . .
> Joe
A third option - one I think Sean B. was mentioning - uses bit-encoding. Using your combination 10-18-19-25-38-49, you'd have the following (in a 49 number game) bit patterns:
> >>> Does anyone have source code or an algorithm that will generate all possible > >>> combinations for an 6/49 lottery, for example?
> >>> Thanks for your help. > >>> SC > >>--------------------- > >>The algorithm is really quite simple:
> >>for i = 1 to 44 > >> for j = i+1 to 45 > >> for k = j+1 to 46 > >> for l = k+1 to 47 > >> for m = l+1 to 48 > >> for n = m+1 to 49 > >> ... > >> ... now do what you want to do with the six mumbers > >> ...(ie: for the total: tot = i+j+k+l+m+n) > >> ...if it meets your criteria then save to disk > >> ... > >> next > >> next > >> next > >> next > >> next > >>next > >>quit
> >Some time back, someone wrote saying they had a method > >of saving something like the above to disk using only about > >2-3 bits for each number.
> >I tried to figure it out myself, but couldn't get it down anywhere > >near even using binary trees.
> >Does anyone know the most economical way of saving a lot > >of lottery entries to disk? Perhaps it might be quicker just > >to save them as an ascii file rather than spend time converting > >to binary. e.g. 020817223449 This would take about 196mb > >inc. CR and LF. Using just CR would only save 14mb... hardly > >worth it. Saving to a Stacker mounted drive might be one possibility, > >although 196mb of disk space is not too bad with todays > >drives.
> >Don McDonald has devised a way of numbering each of the > >14m combinations which would make the file smaller. I'm > >not sure if there is anyway of converting them back though, > >short of running them through a loop similar to the above, > >which would be very slow. Probably take about a year ;-(
> >The reason I'm interested in saving a large quantity to disk > >is that there are certain obvious combinations that never or > >very rarely get drawn, so it would be interesting to see how > >many would be left after eliminating all of these.
> Ummm... not to nit-pick (well, ok, yes, I'm nit-picking here) > but exactly *what* "obvious combinations" never or very rarely > get drawn?
> Keeping in mind that the "numbers" on the balls are just nifty > splotches of ink - that have no meaning whatsoever, except to > sentient beings with mathematical backgrounds. > Ie, the *balls* can't tell each other apart - - because they > do *not* have intelligence, nor any mathematical training whatsoever.
> We could (in theory) rearrange the ink on each and every ball, > such that the ink was in the silhouette of, say, a farm animal. > Now, without >knowing< that the ball with the "sheep" outline > used to be the "2" or that the "cow" outline used to be the "17" > or that the "cat" outline used to be the "31" > and in the full knowledge that this change makes *absolutely* > no difference to the balls themselves (not having brains, y'know) > can you tell me whether ( "dog", "chicken", "llama", "rabbit", "ox" ) > is more rarely or never picked compared to, oh, say > ( "pig", "ostrich", "goose", "duck", "ferret") ??
> I mean, there would be an "obvious" difference, wouldn't there? > Ummm, perhaps avians vs mammals? Or based on weight? > Or perhaps cost per pound of buthered meat? Or...?
> >Obviously the file can be split into smaller files using the > >loops as start and finish points.
> >Cheers
> >Sean B
> With a little bit o' luck, wi' a lil' bit o' luck...
(snip) >The second option is to use a binary storage format, instead of text. Then, >rather than using integers for the values, use something like "unsigned >char" (in C). It has a range of 0...127, so encompasses all the values you >would most likely want to use (e.g., 1 to 49 is feasible
- - - - - - - - Sorry for the typo. It was in the head, not on the keyboard.
type unsigned char (in C) has a range of 0...255, not the range shown above.
>Keeping in mind that the "numbers" on the balls are just nifty >splotches of ink - that have no meaning whatsoever, except to >sentient beings with mathematical backgrounds. >Ie, the *balls* can't tell each other apart - - because they >do *not* have intelligence, nor any mathematical training whatsoever.
>We could (in theory) rearrange the ink on each and every ball, >such that the ink was in the silhouette of, say, a farm animal. >Now, without >knowing< that the ball with the "sheep" outline >used to be the "2" or that the "cow" outline used to be the "17" >or that the "cat" outline used to be the "31" >and in the full knowledge that this change makes *absolutely* >no difference to the balls themselves (not having brains, y'know) >can you tell me whether ( "dog", "chicken", "llama", "rabbit", "ox" ) >is more rarely or never picked compared to, oh, say >( "pig", "ostrich", "goose", "duck", "ferret") ??
...
>With a little bit o' luck, wi' a lil' bit o' luck...
- - -
Would somebody please run this in an RNG against the Sharkey Challenge?
<c...@gsinet.net> wrote: >Mike Sharkey wrote ... >... >>Keeping in mind that the "numbers" on the balls are just nifty >>splotches of ink - that have no meaning whatsoever, except to >>sentient beings with mathematical backgrounds. >>Ie, the *balls* can't tell each other apart - - because they >>do *not* have intelligence, nor any mathematical training whatsoever.
>>We could (in theory) rearrange the ink on each and every ball, >>such that the ink was in the silhouette of, say, a farm animal. >>Now, without >knowing< that the ball with the "sheep" outline >>used to be the "2" or that the "cow" outline used to be the "17" >>or that the "cat" outline used to be the "31" >>and in the full knowledge that this change makes *absolutely* >>no difference to the balls themselves (not having brains, y'know) >>can you tell me whether ( "dog", "chicken", "llama", "rabbit", "ox" ) >>is more rarely or never picked compared to, oh, say >>( "pig", "ostrich", "goose", "duck", "ferret") ??
>...
>>With a little bit o' luck, wi' a lil' bit o' luck...
>- - -
>Would somebody please run this in an RNG against the Sharkey Challenge?
(Now, some wise-ass will ask me to list a field of 49 distinct farm-animals...)
( And then another will ask me to map the direct one-to-one relationship between the numbers 1 through 49 and (a) the average weight per animal, (b) the market price per pound, and (c) their alphabetical nomenclature - both in common English and their Latin genus names....)
With a little bit o' luck, wi' a lil' bit o' luck...
Sean B wrote: > MeMyselfAndI <mhnsp_nos...@aol.com> wrote:
> >CDEX wrote: Hi Sean,
> ><snip>
> >> There are a couple of options . . .
> >> The more obvious one is simply to "zip" the text file before storage. ASCII > >> files compress down to very small sizes because of the repetition within > >> them (all or mostly the same numeric digits 0...9). So you could have quite > >> a large assortment of the darned things, all on your disk at the same time. > >> Just pop out the one you want for the job at hand, and "unzip" it.
> >Correct, Joe. Actually, there is a compression algorithm that utilizes only > >text (ie, numerical quantities from 32 (space) to 126 (tilde?)). I can't > >remember the name (MA?), but it compresses text files even lower than LZH > >compression. It reduces it to something like 3-5% the original. Of course, if > >you are compressing only digits (0-9), the space, and CR/LF, then I'm sure the > >compression can be much higher.
> That's a good idea use just the 49 ascii chars starting from > 33 (decimal) should reduce the files size by about half.
> >> The second option is to use a binary storage format, instead of text. Then, > >> rather than using integers for the values, use something like "unsigned > >> char" (in C). It has a range of 0...127, so encompasses all the values you > >> would most likely want to use (e.g., 1 to 49 is feasible). Each value uses > >> just one byte, and you do not need to store the "spaces" or "CR-LF" values. > >> You simply insert them as needed when retrieving the information.
> >> So for example, the combination:
> >> 1 8 19 25 38 49
> >> ... would require 17 bytes as text (including the CR-LF),
> >> and the combination:
> >> 10 18 19 25 38 49
> >> ... would require 19 bytes.
> >> However either one of them would require just 6 bytes if done as outlined > >> above.
> >> - - -
> >> Hoping this helps . . .
> >> Joe
> > A third option - one I think Sean B. was mentioning - uses bit-encoding. > >Using your combination 10-18-19-25-38-49, you'd have the following (in a 49 > >number game) bit patterns:
> Not quite that's just the numbers in binary and uses 6 bits > for each. Someone (not a RGL regular) said they got it down > to 2 or 3 bits. When I tried a binary tree about a year ago I > think I got down to 4 bits. Hardly worth it because of the extra > processing time.
Here's another option you could consider -- for managing the wheeling diskfile and RAM sizes.
Instead of using the Full 6/49 (13.9M lines) you could consider splitting the field into smaller sections or "zones", and wheeling those sections separately.
That would give you significantly smaller files and less demand on RAM for access.
How you would split up the field is your choice. You could just do it to get something you can work with. There are dozens of ways, all of them arbitrary.
- - -
For example, you could just do a Low/High split using the numbers 1...24 in one field, and 25...49 in the other. That would give you the following total lines:
That's a lot less than the full 13,983,816 and your two files would be smaller. You could easily store them on your disk and access them in RAM without swap files.
In no way would this change your odds, but it would be an easy way to reduce your playing cost while getting files you can handle. Your Jackpot chances would be reduced by the same proportion (311696/13983816) -- can't get anything for free, as you know well.
- - - -
I just ran the above pair of wheels against the UK 6/49 game's drawings through #344 (at 10 April 99).
In a 6/49 you would get a 6-match (disregarding the Bonus) about an average 1:45 draws. The two wheels gave 7 matches in the 344, or about 1:49.
If you played a Full 6/49 wheel (all combinations) your cost would be:
... 344 * 13,983,816 = L4,810,432,704.
Your approximate payback ratio (for the 344 wins) would be:
... 754,993,656 : 4,810,432,704 = 1:6.37
- - -
If you played the two wheels above (311,696 combinations) your cost would be:
... 344 * 311,696 = L107,223,424.
Your approximate payback ratio (for the 7 wins) would be:
... 15,363,243 : 107,223,424 = 1:6.97
Obviously 7 wins is not much data. The split-wheeled play could do better or worse, but would average out to the same ratio as for the Full wheel in steady play.
- - -
By the way, in addition to the 6-match Jackpot wins, there would be 5-match wins as well. You would have multiple 5's in addition to each 6, and you would also have multiple 5's even when you did not score a 6.
For example, the two split wheels above produced 6-matches in 7 draws. But they produced multiple 5-matches in 72 draws (including the 6-match draws).
Running the wheels through the game's recent 50 draws through 10 April (#295 to #344), there were:
There would be 4- and 3-matches too, but I didn't count them.
- - -
So I guess the point is: You can have the same odds with wheels other than Full wheels, using file/RAM sizes that you can work with. You're not giving anything up in order to use practical wheel sizes.
>(Now, some wise-ass will ask me to list a field of 49 distinct farm-animals...)
>( And then another will ask me to map the direct one-to-one relationship >between the numbers 1 through 49 and (a) the average weight per animal, >(b) the market price per pound, and (c) their alphabetical nomenclature - both >in common English and their Latin genus names....)
>With a little bit o' luck, wi' a lil' bit o' luck...
- - - - - -
No problem. 'Experts' would sort them out by Low/High values. Rabbits and chickens are Low. Llamas and ostriches are High.
Then there is Even/Odd. Dogs are generally pretty Even. Cats are, if anything, Odd.
The ferret would always be wheeled as the Key critter, expected to show up anywhere.
And ... how do you "get down from a goose"? Careful with that answer !!!
Sean B wrote in message <37232c9a.1961...@news.rapid.co.uk>...
(snip for brevity)
>I received a program from Robert that saves all or >some of the 14m combinations to disk using just >2 bytes for each. Unfortunately because its a binary >save there's no way of telling how its done, without >info on the binary tree used. Everythings just 001000111001 etc. >Works fast though even reading back.
I'm curious -- what file size (bytes) do you get when saving all 14M combinations?
>Another possibility for saving the numbers and reducing the >file size is to save the first number and then the number of >spaces to the next and so on.
... Don't think so, unless I missed something. Wouldn't it take the same amount of storage, if you're using the same storage type as you would use for the numbers themselves? A Pick-6 combination has six numbers (I studied Rocket Science to figure that out). But it also has one number plus five spaces to the following numbers. So wouldn't we wind up with six "things" to store, each representing a numerical value?
For example, if three numbers: 1-7-10 could be stored (say) as 16-bit integers, you would (obviously) have three 16-bit values. If you stored them as "number-space-space" you would be storing: 1-6-3, still as three integer values. The same would be true if you were storing 8-bit unsigned characters, and so on. Probably I missed the point, sorry if I did.
>Home wrote in message <7fcuj8$e9...@mur2.odyssey.on.ca>... >>Hi Lotto Enthusiasts!
>>Does anyone have source code or an algorithm that will generate all >possible >>combinations for an 6/49 lottery, for example?
>>Thanks for your help. >>SC
>= = = = = = = =
>This newsgroup had some messages on this subject a couple of months ago. >You might want to look back into the DejaNews archives to see if you can >find them. I believe they were titled "Full Wheels", or "Full Wheel >Generators", or something like that. You could do a text search on such a >phrase, and you would probably find the messages.
>Question to consider: Are you sure you want to generate every possible >combination? Storing 13,983,816 lines as a basic Text (ASCII) file would >give you a file of 280 megabytes in size. That's a good portion of your >hard disk space. Further, no common data application (e.g., Word or Excel) >would handle that file without an obscene amount of swap space (you probably >do not have 280 MB RAM in your PC). If you intended to print the >combinations (say, 6 across per line, 60 lines = 360 combinations on a >page), I believe we figured that the printing would take several days and >about 38,000 sheets of paper. I think Mike Sharkey calculated that out, >perhaps he recalls the amounts.
>If the intention is to *generate* all the possible lines, but to *keep* >only selected ones, then you might explore some of the software programs >which generate and filter your combinations according to the personal >criteria you set up. Each combination gets made, but then is either >rejected or kept in your final list according to your preferences. There >are both freeware and commercial software which do this.
>Hoping this is helpful.
>Joe >CDEX
Besides, storing the complete list of combinations is pretty useless, since you can always generate the nth combination with a simple calculation. What good is storing the entire list someplace, when any desired combination can be regenerated at will?
Sean B wrote in message <371cd5d9.332...@news.rapid.co.uk>... >Royce Penny <lottoking.nos...@geocities.com> wrote:
>>Home wrote:
>>> Hi Lotto Enthusiasts!
>>> Does anyone have source code or an algorithm that will generate all possible >>> combinations for an 6/49 lottery, for example?
>>> Thanks for your help. >>> SC >>--------------------- >>The algorithm is really quite simple:
>>for i = 1 to 44 >> for j = i+1 to 45 >> for k = j+1 to 46 >> for l = k+1 to 47 >> for m = l+1 to 48 >> for n = m+1 to 49 >> ... >> ... now do what you want to do with the six mumbers >> ...(ie: for the total: tot = i+j+k+l+m+n) >> ...if it meets your criteria then save to disk >> ... >> next >> next >> next >> next >> next >>next >>quit
>Some time back, someone wrote saying they had a method >of saving something like the above to disk using only about >2-3 bits for each number.
Since we are not using all the digits with equal frequency, Huffman encoding is another possibility.
I am NOT saying that any particular number (1-49) is more likely that any other. What I am saying is that some DIGITS appear more frequently than others. These digits would be 0, 1, 2, 3, and 4, assuming a 6/49 game. Why? Because the ten's place can only have 0-4, while the units place can have 0-9. 0: 13, 1,2,3,4:15, 5,6,7,8,9: 5 13 + 15*4 + 5*5 = 98 digits (49 numbers). Some numbers have 3 times the fequency of others.
The basis of Huffman encoding involves encoding the more frequent codes with shorter binary strings, letting the less frequent codes be represented by longer binary strings. For example, if I were to Huffman encode a book written in English, it is likely that 'e' appears the most and would have the shortest encoding.
I don't know what the optimum encoding would be, but if you arbitrarily pick one of the four ties for the most frequent and called it the most frequent, you can encode that digit in one or two bits, giving a best case encoding for a NUMBER of 2-4 bits. The worst case may be much longer, but should appear less frequently.
I can't think of any way to get it down to 2-3 bits for all numbers, let alone for each digit.
<snip>
>The reason I'm interested in saving a large quantity to disk >is that there are certain obvious combinations that never or >very rarely get drawn, so it would be interesting to see how >many would be left after eliminating all of these.
This would be a good application for some sort of encoding, although the basic premise for wanting to do this is fundamentally flawed, as always. Tracking "certain obvious combinations that never or very rarely get drawn" is of no use except for curiosity's sake. It is no bearing on future draws.
>>Question to consider: Are you sure you want to generate every possible >>combination? Storing 13,983,816 lines as a basic Text (ASCII) file would >>give you a file of 280 megabytes in size. That's a good portion of your >>hard disk space. Further, no common data application (e.g., Word or Excel) >>would handle that file without an obscene amount of swap space (you probably >>do not have 280 MB RAM in your PC). If you intended to print the >>combinations (say, 6 across per line, 60 lines = 360 combinations on a >>page), I believe we figured that the printing would take several days and >>about 38,000 sheets of paper. I think Mike Sharkey calculated that out, >>perhaps he recalls the amounts. ...
>Besides, storing the complete list of combinations is pretty useless, since >you can always generate the nth combination with a simple calculation. What >good is storing the entire list someplace, when any desired combination can >be regenerated at will?
Do you have an example (or know where one is found)? Does this entail counting the combinations as generated (per Royce's code example) and extracting the desired "nth" on the fly (which would be slow)? Or does it entail naming the "nth" in advance and generating specifically that single combination (which would be fast)?
Huffman codes would work well, however, run-length encoding would probably be better given the fact that (a) *ALL* combinations are being stored, and (b) there is no predetermined storage method.
When most people think of the combinations, they probably vision them this way:
... 10-20-26-33-37-45 ...
However, another way to look at the numbers is like this:
1[number of consecutive 1's]2[number of consecutive 2's]...
The first line itself would be wittled down to something like (43 * (6 + 25)) = 1,333 BITS! A reduction of less than 1 bit for every 1,000 *BYTES*!
Another option would be WHY STORE THE COMBINATIONS ANYWAY!
Just use a recursive combinatorical search routine to find a particular pattern given it's index (or an index given it's particular pattern), such as this:
String[] s = getCombination(4500); // find combination #4500 long i = getIndex(14,21,23,35,39,42) // find index of the combination 14-21-23-35-39-42
I wrote these functions several years ago and they are extremely fast (no, they don't do 6-deep for() loops, either).
Karl Schultz wrote: > Sean B wrote in message <371cd5d9.332...@news.rapid.co.uk>... > >Royce Penny <lottoking.nos...@geocities.com> wrote:
> >>Home wrote:
> >>> Hi Lotto Enthusiasts!
> >>> Does anyone have source code or an algorithm that will generate all > possible > >>> combinations for an 6/49 lottery, for example?
> >>> Thanks for your help. > >>> SC > >>--------------------- > >>The algorithm is really quite simple:
> >>for i = 1 to 44 > >> for j = i+1 to 45 > >> for k = j+1 to 46 > >> for l = k+1 to 47 > >> for m = l+1 to 48 > >> for n = m+1 to 49 > >> ... > >> ... now do what you want to do with the six mumbers > >> ...(ie: for the total: tot = i+j+k+l+m+n) > >> ...if it meets your criteria then save to disk > >> ... > >> next > >> next > >> next > >> next > >> next > >>next > >>quit
> >Some time back, someone wrote saying they had a method > >of saving something like the above to disk using only about > >2-3 bits for each number.
> Since we are not using all the digits with equal frequency, Huffman encoding > is another possibility.
> I am NOT saying that any particular number (1-49) is more likely that any > other. What I am saying is that some DIGITS appear more frequently than > others. These digits would be 0, 1, 2, 3, and 4, assuming a 6/49 game. > Why? Because the ten's place can only have 0-4, while the units place can > have 0-9. 0: 13, 1,2,3,4:15, 5,6,7,8,9: 5 13 + 15*4 + 5*5 = 98 digits > (49 numbers). Some numbers have 3 times the fequency of others.
> The basis of Huffman encoding involves encoding the more frequent codes with > shorter binary strings, letting the less frequent codes be represented by > longer binary strings. For example, if I were to Huffman encode a book > written in English, it is likely that 'e' appears the most and would have > the shortest encoding.
> I don't know what the optimum encoding would be, but if you arbitrarily pick > one of the four ties for the most frequent and called it the most frequent, > you can encode that digit in one or two bits, giving a best case encoding > for a NUMBER of 2-4 bits. The worst case may be much longer, but should > appear less frequently.
> I can't think of any way to get it down to 2-3 bits for all numbers, let > alone for each digit.
> <snip>
> >The reason I'm interested in saving a large quantity to disk > >is that there are certain obvious combinations that never or > >very rarely get drawn, so it would be interesting to see how > >many would be left after eliminating all of these.
> This would be a good application for some sort of encoding, although the > basic premise for wanting to do this is fundamentally flawed, as always. > Tracking "certain obvious combinations that never or very rarely get drawn" > is of no use except for curiosity's sake. It is no bearing on future draws.
> Huffman codes would work well, however, run-length encoding would probably be > better given the fact that (a) *ALL* combinations are being stored, and (b) > there is no predetermined storage method.
> When most people think of the combinations, they probably vision them this way:
> ... > 10-20-26-33-37-45 > ...
> However, another way to look at the numbers is like this:
> 1[number of consecutive 1's]2[number of consecutive 2's]...
> The first line itself would be wittled down to something like (43 * (6 + 25)) = > 1,333 BITS! A reduction of less than 1 bit for every 1,000 *BYTES*!
Yup, I think that would work.... Thanks for pointing it out.
> Another option would be WHY STORE THE COMBINATIONS ANYWAY!
I pointed this out in another posting and have discussed it offline with others. Right, there is no reason to do so.
But there might be a weak reason for an application where *ALMOST* all combinations are stored, as when someone wants to remove a few favorites from the list. In this case, you are still faced with a large storage problem if you insist on storing these things someplace. (Storing *just* the exceptions and using a "virtual" list as we're talking about here would be a much better way)
> Just use a recursive combinatorical search routine to find a particular pattern > given it's index (or an index given it's particular pattern), such as this:
> String[] s = getCombination(4500); // find combination #4500 > long i = getIndex(14,21,23,35,39,42) // find index of the combination > 14-21-23-35-39-42
yup.
Karl
-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
MeMyselfAndI <mhnsp_nos...@aol.com> wrote: >Sean and Karl -
>Huffman codes would work well, however, run-length encoding would probably be >better given the fact that (a) *ALL* combinations are being stored, and (b) >there is no predetermined storage method.
-> remainder of reply snipped.
Thanks for the input on this one. It did occur to me that the easiest solution would be to just save the14M bits as Y/N flags 0 and 1 only. That would only take up 1.75Mb The loops could be just run through and the first check would be to see if that combination was ON or OFF. (included ot not-included).
I don't know why I never thought of that earlier its similar to the methods I've always used for identifying lottery balls.
This thread was started April 18, 1999 with tha penultimate entry
April 30, 1999. The answer to the question is given in the same thread
by Royce Penny April 19, 1999. You may also want to look at
http://www.colinfairbrother.com/ProbabilityTheoryForLotto.aspx
