[OT] Re: Problems retrieving items from a list {lottery numbers}

[eltronic at juno.com]

> >At 04:05 PM 7/17/2003 +0100, Rogue9 wrote:
> >to illustrate the problem I'm having.Therefore I have 
> >printed the listing  below which is quite short 
> >and hopefully won't annoy too many people
> >about the length of my post.
> >To reiterate:
> >The masterList holds the results for the UK lottery

>[snip]
On Thu, 17 Jul 2003 10:51:41 -0600 Bob Gailer <bgailer at alum.rpi.edu>
writes:
> I sure hope you are not writing "yet another winning lottery number 
> predictor". It is a sad commentary on mathematics education when 
> individuals belive that one can predict the outcome of a truly 
> random 
> process based on any history. 

there are only few things more important than understanding just how
random a list of numbers are. although, I agree the properly conducted
lottery is random enough, therefore, we agree, don't quit your day job.
in NY's pic3, randomness is ensured by randomly substituting each
component of the draw, number balls, machines, air pressurem weather, who
knows what else. and one can assume, sophisticated PHD's whose job
depends on ensuring randomness are working on the list and sharing info.

in NY numbers pic3, 000 to 999 possible, 1 of 1000.
presumably the easiest to guess. if you think its impossible to narrow
down the numbers to a buyable amount, then you have either never tryed or
failed or believe people who tell you that its impossible. if anyone
tells you its possible to narrow down the list to a buyable amount day
after day, or on any particular day, they haven't run enough simulations.
IMO, independant of amount of data and assuming all data is accurate. we
know there are winning tickets out there never cashed in because the
newspapers or official websites published the wrong info,
mixed up the days, transcription errors, random bit errors. letting
history go beyond a few weeks is useless due to the changes in the
picking operation itself. and a few weeks of data isn't enough to turn up
miniscule variations assuming you could correct for the weather.

 you will stand to win more than you spend or lose more than you spend on
tickets. no one can guess which it will be. faith to overcome the reality
that you will lose more often than you will win is a personal, however
flawed, decision. the falacy is that because position one number hasn't
appeared for 28 days, it soon must. and it forces you to pick position
two and position three ready or not.
the simulation of possible numbers bought and outcomes is the more
valuable program. 

randomly picking numbers from all possible numbers is often as good as
culling a list of ready to hit numbers.
a good source of random numbers is, you guessed it, lotteries. but in
this case you really don't want random numbers you want a repeatable list
that matches pervious picks extropolated into the future.
I repeat, the numbers I'm familiar with are random.
creating a system of narrowing down the numbers is probably a lost cause,
possibly in violation of the rules.
it really depends on how much you desire to get out of the exercise, so I
cant really quibble with the futility point.

with that disclaimer:
write smaller bits of code which can be tested separately.
docstring testing is great for this. it specifys how the function will be
used and if the data changes you can more easily adapt. 
 with out seeing more of the code itself, its hard to guess if the
program is correct from unit test and data. to simplify the program you
might try to pick just the first number of the day. as you know the
numbers are often sorted for publication, if so, you begin with flawed
data.



e

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!