PowerBASIC Forums
  Programming
  Looking for Reiterative Solution (Page 1)

Post New Topic  Post A Reply
profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone!
This topic is 4 pages long:   1  2  3  4 
next newest topic | next oldest topic
Author Topic:   Looking for Reiterative Solution
Donald Darden
Member
posted January 07, 2005 06:16 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
In a Lotto Drawing, only certain number combinations are considered.
First, unlike a Pick game, no numbers are duplicated, so you have
five or six unique numbers that appear as a result, depending upon
how many balls are picked are per game. Although I know how to
determine how many separate plays would have to be used to play all
combinations, I wanted a program that would actually generate
those combinations.

I found I could do it readily enough with a series of embedded FOR
loops, one for each ball. Unfortunately, this means writting code
specific to either a five ball or six ball drawing. I wanted code
that could go either way.

It occurred to me that it might be possible to employ a reiterative
Sub or Function to get the same results. I've played with it all
afternoon, but it is proving more dificult than I expected. I
thought I would post the original code here as a challenge. I'm
sure someone will likely respond with a solution.


#COMPILE EXE
#DIM ALL
GLOBAL ns AS STRING
GLOBAL panel AS STRING

FUNCTION PBMAIN
LOCAL a AS LONG, b AS LONG, c AS LONG, d AS LONG, e AS LONG, f AS LONG
LOCAL g AS LONG, x AS LONG
ns=STRING$(11,0) 'the pool of numbers to pick from
FOR a=1 TO LEN(ns)
MID$(ns,a)=CHR$(a) 'for convenience, numbered 1 to n in order
NEXT
panel=STRING$(6,0) 'the numbers picked for one panel
'There has to be a separate FOR loop for each pick. Here, the pick is 6:
FOR a=1 TO LEN(ns)
MID$(panel,1)=MID$(ns,a,1) 'update ther first ball
FOR b=a+1 TO LEN(ns)
MID$(panel,2)=MID$(ns,b,1) 'update the second ball
FOR c=b+1 TO LEN(ns)
MID$(panel,3)=MID$(ns,c,1) 'update the third ball
FOR d=c+1 TO LEN(ns)
MID$(panel,4)=MID$(ns,d,1) 'update the fourth ball
FOR e=d+1 TO LEN(ns)
MID$(panel,5)=MID$(ns,e,1) 'update the fifth ball
FOR f=e+1 TO LEN(ns)
MID$(panel,6)=MID$(ns,f,1) 'update the sixth ball
INCR x
PRINT x, 'track number of plays
FOR g=1 TO LEN(panel) 'show the current panel
PRINT FORMAT$(ASC(panel,g)," 00");
NEXT
PRINT
NEXT
NEXT
NEXT
NEXT
NEXT
NEXT
WAITKEY$
END FUNCTION

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged

Paul Dixon
Member
posted January 07, 2005 09:37 PM     Click Here to See the Profile for Paul Dixon     Edit/Delete Message   Reply w/Quote
Donald,
no promises that it works under all circumstances..

Paul.


GLOBAL ns AS STRING
GLOBAL x AS LONG
GLOBAL pool AS LONG

SUB DoIt(depth AS LONG, MaxDepth AS LONG, nxt AS LONG, panel AS STRING)
LOCAL r AS LONG
LOCAL g AS LONG

IF depth = MaxDepth THEN
INCR x
PRINT x,
FOR g=1 TO LEN(panel) 'show the current panel
PRINT FORMAT$(ASC(panel,g)," 00");
NEXT
PRINT

ELSE
FOR r = nxt TO pool
MID$(panel,depth+1)=MID$(ns,r,1)
CALL DoIt(depth+1,MaxDepth,r+1,panel)
NEXT

END IF

END SUB

FUNCTION PBMAIN

n&=6 'the number of balls to draw
pool=11 'number of balls to draw from

ns=STRING$(pool,0) 'the pool of numbers to pick from
FOR a&=1 TO pool
MID$(ns,a&)=CHR$(a&)
NEXT

