Did I get it right?

Talk about anything Wheel Generator related which doesn't fit in the other forums
Post Reply
Athos
Regular
Regular
Posts: 43
Joined: Tue Dec 15, 2015 5:26 am
Location: Greece

Did I get it right?

Post by Athos » Sat Nov 13, 2021 10:50 am

So, I'm currently using WG in DEMO mode and I just want to see if I understand it correctly

I want to produce a 12 number wheel for Greek Joker (5/45)

Lets say I require a 100% 4 hit, if I get 5 correct numbers from 12

From what I understood from the manual, I used:

v=12
k=5
t=4
m=5
L base=1
L% = 100
auto reduce = yes

Is this correct?

User avatar
lottoarchitect
Site Admin
Posts: 1635
Joined: Tue Jan 15, 2008 5:03 pm
Location: Greece
Contact:

Re: Did I get it right?

Post by lottoarchitect » Tue Nov 16, 2021 12:57 pm

Yes, this is the basic and simplest idea in setting up the program to construct a covering and your interpretation of the parameters is correct. Auto-reduce will eliminate blocks if they deemed redundant (if the removal maintains the coverage equal or above the 100% you have set at the L% parameter). However, the most important aspect of an optimization is what you do during the scan:

The single most important adjustment is the bias slider. During optimization you want the indicated coverage to fluctuate up and down, the coverage "jumps" should be proportional to the value indicated at 1-block cover line at the bottom of the progress panel. For example, assume 1-block cover indicates a value of 1000 (the first value of that 1-block cover line). A proportional fluctuation would be like going up and down in steps of 10-50 or more but if it jumps quite less than that i.e. like just by one point, this might be a too tight search. We want to avoid tight searches as this rarely results in a better covering later on. So, during the first steps of optimization we want to let the coverage fluctuate and the indicated coverage should give the impression it reaches the best coverage found so far very so often; if it constantly fluctuates away from the best coverage found, then we have a quite big fluctuation and we should reduce it by moving the bias slider to the left. When no more improvements occur, we gradually reduce the bias (bias expansion slider at the optimization panel) and when we reach a minimal fluctuation with no further improvements, we consider the optimization completed. Use this alongside the Bias Multiplier parameter to allow for a proper fluctuation. When 1-block cover indicates a large value, typically x10 x100 or even more might be needed as bias multiplier. Values x1 x0.1 x0.01 etc are usually needed for very small 1-block cover indicated and are mostly useful when normal filters are used. Again, the whole point of these parameters (bias slider, bias multiplier) is to have a good fluctuation of the coverage, what is needed for the given state of the covering.

To summarise: observe the fluctuation and adjust as needed to maintain it to a sensible value. If it approaches the current best coverage every so often we are good. If it constantly fluctuates at higher values and never reaches the best coverage we have to reduce the fluctuation using the bias slider/multiplier. Optimization is over when we virtually have no fluctuation.

Q: why this bias adjustment is not fully automated?
A: The engine is semi-automatic in regards to bias adjustment which means it reduces the requirements for manual adjustment by the user. However coverings are unique to what they require in terms of bias fluctuation which will result in an improvement later on which ultimately means there is not a single "best value". Experience with how the engine behaves and what is generated will become second nature on what to set to these sliders. I constantly work on trying to make a fully automated approach but it turns out a very hard task to do so far. It works nicely for some coverings but not so good on others.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests