Vertical Sum Pairs - Draw Distances correct or not?

[pyst7lot]

I could be wrong but I think that Draw Distance 0 is actually Draw Distance 1.
Is anyone able to check?

[tdnl46w]

When analyzing the latest selected draw plus the previous draw, the pair sum hasn’t moved any distance. So it is “Draw distance: [0]".

[pyst7lot]

Here's why I ask.
When I use the VPS filter and enter the values for the sums of the last two draws in each position then hide the last draw in my winning numbers table.
When set at draw distance 0 and accept, the winning combination remains when it should not.
When set at draw distance 1 it gets eliminated when it should not.

[tdnl46w]

Is this a back-test or a run, can you post an example?

[pyst7lot]

Here are my last two draws.
25 40 18 01
01 02 34 29

VPS at Draw Distance 1 is the sum of numbers in each position?
26 42 52 30

I enter those values in the VPS filter at Draw Distance 1
I hide the last draw in my winning numbers table.

I run the filter and the 2nd draw numbers do not appear.

I change the Draw Distance to 0 and the 2nd draw numbers appear.

[tdnl46w]

If those are the latest two draws, then the VPS sums of 26,42,52,30 are from “Draw distance:[0]”.

[pyst7lot]

I'm still not convinced that I am wrong. It's frustrating because I want to use VPS but I want to be confident that I understand it correctly.

The last comment in the help file is what I'm not quite getting.
"Note: Draw distance value 0 means that the filtered tickets are compared with the very latest draw in the selection of past draws."

In my example I have as my last known draw
25 40 18 01

In VPS I entered the values which are the Sums with the next draw 01 02 34 29
26 42 52 30

So if I want the draw to appear should it be set as Distance 0 or Distance 1

[tdnl46w]

Example filter using the latest two draws of;
25 40 18 01
01 02 34 29

Draw distance: [0] sums are: 26 42 52 30.

Vertical Pairs Sum - Matching Tickets: [Accept]
Winning Numbers: 2 latest draws (<-this needs to match the draw distances used etc.)
- Draw distance: [0]
- ☑ Position 1 Sum range min:[26] max:[26]
- ☑ Position 2 Sum range min:[42] max:[42]
- ☑ Position 3 Sum range min:[52] max:[52]
- ☑ Position 4 Sum range min:[30] max:[30]
- At least [4] to [4] positions must pass.

Running the VPS filter setup above will accept any tickets in the package that contain those positional sums. So for either of the latest two draws to be accepted in the package, they must have those positional sums.

Edit to add:

... "Note: Draw distance value 0 means that the filtered tickets are compared with the very latest draw in the selection of past draws."

This means; Draw distance:[0] = latest draw 25 40 18 01, is compared to the package. Draw distance:[1] means draw 01 02 34 29 is compared to the package. So the higher the draw distance the farther back in previous draws.

[pyst7lot]

We're getting there.
I have it in my mind that Draw Distance 0 does nothing except use the value of the last draw by itself and that draw distance 1 adds the last draw to the previous one.
The help file is often not written for this dummy. lol
I think the analyser confuses me because it looks like draw distance 1 does add each of the draw numbers to the numbers in the previous draw.

So in the filter, draw distance 0 adds the same numbers that the analyser adds as draw distance 1.

[pyst7lot]

I still think there is something not right about the draw distances.

[tdnl46w]

Hi pyst7lot.

Here is some information I found while testing the VPS filter. Example below using the EL Demo lotto 6/49(Bonus number excluded).

Vertical Pairs Sum - Matching Tickets: [Accept]
Winning Numbers: All draws - Wed 1st, Wed 2nd, Sun 1st, Sun 2nd
- Draw distance: [5]
- ☑ Position 1 Sum range min:[25] max:[25]
- At least [1] to [1] positions must pass.

Run

2010/28 Sun 2nd......23,29,36,42,44,47 <Draw distance: [0]
2010/28 Sun 1st.......06,13,14,19,41,42 <Draw distance: [1]
2010/28 Wed 2nd.....02,13,16,17,25,40 <Draw distance: [2]
2010/28 Wed 1st......16,18,22,23,28,29 <Draw distance: [3]
2010/27 Sun 2nd......01,06,12,24,32,41 <Draw distance: [4]
2010/27 Sun 1st.......02,15,22,29,30,37 <Draw distance: [5] <<< 02 + package ticket position 1.

When you Run the filter, it will use the winning draw of 2010/27 Sun 1st for draw distance [5] to compare to the package. Position 1 in this ticket is 02. So the filter will accept any package tickets that have 23 at position 1(2+23=25).

Back-test

Now for the confusing part. If you "Back-test", then the "Draw distance:" will be calculated differently.

2010/28 Sun 2nd......23,29,36,42,44,47 <Draw distance: [0] <<< Running the filter will start the distance count at [0] here.
2010/28 Sun 1st.......06,13,14,19,41,42 <Draw distance: [1] <<< But the Back-test will start the distance count at [0] here.
2010/28 Wed 2nd.....02,13,16,17,25,40 <Draw distance: [2]
2010/28 Wed 1st......16,18,22,23,28,29 <Draw distance: [3]
2010/27 Sun 2nd......01,06,12,24,32,41 <Draw distance: [4]
2010/27 Sun 1st.......02,15,22,29,30,37 <Draw distance: [5]

So from a ticket properties standpoint, I agree that there is something missing here. To filter the same distances as seen in the properties, analyzer, and Run results, the Back-test would have to use "Draw distance:[4]" instead of [5]. I could be reading/testing something wrong but I'm not sure. Maybe Stan can explain more(?).

Note: There are also multiple errors/typo's in the documentation/help file for the Vertical Pairs Sum filter.
> The first filter example references draw 2010/28 Wed 2nd as having the number 6 at position 1 when it actually has number 2 at position 1.
> In the second filter example, it uses the sum ranges of 30 to 35 for Position 6, but in the explanation of the results it references using 40 to 45(?). Also, the winning draw of 2010/26 Wed 2nd is a duplicate of winning draw 2010/26 Sun 2nd. Winning draw 2010/26 Wed 2nd should have numbers 4,18,26,33,35,47.

[pyst7lot]

Hi tdnl,
You're doing my head in. lol
The more we discuss it the more confused I get.
Draw Distance 0 should never have been an option because that is the thing which has confused me.