CALL DoIt(0,n&,1,STRING$(n&," "))

WAITKEY$
END FUNCTION

------------------

IP: Logged

Donald Darden
Member
posted January 07, 2005 09:44 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
Thanks, I'll look at it. Actually, it's easy enough to check - just
see if it runs to the limits allowed.

I finally thought of another approach that uses a funky way of
incrementing by offsets in the panel. It works well, and does not
require reiteration:


#COMPILE EXE
#DIM ALL
GLOBAL ns AS STRING
GLOBAL panel AS STRING
GLOBAL picks AS LONG
GLOBAL x AS LONG

FUNCTION expand()AS LONG
LOCAL a AS LONG, b AS LONG, c AS LONG, d AS LONG, tmp AS STRING
d=LEN(ns)
FOR a=0 TO picks-1
b=picks-a
tmp=MID$(panel,b,1)
c=INSTR(ns,tmp)
IF c>=d-a THEN ITERATE FOR
INCR c
MID$(panel,b)=MID$(ns,c)
FUNCTION=-1
EXIT FUNCTION
NEXT
FUNCTION=0
END FUNCTION

FUNCTION PBMAIN
LOCAL a AS LONG, b AS LONG, c AS LONG, d AS LONG, e AS LONG, f AS LONG
LOCAL g AS LONG
ns=STRING$(10,0) 'set ns to total number of numbers to pick from
picks=6
FOR a=1 TO LEN(ns)
MID$(ns,a)=CHR$(a) 'assign numbers as byte values within ns
NEXT
panel=LEFT$(ns,picks)
DO
INCR x
PRINT x,
FOR g=1 TO LEN(panel)
PRINT FORMAT$(ASC(panel,g)," 00");
NEXT
PRINT
LOOP WHILE expand
WAITKEY$
END FUNCTION


------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

[This message has been edited by Donald Darden (edited January 07, 2005).]

IP: Logged

Donald Darden
Member
posted January 07, 2005 11:07 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
Another problem is generating an abbreviated wheel from the range of
all possible combinations. While some wheels focus on ensuring that
every 3 of six or 4 of six combos is picked, I am more interested
in trying to ensure that all balls selected are played an equal
number of times, or as close as possible, over a given range of
plays without generating any duplicate plays. I've had some
success with several approaches, particularly with ensuring an even
distribution, but the problem of duplicates becomes acute as the set
of picks gets larger.

Online research suggests that wheels that focus on improving your
odds for getting 3 of six or 4 of six, tend to work against your
chances at a 5 of six and 6 of six matchup. Since nobody plays on
the expectations of just an occasional 3 or six or 4 of six win, it
seems to make sence to avoid those particular wheels.

There are other wheels that focus on trying to wheel with pairs
and threes, sometimes called neighbors, keeping them together
during the distribution. My thought on this is to code the pair
or threes and wheel the codes in an abbreviated panel, then
expand the panel to the picks' full size later by expanding the
codes back to the pair or threes.

Neighbors are believed by some to be significant, based on the
perception that if a so-called "hot" number is due, that a ball
adjacent to it ( a neighbor) might come up instead. It is also
reinforced sometimes when two, possibly three adjacent balls
come up in the same game. So you bet the hot number and maybe
either or both neighbors. This is how you end up with a pool of
numbers to wheel.

There are many other theories as to what might cause a certain
ball or set of numbers to be "due". I won't get into all that.
But I'm disturbed that people hold that wheeling strategies are
worth protecting and charging big bucks for. Some of those
Wheeling programs run up to $50, and even come with wild
promises about how much you can win and the improved odds that
Wheeling supposedly gives you. So I'm going to mess around with
some code, and make it available to others as I go along.

It's been claimed that using a good strategy or lottery program
and wheeling your pool or numbers can increase your odds of
winning by up to twelve times. That may seem a lot, and it
certainly means that you can leverage your number of plays as
though it were a larger set, but the odds against winning are
still astronomical. Still, if I were motivated to play the Lottery,
I would want every advantage I could get. But I would not want
anyone to think that these programs are going to result in a
significant win, ever. Because they may only encourage you to
try harder and play more. at an added cost to yourself, and the
outcome is most probably going to be one of great disappointment.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged

