|
Author
|
Topic: Looking for Reiterative Solution
|
Donald Darden Member
|
posted January 07, 2005 06:16 PM
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 STRINGFUNCTION 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
Donald, no promises that it works under all circumstances..Paul.
GLOBAL ns AS STRING GLOBAL x AS LONG GLOBAL pool AS LONGSUB 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
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 LONGFUNCTION 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
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
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 LONGSUB 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
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
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
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
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
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
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
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
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
DonaldHave 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
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 |