![[UK National Lottery Logo]](/Lottery.gif){kind=small}
Next month: February 1996
Linked the Prize, Winners, Total and Ticket sales headings on each individual lottery page's results table to their respective overall tables (yes, I should have done this many months ago...). Bolded the left-hand side of that table too, since they are really headings as well.
Added a mention of sci.math contributors who helped in the construction of the 174-ticket wheel, although since Mat actually sent me the wheel, he gets named explicitly. Temporarily withdrew the InterLotto ticket sales information, since the organisers haven't released that yet (though they eventually will apparently). Disallowed [ or ] in the e-mail address submitted to the virtual lottery (yes, someone used a [ by mistake for the first time this week). Bought 2 extra tickets for next Saturday's double rollover.
Finally got around to writing quite a complex internal link checker in C for the Connect server - it picked up a few bad links on my lottery pages (mostly defunct references in this What's New section) and a ton on the rest of the Connect server, which have all now been fixed. The checker is extremely fast - it checked 1,373 HTML documents (basically the entire Web server I use at home) on my home machine in only 24 seconds ! Yes, it's clever enough to remember where's it been before and it generates only one warning per bad link and it also doesn't get stuck in circular links of course. It can usually "deduce" where the root server directory is without you telling it (by following upward-pointing relative internal URLs). Interestingly, I initially did it depth-first, but this opened too many files simultaneously, so I switched to breadth-first, which was quicker anyway.
The next big enhancement will be to tie-in external link checking too, keeping a permanent record of external URLs and datestamps when they were last checked (because you only want to do a full check once a week - the daily checks can be done on new external URLs only). Once I've finished the project, it's probably something I will release into the public domain because there's no really good internal/external link checker for WWW sites out there.
I decided to revamp the speech CGI to support either .wav or .au format depending on the contents of the HTTP_USER_AGENT environmental variable. If it contains the "X11" string, then it's a UNIX WWW client and the sound is sent in .au (audio/basic) format. For all other cases, it is sent in .wav (audio/x-wav) format. Sounds easy enough, but sending a joined .wav is harder than a joined .au because the former has a header, whilst the latter doesn't.
To get around the problem, the first .wav sample to be sent has its length value (bytes 41-44 in the header) changed to be [the total length of all the .wav samples - (number of samples-1)*44]. To be awkward, PC stores its 4-byte values in reverse to UNIX, but that was easy to translate with a shifting loop. Yes, this is all convoluted because second and later .wav samples have their 44-byte header stripped off when sent by the CGI program. I used "sox -t ul -r 8000 sample.au sample.wav" to convert each sample to .wav format and then spent the rest of the afternoon trying to get PC Netscape 2.0b6 to correctly run the sound player.
It turns out that it doesn't (a definite bug), whereas PC Mosaic 2.0 was quite happy once I'd set up the same helper application as I tried in Netscape. I proved it conclusively by copying the "say" CGI to "say.wav", hacking the home page to run say.wav instead and then clicking on the link: this worked in PC Netscape with the helper application, indicating that Netscape incorrectly insists on .wav-generating CGI programs being called something.wav, even if they send Content-type: audio/x-wav, like mine does of course.
Oh, finally, I reduced the alarm time to quitting the "say" CGI program to be [total length of samples in bytes divided by 100] seconds, to make sure it doesn't hang around any longer than it should (a Netscape Commerce Server bug - it doesn't correctly signal CGI children to terminate). Of course if your net connection to the Connect site is less than 100 bytes per second, it would quit early, but if you're surfing at those speeds, you shouldn't be downloading 70K sound samples !
I was relieved to see that the auto-update worked for a change, so I'm moving the teletext mail request forward one minute to 8.00pm, although I seem to remember that the last time I did that, the mail came back too quickly. However, with the Might BU site bragging about how fast it can update results, it's worth the risk. It's a big gamble though - I'll either get the results extremely quickly or it'll backfire and the update will be delayed an hour. We'll see...
I went through the pages with the usual checking tools: "spell -b", "weblint -d heading-order" (I strongly disagree with that warning !) and I ran the C software through "gcc -Wall" and "lint". Yes, there were 2 or 3 spelling mistakes and I also changed the incorrect "<BR ALIGN=center>" (well, I don't see why BR shouldn't have that attribute !!) to "<BR>".
I decided to add a search facility to the Lottery Links page, but don't get too excited, because it's incredibly primitive. Bad features include:
All in all, a pretty shabby search engine - the Skoda of search engines if you like. :-) It's better than nothing, but only just. BTW, the HTML used for the search box marks the first use of the <DIV> tag on my lottery pages. I couldn't find any other way to centre an <INPUT> text box, but the tag works OK in Netscape 2.X and arena, so I'm happy to use it.
It was more painful to compile the new version of "verify" on a PC than I expected. I'd used getopt() to parse command-line arguments and I was quite surprised to see that Watcom C/C++ didn't have that function ! It meant I had to get the source to getopt() from GNU gzip 1.2.4 and supply that too (along with the GNU licence). Meanwhile, I'd stupidly left a ticket line commented out (it was deliberately done during testing to force losing combinations) in wheel174.txt, so the Lottery Perms page option for 174 tickets went somewhat berserk. It's now fixed.
The 174-ticket "at least 1 three-match" option on the Lottery Perms and the 24-ticket Quick Pick with a ticket history is now lightning fast - I've transferred all lotteries' prize amounts to an integer array and now scan this in a tight loop. It's effectively "instant" to the end-user and is the last slow CGI code on the lottery pages to be eliminated. Now if only I could find a way to speed up the generation of the best performing tickets page, because that gets slower and slower each week of course.
The new locking code was actually stopping the InterLotto updates from working correctly because it locked them out (I'd called the script recursively, so the InterLotto update code was sitting on a lock that it had created itself !). This has been fixed. Meanwhile, there's been a price adjustment of the cost of an InterLotto ticket (down from 5 SFr to 1 SFr), which gave me the impetus to properly adjust the balance on the CGI-generated pages returned from checking InterLotto tickets (5 SFr for lotteries #1 to #13 and then 1 SFr thereafter).
I went back to the Ticket Checker code and fixed a long-standing minor annoyance - the text that said "No valid ticket entered !" if you went straight to that page and clicked on "Check tickets" without actually entering a ticket was incorrectly displayed pre-formatted and has been ever since that page was first was made available ! The problem has been fixed. Trying out some random values on that page, I was horrified to see that it let the number 0 through as a valid number on a ticket to be checked...that bug was squashed in double-quick time, although I'm quite surprised no-one reported it to me. The virtual lottery winner total on the Entry Matches page was incorrect because it included an "winner" who failed to claim the prize - this has been fixed.
You've got to be sceptical about why it will have taken 16 months for Camelot to introduce a Quick Pick facility (called Lucky Dip) to their lottery terminals starting from March 1996. I personally reckon it's because a random number generator would scatter the combinations covered by punters more widely, leading to a lower chance of a rollover. Camelot make the most profit when there's a rollover because of boosted ticket sales and hence there was an incentive for them to withhold the facility for as long as possible. This logic is pretty well flawless, although you can bet Camelot will come up with some (incorrect) defence for the huge delay !
Yes, I sort the winning numbers if a WWW site prefers to present them in draw order and also ignore the winning number info if there's any numbers outside the range 1 to 49 or if there's any duplicates. The most complex part of the coding was the section to tack on a correct credit (including a site link if it's a URL) to the "Provisional information courtesy of..." message during an auto-update, especially since the jackpot amount could be sourced from somewhere different to the winning numbers. It was important to get this right, because I wanted to make sure the source(s) of the results was properly credited.
Basically, I now have 6 sources of winning numbers (2 teletext, 4 WWW) and 3 sources of jackpot prize pools (1 teletext, 2 WWW), so this should stop people complaining about auto-updates not working ! Another enhancement during the code hacking session included new locking code for the page generation scripts so that incoming e-mail from the teletext mail server doesn't collide with the cron jobs that may be re-generating pages at the time. I also slightly adjusted the column positions on the virtual lottery Entry Matches page (using printf()'s useful %*s and an array of field widths), mainly because the "Tot" line for 0-match and 1-match had exceeded the width I'd allocated for them.
The failed update (second week in a row) has got me thinking that since two WWW sites have already stolen my results pages, I may as reciprocate by scanning other UK lottery WWW pages on a Saturday night, looking for the latest result and then grabbing it, parsing it and using it for my pages. I would give full credit (including a link back to their site), if I did this of course. This would only be done if:
I would probably want to schedule a cron job every 5 minutes between 8.05pm and 9.00pm, every 15 minutes after that until midnight and then once an hour from then on until midnight Sunday evening/Monday morning.
This new code is very handy for the long-term too because it gives me two potential sources of winning numbers, with BBC 2's being the more trustworthy because it's prefixed with the date in "DD MMM:" format, making it fairly easy to parse out, as long as you can calculate the draw date of course ! That takes priority over ITV winning numbers, not that I can see any at the moment of course.
Wouldn't it be nice if BBC and ITV got their teletext services on the WWW ? It would be a lot easier for me then ("lynx -dump" every minute from 8.03pm until I get a result) ! Remarkably, neither the official BBC TV site [spot the lottery link !] nor the more well-known BBC Networking Club site have teletext on the WWW :-( This would be the single greatest improvement for UK users on the WWW if teletext was available (for free and none of this annoying registration rubbish) - it's updated minute by minute and is much more concise than the Electronic Daily Telegraph.
No, I didn't hang around at work on Saturday night to see if I'd won (or if the auto-update had worked) - it's back home to watch VR.5 on Sky One (what, watch the lottery show live ? What a waste of time that is when you can tape it and FF it later on...only lasts the ideal 2 minutes if you do that...). It's really annoying that Sky One slap the lottery numbers right on top of the gorgeous Lori Singer :-(
My boss came up with the idea of switching to BBC 2 teletext 750 as a backup for the winning numbers now that ITV teletext 123 is well and truly messed up. I hadn't used it before because there was no estimated jackpot on those pages, but it didn't take long to write some code to extract the winning numbers (trickiest bit was if there was a delay until Sunday, because finding yesterday's date in DD MMM format via shell script isn't as easy as you'd think). A quick test showed it to work OK and with some careful coding in future weeks, I might be able to use a combination of the winning numbers on BBC 2's teletext and the estimated/actual jackpot on ITV's teletext, but people will have to live without that for the moment, so there'll be no jackpot info in the auto-updates this weekend.
I got home on Friday evening, only to discover that Camelot had issued a press release during the day that the estimated jackpot was now at £40m and the total ticket sales are predicted to be a staggering 110m ! When I first ran my estimated jackpot code, it came up with a figure of £47m, which I thought was too high and I toned it down to £35m - maybe I should have left it alone ? I found a bug in the new hastily-written auto-update code that would cause a failure if the return e-mail didn't come back by midnight on Saturday evening/Sunday morning. I've fixed the bug at home, but I'll keep my fingers crossed for tomorrow evening's update...
Also on the Friday evening, ITV teletext page 321 gave these quotes: "...and even on the high-tech Internet, there is an analysis of which numbers come up most frequently." and "...the Internet analysis of the numbers since the draw began..." and then proceeded to quote information on frequencies taken from my pages. However, like most UK media, they foolishly omitted the URL...grrr...! Mind you, I'm in dispute with ITV teletext as to their new 1996 layout of page 123, so I guess any mention, assuming they are talking about my site of course, is better than none at all. However, ITV teletext want me to apply for permission to use info from their lottery page - sort of two-faced don't you think when they took info from my pages without crediting the origin [at least I credit ITV teletext when I use their info !] ?
I saw a TV ad for The Sun newspaper this evening that was interesting - they've bought 40,000 lottery tickets and will pick 100 Sun readers at random to become syndicate members and share the prizes those tickets will have won in the double rollover draw. Does this make that newspaper the biggest ever purchaser of tickets for a single UK lottery ?
The fast integer ball array I've been using to speed up the best performing tickets page is now defined for all programs, which has allowed me to speed up the number selection strategy code check for prior 5+bonus/jackpot wins (the slowest part of the check by far). This reduced the execution time of the 174-ticket perm mentioned above to around 8 seconds on my home machine. If I can speed up the wins/ prizes check, that should go down to about 5 seconds, but it's easier said than done ! Also note that the code improvement has speeded up the Quick Pick CGI code when a ticket history filter is used. It's now down to about 2 seconds on my machine, with possible further speed improvements due if I get that wins/prizes check fixed (which is now officially the slowest code of all CGI lottery programming I've done to date).
Updated the Lottery Links section substantially - it's now reached 150 links for the first time. I also discovered that Yahoo has added my Lottery Links section to their list of lottery sites.
Fixed a bug I missed for a while w.r.t. to the "at least 1 two-match if X is drawn" option on the Lottery Perms page. The value of X that was typed in was being ignored and a random number was used instead :-( It works fine now. Fixed another bug that was causing the Quick Pick code of the lottery CGI program to hang and use infinite CPU if the ticket history filter was used. Fixed yet another bug that was causing the individual lottery page generation for InterLotto to fail (it was because of a backwards multi-rollover check I'd added for the UK lottery that hit the InterLotto pages because they've pretty well all been rollovers so far).
Compiled the verification software I mentioned above on a Pentium 90 using Watcom C/C++ and it worked first time (was 50% slower than my 712/60 at home...ha !). I've got a "verify.zip" file ready for distribution, so expect to see some new pages soon. Meanwhile, Radio 5 Live contacted me trying to a do a phone interview, but I turned them down flat. I'm afraid the UK media is so appalling, that there's no way I'm doing any more interviews for anyone.
Bad news as ITV teletext page 123 changes its format for the worse - the way the graphics surround the winning numbers now means that the teletext mail server strips thems out before mailing me the pages. Therefore, the new format will not allow me to get the winning numbers automatically. Apart from that change, the footer is now about 8-10 lines high containing an advert and this leaves precious room for the actual text in the middle of the page (typically 6 or 7 lines now !). What an awful downgrade that was :-(
Previous month: December 1995
![[What's New]](/nav/WhatsNew.gif){kind=small}