Donald Darden
Member
posted January 07, 2005 11:57 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
Paul Dixon,

I just tried your code. Works just fine. I was trying to use
Globals and Local variables for control, but couldn't get it
right. Your method of passing everything simplified all that.

I made minor name and dimension changes to your code, just to
make it consistent with what I wrote. But it is your code in all
respects.


#COMPILE EXE
#DIM ALL
GLOBAL ns AS STRING
GLOBAL x AS LONG
GLOBAL pool AS LONG

SUB DoIt(depth AS LONG, MaxDepth AS LONG, nxt AS LONG, panel AS STRING)
LOCAL r AS LONG, g AS LONG

IF depth = MaxDepth THEN
INCR x
PRINT x,
FOR g=1 TO LEN(panel) 'show the current panel
PRINT FORMAT$(ASC(panel,g)," 00");
NEXT
PRINT
ELSE
FOR r = nxt TO pool
MID$(panel,depth+1)=MID$(ns,r,1)
CALL DoIt(depth+1,MaxDepth,r+1,panel)
NEXT
END IF
END SUB

FUNCTION PBMAIN
LOCAL picks AS LONG, a AS LONG
picks=6 'the number of balls to draw
pool=9 'number of balls to draw from
ns=STRING$(pool,0) 'the pool of numbers to pick from
FOR a=1 TO pool
MID$(ns,a)=CHR$(a)
NEXT

CALL DoIt(0,picks,1,STRING$(picks," "))

WAITKEY$
END FUNCTION

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged

Michael Mattias
Member
posted January 08, 2005 09:14 AM     Click Here to See the Profile for Michael Mattias     Edit/Delete Message   Reply w/Quote
I think you mean "recursive" rather than "reiterative".. that is, a function which calls itself.

In the PB/DOS User's manual there is a statement about recursive code I've always liked:

quote:

[R]ecursive programming, while seductively elegant, can be devilishly tricky to debug..

Not really on topic, but I've always loved that statement.

IP: Logged

David Roberts
Member
posted January 08, 2005 01:42 PM     Click Here to See the Profile for David Roberts     Edit/Delete Message   Reply w/Quote
quote:
It's been claimed that using a good strategy or lottery program
and wheeling your pool or numbers can increase your odds of
winning by up to twelve times. That may seem a lot, and it
certainly means that you can leverage your number of plays as
though it were a larger set, but the odds against winning are
still astronomical.

Lotteries are determinate systems and as such the theoretical odds against
winning whatever strategy is used is the same for each and every one.

There may be slight imperfections in the machines and balls used such that
the practical odds differ to theoretical odds.

In the UK our 'Lotto' uses 12 machines and 14 sets of balls.

------------------
David Roberts

IP: Logged

Donald Darden
Member
posted January 08, 2005 05:44 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
Back some 20 years ago, when lotteries only had 28 to 32 balls. I
recall one lottery that repeated the same five or 6 combo between
two consecutive drawings, and another where the same six of six
numbers came up within five drawings of each other. Things like
that drew harsh criticism as to mechanical imprefections that might
cause certain balls to come up more often. I also recall some
scandals where paint was added to some balls to give them more
mass and make them stronger contenders for selection - they would
bump lighter balls out of the way.

As a result, lotteries adopted multiple ball sets, which get
rotated on a random basis, and each ball is carefully weighed and
inspected before each drawing, and the results are attested to by
an independent auditoring firm.

But still, as Gail Howard first observed, patterns seem to persist.
Some numbers come up, others don't. Over a period of some drawings,
the results change, but the general observation that there are
subtle patterns involved continues to persist. Gail Howard used
her background in programming and mathematics to track and
exploit these patterns. She still sells her "winning" (she boasts
that several people have used it and won big) lottory system, but
she has also inspired many imitators, some of which have tried to
develop far more sophisticated and agressive systems.

