Here's an interesting article related to this -> http://www.codeproject.com/KB/recipes/combinations_cpp_2.aspx.

]]>

Krish

The answer is in a table I made Combinations per Pool. For a Pool 34 Pick 7 your chances of getting any Seven is 1 in 5,379,616.

To calculate for any Contiguous Numerical Order or Consecutive Sevens - first work out how many there are, which is 28 -

01 02 03 04 05 06 07

02 03 04 05 06 07 08

.

.

.

28 29 30 31 32 33 34

Then, simply multiply by the ratio to get the probability

28 x 1/5379616 = 0.0000052 or 0.00052%

What this means is any set of 28 numbers you care to nominate has the same chance of having the winning number.

If you played any 28 numbers once a week for a year then your chances of a first prize are 52 x 28 x 1/5379616 = 0.0002704 or 0.02704%. For 50 years you are looking at 50 x 52 x 28 x 1/5379616 = 0.01352 or 1.352%.

If you increased the lines played to 1000 a week then over 50 years it is likely but still not certain that you would win first prize ie 50 x 52 x 1000 x 1/5379616 = 0.0096 or 96%. The number of plays you have made if all are different at 2,600,000 is about 48% of the possibilities.

Chances are that you will have spent more than what you get back as first prize no matter how much you increase the plays. In other words the luck element can't be elimiminated from being ahead in Lotto.

Regards

Colin

I realize that this don't have anything to do with the thread you guys had going here. I'm sorry for interupting. I'm just a bit eager to find out the answer :)]]>

Hi Colin,

I'm trying to figure this out: In a Norwegian Lottery they have 34 balls and they pick a total of 10 balls, 7+3 extras. The prices are for 5, 6 and 7 correct balls = 4+1, 4+2, 4+3, 5, 5+1, 5+2, 6, 6+1 and 7 correct balls.

What are the chance of the balls 1,2,3,4,5,6,7 are picked out? They can be randomly picked, but in the end those 7 numbers must be picked.

I think this can be calculated by finding the number of possibilities. But I've got some problems with finding this out.

I'm greatful for any help.

]]>

Hi Colin

is there a trial version of the calculator above?

I'm interested in trying it out.

Thanks for the inquiry Ron1.

It used to be my intention to release an analysis program that highlighted the deficiencies of most of the Lotto Wheels/Covers touted in this field of interest. I'm warming to the idea again.

As a matter of interest what would you use it for?

My experience has been irrespective of the logic and proofs people still choose to believe what they want to believe. Even from intelligent academic people that write articles on Lotto Designs I have yet to see any admission that in terms of the Covers they promote as being beneficial to Lotto players the yield or percentage return in the short term is woeful.

Generally speaking anyone who thinks they can tweak the odds in Lotto beyond 5 or 6 percentage points over a reasonable sample is in fairyland as far as I'm concerned.

Regards

Colin Fairbrother

]]>
Hi Colin

is there a trial version of the calculator above?

I'm interested in trying it out.

]]>

Thanks Millsy

I actually did the Windows version of LottoToWinŽ before the online version of LottoToWin. Security and updates are not an issue when you publish on the web but are once you make your program stand alone. I suppose I'm over reacting as I don't think the plagiarists would be interested that much.

What you see here is an internal program - a simplified version of my analyzer in Access. The idea is that when I analyze a number set I want to do it in a standardized way and then publish the screen shot.

The short answer is I don't think there is any real commercial demand for a program like this. As for the windows version of LottoToWin - well, I need a few more people like yourself to ask for it. There is no profit in these efforts so I'm cautious about distributing something with more maintenance requirements than the easier way of using the web, where a change can be effected in a few minutes for the benefit of all users.

Regards

Colin Fairbrother

]]>
Hi Colin,

I hope your well.

Your coverage calculator looks great.

Will it be available soon in addition to your other program

Best Regards

Millsy

]]>
I'm looking to standardize on how I present a Lotto playset analysis and this is my simplified adaption into VB of my Access internal application that I've had for a few years. Comments and suggestions are welcome.

Colin

