I have problems to find the correct win garantee for a small number of blocks.

Please see the following case:

v = 11

k= 6

t = 4

m = 6

b = 2

Covering:

01 04 05 06 08 11

02 03 06 07 09 10

As you can see the number 6 is a key number because it is twice in the covering.

What is the win garantee? Is it a key number case?

The default Hit statistic without key number shows for a 4 if 6: 78,35 %

And the Hit statistic with a key number shows for a 4 if 6: 100 %

What win garantee is correct?

For a v = 8 covering with 2 blocks we have 3 key numbers. What is the win garantee? Is it a 2 key numbers case?

Or shows the hits statistic the correct win percentages?

01 03 04 05 07 08

02 03 04 05 06 07

## Win garantee question

- lottoarchitect
- Site Admin
**Posts:**1539**Joined:**Tue Jan 15, 2008 5:03 pm**Location:**Greece-
**Contact:**

### Re: Win garantee question

When a number is considered a key number (means this number appears in all the blocks), the coverage evaluation is different. In this case you have two different "match" parts a)the actual key numbers b) the variable wheel part.

To understand it better, in your same wheel

01 04 05 06 08 11

02 03 06 07 09 10

we strip out the number 06 as it is the key anyway and we are left with

01 04 05 08 11

02 03 07 09 10

and your coverage evaluation is [match key] + 3if5.

Now you may ask why we gone from 4if6 to 3if5. First the [match key] part refers to the matching or not of the key numbers (you can have more than one key number). The other part left is what the coverage should be evaluated on. Keep in mind, if your initial wheel is v,k,t,m=b and in there you have c key numbers, the variable part to evaluate the coverage is actually a [v-c], [k-c], [t-c], [m-c] = b wheel which is the correct answer for evaluating coverage on key wheels.

Of course, we can evaluate a key wheel as a normal wheel regardless if a key number is in there or not. In that case, the coverage takes no assumption or advantage of the key property, so in that case your coverage is evaluated as the original case of v,k,t,m=b wheel.

Now, the interesting fact about key wheels is the actual match is a mix of the performance from the two parts [key & remaining wheel]. So, in the example above, you may match the key number 06 or not, so you have 0 or 1 hit from the key part. the 3if5 part is what it is: if you match 5 correct in those v-1 remaining, you will get a 3 match hit assuming this is an 100% 3if5 wheel. So, the overall key wheel judged as a real key wheel can produce a [0 or 1] + [3if5 match performance].

Finally, these trivial sized wheels are not really key number wheels. The fact that in two rows we may have same numbers appear is just the case of unavoidable overlap occurring in these trivial situations. In reality these wheels should be judged as normal wheels (no keys). Unless if you specifically design a key wheel or you know it was meant to be treated as a key wheel, the evaluation always assume a normal non-key wheel. But if you want to evaluate an actual key wheel, you have to separate the two parts and evaluate them separately as demonstrated above.

So

4if6 100% assumes the key was a match so in reality we talk about [1 match from key] + 100% 3if5 wheel here. But we fail to acknowledge the case we can miss the key number so the hit would be [0 match from key] + 100% 3if5 = a maximum of a 3 hit only. So this 4if6 100% evaluation is incorrect because you evaluate a key wheel as a general wheel when you should have separated the two parts making up the key wheel and evaluate them independently.

The correct key wheel guarantee is [0 or 1] + [3if5 match performance].

Unfortunately WG at its current version can only evaluate the general case and cannot take into account the key property to generate the real key wheel coverage.

To understand it better, in your same wheel

01 04 05 06 08 11

02 03 06 07 09 10

we strip out the number 06 as it is the key anyway and we are left with

01 04 05 08 11

02 03 07 09 10

and your coverage evaluation is [match key] + 3if5.

Now you may ask why we gone from 4if6 to 3if5. First the [match key] part refers to the matching or not of the key numbers (you can have more than one key number). The other part left is what the coverage should be evaluated on. Keep in mind, if your initial wheel is v,k,t,m=b and in there you have c key numbers, the variable part to evaluate the coverage is actually a [v-c], [k-c], [t-c], [m-c] = b wheel which is the correct answer for evaluating coverage on key wheels.

Of course, we can evaluate a key wheel as a normal wheel regardless if a key number is in there or not. In that case, the coverage takes no assumption or advantage of the key property, so in that case your coverage is evaluated as the original case of v,k,t,m=b wheel.

Now, the interesting fact about key wheels is the actual match is a mix of the performance from the two parts [key & remaining wheel]. So, in the example above, you may match the key number 06 or not, so you have 0 or 1 hit from the key part. the 3if5 part is what it is: if you match 5 correct in those v-1 remaining, you will get a 3 match hit assuming this is an 100% 3if5 wheel. So, the overall key wheel judged as a real key wheel can produce a [0 or 1] + [3if5 match performance].

Finally, these trivial sized wheels are not really key number wheels. The fact that in two rows we may have same numbers appear is just the case of unavoidable overlap occurring in these trivial situations. In reality these wheels should be judged as normal wheels (no keys). Unless if you specifically design a key wheel or you know it was meant to be treated as a key wheel, the evaluation always assume a normal non-key wheel. But if you want to evaluate an actual key wheel, you have to separate the two parts and evaluate them separately as demonstrated above.

So

4if6 78,35% is the general case evaluation which doesn't take into account special properties of the wheel (like key numbers).The default Hit statistic without key number shows for a 4 if 6: 78,35 %

And the Hit statistic with a key number shows for a 4 if 6: 100 %

What win guarantee is correct?

4if6 100% assumes the key was a match so in reality we talk about [1 match from key] + 100% 3if5 wheel here. But we fail to acknowledge the case we can miss the key number so the hit would be [0 match from key] + 100% 3if5 = a maximum of a 3 hit only. So this 4if6 100% evaluation is incorrect because you evaluate a key wheel as a general wheel when you should have separated the two parts making up the key wheel and evaluate them independently.

The correct key wheel guarantee is [0 or 1] + [3if5 match performance].

Unfortunately WG at its current version can only evaluate the general case and cannot take into account the key property to generate the real key wheel coverage.

### Re: Win garantee question

Thank you for your answer. I understand the win garantees for a small number of blocks now

Wheel Generator works perfectly.

Wheel Generator works perfectly.

### Who is online

Users browsing this forum: No registered users and 3 guests