To try to put a value to such systems, I refer back to the
general observation of: "To win, you must play. If a system
encourages you to play and you win, then who is to say that the
system was not the cause of your success? But to not play makes
not winning a certainty." But don't forget the fact that playing
and not winning is almost a certainty as well, as the odds clearly
show.

I'm still struggling with my wheeling program. the problem is
that there are only a finite number of ways in order that the
picks can be organized, and if you want to avoid duplicates,
you can only partially rely on a random process of selection.
This is because at some point your selection process is going to
get down to a very few unused arrangements. As the choices
become confined, you also have a problem with whether all the
numbers are getting equal play as all the other numbers. A
random process exposes you to risks that each number is not
getting equal play.


I'm currently trying to use an elimination set, which is all the
possible unique pick combinations in order on a series of panels.
If I select a panel, I remove it from the elimination set, That
in itself gets rid of duplicates. But if I am selecting just a
subset of the elimination set, I need to ensure that each
individual number only plays to the limit allowed by the numbers
being pooled, the picks per panel, and the number of panels that
I am going to play. It's a bit of a balancing act.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged

Donald Darden
Member
posted January 08, 2005 06:00 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
Hi Michael,

Yes, "recursive" was the word I was trying to think of. There are
three problems with recursion: (1) Getting it to do what you want]
it to do, (2) Providing an embedded test case so that you can commense
to leave each recursion level at some point, and (3) ensuring that in
the worse case senario that you do not exceed available stack space.

Several sort methods make use of recursive calls, which have been
known to set an effective size on the arrays that they can correctly
sort. That is because they can exhaust available stack space.

Some eligant adaptations of these sort routines exist that use an
array to store partial results, rather than forcing them onto the
stack. Each recursion extends the array, and as each recursion
is exited, the array is contracted and the partial results
incorporated. This method allows the recursion to be extended
to the limits allowed by available array space, whether in RAM
or as part of an external table on a hard drive.

Recursion gets a bad name, mostly because either the test case
failed, or the stack space was inadequate. In my opinion, it is
just another tool to benefit the programmer, needing to be
understood and used appropriately, rather than condemmed outright.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged

Tom Hanlin
Member
posted January 09, 2005 05:47 AM     Click Here to See the Profile for Tom Hanlin     Edit/Delete Message   Reply w/Quote
Recursion is often elegant and often inefficient but, stack space should
rarely be an issue on modern machines... except for grossly nasty cases
like paint/fill algorithms. "Devilishly tricky to debug" is foolishness.
Recursion works or doesn't. You know what's going on in a recursive routine.

If you want something devilishly tricky to debug, start with the THREAD
statement. Conflicts between multiple threads often occur "at random" and
are sheer bloody murder to find and fix.

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself

IP: Logged

Michael Mattias
Member
posted January 09, 2005 09:34 AM     Click Here to See the Profile for Michael Mattias     Edit/Delete Message   Reply w/Quote
quote:

"Devilishly tricky to debug" is foolishness.

But, but... that's what PowerBASIC Inc says!

(Actually that part of the statement is not nearly as sexy as "seductively elegant")


IP: Logged

Donald Darden
Member
posted January 10, 2005 01:20 AM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
Licked my Wheeling problem in trying to maintain an equal number
of plays for each number given a specific number of panels to fill.
However, it required a brute force method - If I find a number has
played too often, and another not enough, I pick a selected panel
that contains the first number but not the second, see if it is
still available, and if so, make a substitution. After all the
counts are adjusted, I check again, until the most selected number
is within one count of the least selected number.

First occasion I've had of using the MAT array2() = array1() as a
quick way of producing a duplicate numberic array. That let me
test results before I committed to them. The ARRAY SCAN was also
useful for finding out if and where a certain panel was in the
elimination set. Since I was looking for an exact match, I did not
have to resort the elimination set each time when I swapped out
a panel in it with one that I was trying to remove from my
selection.

Unfortunately, the MAT method of duplicating an array is only
applicable to a numeric array. It would be neat if it could
work for UDTs and String arrays as well.