The objective is to achieve a sub 1 sec time in a visual environment to calculate the coverage of say 44 45 46 47 48 49 by testing all the 13,983,816 possiblities and establishing a count of match Threes in a Pool 49, Pick 6 Lotto game.

If iteration is not used then there must be a way of keeping track of what is covered for further block processing and counting the Coverage. **The iteration algorithm I used to obtain these Coverage Calculation times is basically the same in all the four languages allowing for syntax differences and was supplied by Michael Harrington mentored by John Rawson in a thread I started called ***Coverage Calculation in VBA, VB, C# and C++* and can be viewed **here**. The initial times shown in the thread were based on older slower code than what I was currently using to attract more attention which it did; I had got it down to 70 sec in VBA and 7 sec in VB 2008 on a 1.8 GHz computer. Michael's times were impressively better at 6.5 sec and 0.44 sec respectively.

From the code supplied at the message board you may want to add a couple of improvements for the first two loops, as I do, to opt out when it is greater than the max integer in the block. Obviously, this will not have any effect on our test block of 44 45 46 47 48 49.

I should mention that Michael's code simply counts the extent to which a subset Three in the Play Set is in the 13,983,816 possibilities. When you are generating sets and in my case making sure a Three is not repeated the code is not as simple nor as fast.

Michael came up with a faster algorithm better than the 0.44 sec by breaking the 49c6 into 4 groups: -

- 4c1 x 6c6 = 1
- 43c1 x 6c5 = 258
- 43c2 x 6c4 = 13,545
- 43c3 x 6c4 =
__246,820__ - Total 260,624

This is OK for calculating 1 block - the problem still remains to keep track of what is covered for calculation on multiple blocks as the flow through the lexicographic order has been lost - so, it is still a work in progress. Maybe combinadics can be used?

The times below are adequate for my use using the iteration method.

What is your real processor speed? I downloaded this free program CPUSpeedPro and had to adjust my speed from what I thought was 2.4 GHz as shown by XP to 1.8 GHz as tested. You can access tested speeds of current and old CPU's from around the world.

**1.8 GHz** Est 3 GHz (x.6)

VBA 6.52 sec 3.91 sec

(Access or Excel)

VB 2008 0.44 sec 0.26 sec

C# 0.64 sec 0.38 sec

C++ 4.00 sec 2.40 sec

without Boolean Vector < 0.5 sec < .5 sec

Why does C++ give such a relatively high time? If I remove the 13983816 Vector Boolean which is taking up a lot of contiguous memory it gives the fastest time. But how then does one keep track of what is covered? If you would like to give a time for the code in C++ go ahead - just let us know how fast your processor is and how large the RAM and **how you are going to keep track of what is covered**.

C# is managed memory and does not have to be contiguous for its arrays .

VB rules! You can get a free copy of Visual Basic Express here:

http://www.microsoft.com/Express/VB/

http://www.microsoft.com/Express/VB/

I use Visual Studio Standard which includes VB, C# and C++ with intellisense in the IDE. Study what you need and what you get before forking out for the considerably more expensive Professional edition.

Colin Fairbrother

ps

On May 17th Michael Harrington published what is pretty well the final

version of the Coverage Calculation code after some mentoring by John

Rawson. The objective of an under 1 second calculation time was

achieved for not only 1 line but also 163.

version of the Coverage Calculation code after some mentoring by John

Rawson. The objective of an under 1 second calculation time was

achieved for not only 1 line but also 163.

Here are the times for the various languages as tested for a 1.8 GHz

processor (except C++ where a calculation is made from John Rawson's

accepted time of 0.2 sec on a 3 GHz processor and the assumption is

made that the code for this task is pretty similar) : -

1,8 GHz 3.0 GHz

Processor Processor

VBA 3.00 sec 1.65 sec

(Access or Excel)

C# 0.45 sec 0.25 sec

VB 2008 0.42 sec 0.25 sec

C++ 0.36 sec 0.20 sec

Congratulations to Michael Harrington. I for one will find some of the

tricks and techniques used to be useful in speeding up some internal

programs I use.

Colin Fairbrother

www.lottotowin.com