shellgrip

Hi Willa, We've ended up going with a frequency based approach described by Bignose. What we'll do is analyse the number of entries against the expected number of entries and the number of prizes. So, if after 8 days of a 100 day competition there have been 500 entries, we estimate a total number of entries of 6250 and with 10 prizes that means a prize every 625 entries. I think, in theory, this should be 'self-adjusting' which we'll need since we can't accurately (or even approximately to be honest) know how many entries there'll be. Your suggestion is equally valid, I think, although I'd still be concerned that this might end up with all the prizes in a bunch. Plus, of course, since these dates would need to be stored somewhere the administrators would be able to find them. Since that's only really me, that's not a problem but I prefer the idea that even I won't know exactly when a prize will be awarded. My next step (today hopefully) is to code a test routine to ensure my code for the frequency system works... Thanks for the response and the suggestion. If the frequency route doesn't work it may still be the way we do it!! Jon

Hi Bignose, thanks for the reply. IF the client decides they're happy with a 'delayed' draw then doing it that way is certainly a lot easier, it's just that at the moment they're saying they want it to be an 'instant' notification: you type the code in, press submit and are told straight away whether you've won or not. I like the 10,000th entry idea - I'll admit that's something that completely slipped by me and it's a good one. The only problem is of course that 9,999 people simply cannot win after a prize is awarded but I guess the 'luck' factor there is in where you are in the counter when YOU choose to enter the comp. At the moment we're leaning towards pre-selection. I'm going to generate all the numbers to be used in the comp (using various checksums, etc. to prevent random entries) so it's a simple task to pick X winners from that list. My only problem here is that I'll know which are winning tickets (including the code to type in) or could fake a win. I guess that's something that applies to lots of online comps though. Thanks again, any more ideas, suggestions, keep 'em coming Jon

Hello! I'm a web programmer and have been commissioned to develop a simple site that accepts a 'ticket number' and then tells the visitor instantly whether they have won a prize or not. What seemed originally like a simple problem has, under further thought, proven to be nothing of the sort and I need expert help. The problem is largely that of ensuring that the prize allocation is fair, logical, and evenly distributed. This aim is complicated by the following factors: The competition is based upon physically received leaflets following a visit to a store. The competition will run for three months or thereabouts. The number of prizes is very small in comparison to the number of entries. What all this means is that I cannot simply use a 'random number' device to decide upon a winner. Doing so presents a finite possibility that all the prizes will be won in the first week or that none are won at all. Neither can we limit prize winning based upon those already won (we can't say a prize has been won this week so no one can win now until at least Monday morning) as this would be demonstrably unfair. My current thinking is that the best solution is to perform some kind of operation on all, or part, of the 'ticket code' (the structure of which is entirely up to me) such that there is a specific probability of winning for any ticket, which matches the number of prizes and the anticipated entrants. So, for example, if there are 10 prizes and 10,000 entrants, I want the operation to result in a probability of 1 in 1000 that this ticket is a winner. The operation must work on all ticket numbers so that every one has the same chance of winning and should preferably, be somewhat flexible such that if, as the competition progresses, it becomes obvious that we're not going to get 10,000 entrants but only 6,000, or 20,000, that the odds will automatically alter. To introduce a truly 'random' element into the selection process I'm considering using the time of entry as part of the operation. Although I've got this far in the thought, I'm afraid the actual math is beyond me - I think. Can anyone help with what I should be doing here, or suggest an alternative approach? My need has become rather urgent as the customer is itching to start printing the leaflets and I haven't got a code structure to give them yet! Jon