I'm having a bit of trouble with the math involved. If you have
a pool of 9 balls, and six picks per panel, how many cards would
you have to buy to play all nine balls an equal number of times?
The answer is three: 1-2-3-4-5-6, 7-8-9-1-2-3, and 4-5-6-7-8-9.
That would be twice each. How many panels to play each number
just once per card? Easy again. 1,2,3,4,5,6,7,8,9 would be 9
cards, with random picks for the other positions on each card.
Now here is a tricky one. How many cards do you have to buy to
ensure that if any six of the nine numbers in the pool are drawn,
that at least 2 of that six will be found on at least one bought
panel?

If course there is no payoff for just 2 of six matches, so the
next question is, assuming again that all six winning numbers
are in the pool of nine numbers, how many panels do you need to
play to ensure that at least 3 of the six picks are on at least
one of the bought panels? Same question with 4 or six and 5 of
six.

The problem revolves around the combo() function, which can be
expressed as:


FUNCTION combo(n AS LONG, k AS LONG) AS EXTENDED
LOCAL plays AS LONG, value AS EXTENDED
value=1
FOR plays=1 TO k
value=value*(n-plays+1)/plays
NEXT
'PRINT k"of"n"="value
FUNCTION=value
END FUNCTION

If there are 53 numbered balls in a lottery, and you have six
picks per panel, then the total number of unique panel combos
that can occur are combo(53,6), or 22,957,480. If you have a
bonus ball as well, and say it goes up to 47, then you would
calculate combo(53,6)*47 as your chances of getting the grand
prize.

To guarantee that you get all 6 matches, whatever gets drawn,
you would have to buy up all 22,957,480 unique panels. That
might be a bit difficult and a little too expensive to do, so
you consider your next option: Buying just enough panels to
cover your preferred list of numbers. Your hope is that this
list of numbers will contain the six numbers finally drawn.

The same combo() function serves in this case as well. If you
have a pool of nine numbers, then the function combo(9,6) says
that you would have to buy and fill out 84 panels using unique
arrangements of those nine numbers, so that if those six balls
are found in that list, you have a panel with those six numbers
on it.

Remember, right now we are not thinking about the (53-9), or 44
numbers that aren't in out list. For whatever reasons, we put
them aside and are just focus on our pool of numbers. So you
should not lose track of the fact that we have to get terribly
lucky for even three or four of the winning numbers to end up on our
list.

So it looks like we have to try and make good on that three or
four that might show up. Now using the same Combo(9,3), we
have to play 84 panels properly numbered to ensure a 3 match.
Using Combo(9,4), then number jumps to 126 panels. So you
figure that with five of nine, then combos must be getting really
big, right? Actually, Combo(9,5) is also 126 panels. In fact,
Combo(9,6) is back down to 84 panels. The reason is that we
exceeded the midpoint of the pool of 9 numbers, and that means
that the ways of uniquely arranging that many numbers in those
size sets becomes restrictive. Of course if you have a larger
pool of numbers that you favor, the number of panels can go way
up.

Now that's the way I've worked it out so far. If anybody wants
to find fault with this, and can show me what really works, that
would be most helpful.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged

Robert DeBolt
Member
posted January 10, 2005 06:59 AM     Click Here to See the Profile for Robert DeBolt     Edit/Delete Message   Reply w/Quote
Donald,

Interesting discussion. I find no problem with the math.
About 20 years ago, I tinkered with the same ideas that you have.
I started a pool at work so we could buy more tickets (panels?) as
a group than we could individually. Over a period of about three
months, we won nothing. Finally, I decided to give it up. On that
last drawing, a five dollar ticket returned $7.50 for the members
of the pool. However, I discovered that the wheel sets I chose
had a greater proportion of "hits" than could be attributed to
chance. Unfortunately, combo(6,3) doesn't pay out. According to
my simulations, you really didn't start winning until you would
play over $10,000 per week.

