draw 4.00 (C) Richard K. Lloyd 2010 This is a program which simulates both main UK Lotto ticket purchases and the live main UK Lotto draw. The latest version can be downloaded from http://lottery.merseyworld.com/DrawSimulation/ Linux packages are in .tar.bz2 format and therefore require tar and bzip2 to unpack, e.g. "bzcat draw-4.00-src.tar.bz2 | tar xvf -", which unpacks the source code into a draw-4.00 sub-directory. Windows packages are in .zip format and can be unpacked by double-clicking on draw-4.00.zip in Windows Explorer (XP or later) and dragging the draw-4.00 folder to a second open Explorer window (e.g. one viewing C:\Temp for example) to unpack it. Mac OS X packages are in .dmg format and should be double-clicked on to create a "disk" on the desktop. The disk should also be double-clicked to view its contents (a draw-4.00 folder) and the contents should be dragged to some suitable installation folders (Applications or wherever you like really). Finally, you should "eject" the "disk" (right-click on it and select "Eject") to remove it from your desktop. Note that you should use a terminal to execute the test suite rather than attempting to double-click on files inside the draw-4.00 folder. Type "draw -h" to get a list of all the available command-line options. To try out a draw simulation: Linux or Mac OS X (in a terminal window): cd draw-4.00 ./testsuite Windows (in a terminal window): cd \Temp\draw-4.00 (or wherever dir you unpacked to) testsuite.bat Windows (from Windows Explorer): Inside the draw-4.00 folder, double-click on the testsuite.bat batch file. This program is licensed under GPL 3 - see the COPYING file for the license details. The source code package and Windows binary package also contain "cygwin1.dll", taken from the Cygwin package (see http://cygwin.com/), which it itself licensed under GPL 2 (see http://cygwin.com/licensing.html). Code from the Blender package (http://www.blender.org/ - GPL 2 licensed) has been used to determine the number of CPU cores on various platforms. Please send any suggestions or bug fixes to webmaster@lottery.merseyworld.com The program has the following features: * It can "randomly" generate tickets, with some slight skew towards the more popular numbers picked as seen on this page: http://lottery.merseyworld.com/Analysis/PopularAll.html The user specifies the ticket sales (from the keyboard or via the -t option) so that the appropriate number of random tickets can be generated. Random ticket generation is seeded either by the current time and process ID or by a user-specified seed value (-s option). If the -i option is supplied, then tickets are read from standard input instead as lines of 6 numbers per ticket. Each input line must contain exactly 6 unique ascending integers between 1 and 49 separated by one or more spaces - any other layout will reject that ticket. * It can handle either rollover amounts from previous draws (which would also include Super Draw top-ups, which are effectively the same thing) or exact Super Draw jackpot prize pools (e.g. 15m). These are specified with -r (rollover top-up) or -r = (Super Draw exact jackpot prize pool) respectively. * By specifying the -o option, it can re-output the tickets that it has input or generated back to standard output, should they need to be piped to another program. In fact, that's how the test suite run by "gmake check" works - it pipes the "live draw" random tickets through to a second copy of the program in verification mode (-v option). Note that all other program output goes to stderr to avoid it being mixed with ticket output. * Each of the 7 numbers of the main Lotto draw (6 main numbers and the bonus number) can be read from a file, input via the keyboard or specified by multiple -b parameters. To terminate keyboard or file input, a "0" terminator should be supplied (typically as a theoretical 8th number) - this isn't needed when 7 valid -b parameters are supplied though. * As soon as each number is known, a full table covering the number of 0-match through to 6-match tickets so far is generated (obviously, some rows will be empty if not enough balls have been drawn yet). Once the 6th main ball is drawn, the individual prize amounts and total prize pools of all categories except 5-match and 5+bonus are displayed. Once the bonus ball is known, the final prize amounts/number of winners in all categories calculated are displayed. * The number of CPU cores (up to 16 or the number of cores in your machine, whichever is the lower) used by the program can be specified via the -c option (it defaults to the highest number of cores usable). This uses a parent process and one or more child threads to roughly linearly speed up the code. * A separate post-draw verification algorithm, activated with the -v option, was also written, which is not only coded very differently, but requires the 7 drawn balls to be known *before* any tickets are input. As each ticket is input, it calculates the number of matches that ticket has achieved, allowing fast generation of a verification table of the number of matches in each category. This is for ease of mind to prove that the "live draw" main algorithm has not mis-calculated the number of matches in each category. On a Q6600 quad core CPU 64-bit Linux system, the slowest table (after either the 6th or bonus ball has been input in a "live draw" scenario) is generated in approximately 0.37 seconds. Somewhat surprisingly, the 32-bit binary (run on a 64-bit Linux system) is even faster at 0.22 seconds - I need to investigate why this is the case. The ChangeLog has the latest timings - I pushed them to the limit with an 8-core 2.53Ghz E5630 server to get a new all-time record of 0.11 seconds! So what's the point of the program? Well, I wanted to see if it was possible to generate "real-time" (i.e. under the 6 seconds between each ball) information on the number of matches (and ultimately the prize amounts/prize pools in the final table). By hitting below the 0.5 seconds mark for the slowest table, I have categorically proved that there is absolutely no reason for Camelot/BBC not to display the same info on their live UK lottery TV show. They have *never* displayed this info since the first draw started in 1994 - it's about time they did! The code should compile on pretty well any Linux or Mac OS X system (32-bit or 64-bit) - if you're stuck with Windows environment, then I suggest you look at cygwin.txt if you're still keen to build this program on Windows from source code. I have managed to set up a Mac OS X VMware/Xcode environment on my Dell, so I can now provide Mac OS X binaries with each release. One final note - although this release of draw was developed on 64-bit Fedora 13 (which ships with gcc 4.4.4), the 32-bit and 64-bit Linux binaries were compiled on that platform using a copy of gcc 4.1.2 from 64-bit Fedora 8 instead. This is because later gcc releases produce very slow code compared to gcc 4.1.2, at least for this draw program anyway.