Looking For Lotto Generation Algorithm
Home
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
CDEX
Home wrote in message <7fcuj8$e9s$1...@mur2.odyssey.on.ca>...
= = = = = = = =
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
Royce Penny
>
> 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
--
Royce Penny
Royce Penny's Money Machine
http://www.geocities.com/wallstreet/7746
CDEX
Sean B wrote in message <371cd5d...@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.
- - -
Hoping this helps . . .
Joe
Mike Sharkey
>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...
GBo9569376
software at her website(www.gailhoward.com). Good luck.
apostador
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.
I thought it over and decided to order a CD from
http://www.spectra.net/~lottery/
Home <sca...@odyssey.on.ca> wrote in message
news:7fcuj8$e9s$1...@mur2.odyssey.on.ca...
MeMyselfAndI
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.
>
>
> 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:
10 = 001010
18 = 010010
19 = 010011
25 = 011001
38 = 100110
49 = 110001
Therefore, the encoding would be:
001010 010010 010011 011001 100110 110001
Storing the bits into bytes:
00101001 / 00100100 / 1101100110 / 01101100 / 01xxxxxx
This reduces the original 6 bytes to only 5 bytes (not much of a reduction
really).
-MMAI-
Tim Noonan
Mike Sharkey wrote:
> In article <371cd5d...@news.rapid.co.uk>, myn...@whyspam.com wrote:
>
> >Royce Penny <lottokin...@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
CDEX
CDEX wrote in message ...
>
(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.
Joe
CDEX
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?
The field:
sheep
cow
cat
dog
chicken
llama
rabbit
ox
pig
ostrich
goose
duck
ferret
I bet on the ferret coming out on top.
Joe
Mike Sharkey
<cd...@gsinet.net> wrote:
Well, there's always the old standby:
Q. How do you get down from an elephant?
A. You don't. You get down from a goose.
>
>
>Joe
Mike Sharkey
(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....)
Robert Perkis
I think I have what you are looking for. Robert Perkis
Sean B wrote:
> MeMyselfAndI <mhnsp_...@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:
> >
> >10 = 001010
> >18 = 010010
> >19 = 010011
> >25 = 011001
> >38 = 100110
> >49 = 110001
> >
>
> 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.
>
> >Therefore, the encoding would be:
> >
> >001010 010010 010011 011001 100110 110001
> >
> >Storing the bits into bytes:
> >
> >00101001 / 00100100 / 1101100110 / 01101100 / 01xxxxxx
> >
> >This reduces the original 6 bytes to only 5 bytes (not much of a reduction
> >really).
> >
> >-MMAI-
> >
>
> Thanks for your help.
>
> Sean B
CDEX
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:
... Numbers 1-24: 134,596 lines.
... Numbers 25-49: 177,100 lines.
... Thus the total play would be 311,696 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.
Richard Lloyd's site (http://lottery.merseyworld.com) gives the average UK
Jackpot payout: L2,194,749.
- - -
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:
... 6-matches (2): #323, 310.
... multiple 5-matches(13): #340, 336, 334, 323, 320, 319, 317, 316, 310,
306, 302, 299, 298.
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.
Hope this helps.
Joe
CDEX
Mike Sharkey wrote ...
...
>
>
>Q. How do you get down from an elephant?
>
>A. You don't. You get down from a goose.
>
>
>(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 !!!
Joe
coustaux philippe
Home a écrit dans le message
>......
>Does anyone have source code or an algorithm that will generate all
possible
>combinations for an 6/49 lottery, for example?
>
I t will cost you 14Mbits ( not bytes) one floppy, look at
http://www.multimania.com/coustaux
Philippe
CDEX
Sean B wrote in message <37232c9a...@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.
>
>Cheers
>
>Sean B
>
Best to you,
Joe
Karl Schultz
CDEX wrote in message ...
>possible
>>combinations for an 6/49 lottery, for example?
>>
>>SC
>>
>
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?
Karl Schultz
Sean B wrote in message <371cd5d...@news.rapid.co.uk>...
>>>
>>> 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.
CDEX
Karl Schultz wrote in message ...
>
>CDEX wrote in message ...
(snip for brevity)
>>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)?
Best regards,
Joe
CDEX
MeMyselfAndI
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:
11111...
22222...
33333...
44444...
55555...
678910...
Therefore, run-length encoding would produce:
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).
-MMAI-
karl_s...@my-dejanews.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.
>
> 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:
>
> 11111...
> 22222...
> 33333...
> 44444...
> 55555...
> 678910...
>
> Therefore, run-length encoding would produce:
>
> 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
Sean B
>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.
Cheers
Sean B
PlayLotteryOnline.org
>
> Does anyone have source code or an algorithm that will generate all possible
> combinations for an 6/49 lottery, for example?
>
Colin Fairbrother
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
Colin Fairbrother
even....@gmail.com
thanks