So, what method did I use to pick the pool of numbers to wheel?
I took the last ninety drawings and compared each panel to every
other panel. The results are shown in a ninety by ninety matrix.
Of course you only have to display the lower half of the matrix
since it is symmetrical about the diagonal. Discard the diagonal
since it is the same panel compared to itself.

For each cell in the above matrix, place an "X" in the cell if the
two panels have at least one common number, else leave it blank.

Print out the matrix and observe the pattern of X's. You will see
that there are some long "runs" of X's, either horizontally or
vertically. So, if you see a long unbroken column of X's, then
you could concievably construct a pool of number consisting of
those intersections of sets of panels. Of course, you can refine
the matrix to show what numbers appear in the intersection.

So how accurate is this method? It falls into the realm of WAGs.
In the early days of lotteries, patterns really did exist in the
drawings, and people took advantage of them. Now, however, the
balls are carefully painted, balanced and weighed. Furthermore,
trays of sets of balls are randomly selected to ensure that certain
trays cannot be predicted.

My conclusion: You can't predict random numbers. If you could,
then those numbers are not random by definition.

Of course you can use statistical probabilities to describe the
mathematical model of a given lottery, but that knowledge doesn't
give you any advantage over anyone else.

Bottom Line:
------------

If you have money burning a hole in your pocket, then pick your
numbers and stuff your money in an old sock. If your numbers
happen to win, pay your winnings out of the old sock. Then, a
year from now, empty the sock and revel in how much money you
would have lost if you bought tickets.

But what if you really hit the big one? You could kick yourself
around the block. But I wouldn't bet on it.

Better yet, invest your ticket money in the stock/bond/real-estate
markets. It will grow much faster (if invested wisely) than the
old sock. After all, Wayne Rogers, Warren Buffet and Donald Trump
can't all be wrong.

------------------
Regards,
Bob

[This message has been edited by Robert DeBolt (edited January 10, 2005).]

IP: Logged

David Roberts
Member
posted January 10, 2005 09:24 AM     Click Here to See the Profile for David Roberts     Edit/Delete Message   Reply w/Quote
Donald

Have you played with the Hypergeometric probability function?

When you write combo(n,r) I write nCr.

For,
N=population size
n=sample size
k=number of items in population labelled "success"

we have h(x; N, n, k) = ( kCx * (N - k)C(n - x) )/NCn ... [1]
where x = 0, 1, ... , n.

With your "If there are 53 numbered balls in a lottery, and you have six
picks per panel..."

we have N=53 and k=6

and with your "If you have a pool of nine numbers ..."

we have n=9.

From [1] we get,

h(0)=0.30748374
h(1)=0.42574673
h(2)=0.21287336
h(3)=0.04845897
h(4)=0.00519203
h(5)=0.00024149
h(6)=0.00000366

giving a total probabilty of 0.99999998, say, 1.0

It follows then for 3 or more the prob is 0.05389617
or 17.55 to 1 against.

More info on the hypergeometric probability function at Site 1 and Site 2

I had a battle royal with a guy who proposed a strategy based upon the second
law of thermodynamics, ie entropy, and the best rebuffle I saw was from a
mathematician who said "lottery balls don't have a memory". I had already argued
the case that if a coin was tossed 19 times and it came up heads on
each and every toss then the probabilty of a head on the 20th toss
was still 0.5 as the previous 19 were 'done and dusted'. The probabilty of 20 heads
from the outset is a different matter, ie 9.5*10^(-7), giving grounds to doubt an
assumption of non-bias.

Have fun.

------------------
David Roberts

[This message has been edited by David Roberts (edited January 10, 2005).]

IP: Logged

Donald Darden
Member
posted January 10, 2005 05:43 PM     Click Here to See the Profile for Donald Darden     Edit/Delete Message   Reply w/Quote
One of the seductive arguments for playing Lotto is that your odds
of getting at least 3 of 6 to match in a drawing were about 1 in
7 or 1 in 8. That means if I play twice a week, and spend five
dollars each time, I should expect to win a free card on the average
of about once a week. That's not so bad.

But I wasn't getting anything like that as a result. In fact I was
having a long dry spell. In going back to several web sites, I
still see that claim, and one site even give me enough information
for me to determine the method by which they were apparently making
this calculation. Based on their apparent approach, the odds of 3
of six with a ball range of 53 worked out to be 1 in 162. Still
well away from the low odds that were often quoted. And the method
of doing these calculations was found to give totally flaky results
under other conditions - you don't end up with needing zero panels
to ensure that 1 of nine balls is played, for instance. Or having
to buy an infinite number of panels to ensure that 6 of 6 balls is
matched during the drawing.

The way I calculate it, is that you have one chance in 53 of
matching the first ball. With that one matched, the second
number has to match one of the remaining 52 balls. With that
one matched, the third ball has to match one of the remaining
51 balls. To state this another way, you need 1 of 53 AND 1 of
52 AND 1 of 51 to get a 3 ball match. To express this in a more
mathematical form, you calculate 1/53 * 1/52 * 1/51 =
0.000005801137023. Or invert that formula and find that
53*52*51 = 140,556. Now if you divide this by the number of balls
you matched, you would get 46852. Divide it by the number matched
less 1 (3-1=2), and you get 23426, Divide it by the number matched
less 2 (3-2=1), and you end up with 23,426. No need to go any
further. In essence, this is what Combo() does, and it gets the
same number: Combo(53,3)=23,426. So this says that the odds of
getting 3 matches in a lottery with 53 balls is only 1 in 23,426.

So how do these experts come up with 1 chance in 7 or 8? I don't
know. I suspect it has something to do with the fact that you are
really playing six balls per panel. So it could be not only any
of those six, but any combination of three of those six. One
could argue that this is 6!, which is 720 combinations, and
23,4236/720 is approximately equal to 32.5. But using Combo(6,3),
we get only 20, so the correct answer seems to be more like 1
chance in 23426/20 = 1,171.3 of getting a match off any 3 numbers
in a panel.

So if you are looking for a few small wins from time to time to
sustain your faith in winning, it doesn't look like you are going
to get much help here. On the other hand, Lotteries that add in
a Bonus ball will report a win if the Bonus Ball matches. If the
highest bonus ball number is 47, then that means that you can
expect a bonus ball match every 47 drawings for any given panel.
Bonus balls may also cause 1 number and 2 number matches to pay
out as well, that could result is 1 in 47 + Combo(53,1)*47 +
Combo(53,2)*47 = 1/47 + 1/2491 + 1/64766 = 0.021693481, or if we
invert the answer, about 1 in 46 chances of a panel getting
something of a win when a powerball is involved.

If you spend $5 to buy a card's worth of five panels using different
numbers, a single card increases your odds by five times, so now you
have about 1 in 9.2 chances of a small win in a powerball game.
That adds up to slightly less than one small win every month if
you buy five panels (1 card's worth) when you play twice a week.

So Powerballs help sustain the illusion that you are close to a
real win, by masking the difficulty of getting other numbers to
match up.

My wife just asked me if she needs to start budgeting a few
dollars each week so that I can use this information and play
the lottery. I sort of laughed and said that I'd hold off on that.
But for fun, I might start tracking how well my programs are
doing in conjunction to the Florida lottery. Of course there is
a (very very small) chance I might miss out on a big prize if I
don't rush right out and buy those tickets, right?

No, I'm sort of doing this for other members of the family - my
brother-in-law and stepdaughter both asked for a system to help
them in their weekly plays. He plays Florida, she plays the
PowerBall. Like I said, if you are going to play anyway, it's
probably better to use a system.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

IP: Logged


This topic is 4 pages long:   1  2  3  4 

All times are EasternTime (US)

next newest topic | next oldest topic

Administrative Options: Close Topic | Archive/Move | Delete Topic
Post New Topic  Post A Reply
Hop to:

Contact Us | PowerBASIC BASIC Compilers

Copyright © 1999-2005 PowerBASIC, Inc. All Rights Reserved.


Ultimate Bulletin Board 5.45c