New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Any latest news will be posted here...
Post Reply
User avatar
lottoarchitect
Site Admin
Posts: 1635
Joined: Tue Jan 15, 2008 5:03 pm
Location: Greece
Contact:

New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by lottoarchitect » Sat Feb 08, 2020 10:01 pm

New versions of these programs were made available today.

The changes mostly include known bug-fixes. Most notably, we hopefully have addressed this error message "Ordinal X not found" which shows up on some installations. Please let us know if you had that error and if it is gone after this update.

For GAT Engine 3.0.2, we have addressed a known bug which could not save in a state the retained GAT IDs if added via the panorama menu. This also results in an incompatibility vs GAT 3.0 state files which can't be loaded in the new GAT.

Wheel Generator 1.8.5.1 has some more extensive changes. Addressed a bug which connected the priority sliders to the bias operation. This fix resulted in some more changes: we have re-introduced the bias multiplier mechanism. At the optimization panel we now have a list of various settings ranging from x0.0001 up to x10000. The default setting x1 is the same as WG 1.8.5. The other settings are useful in various more "extreme" constructions. Bigger than x1 is mostly useful in coverings having too many blocks (in the range of thousands), and coverings having t<<m e.g. 3if6 constructions. Smaller values like x0.01 etc are mostly useful in coverings which include normal guide filters. As usual the whole point in optimization is to let the coverage fluctuate a bit. Use the bias multiplier to have the slider in a more "correct" range to operate on. Always start with x1 and adjust as needed if required.
Along the lines of setting a correct bias, we also introduce a new indicator at the progress panel. At the end of the improvements line we now have an extra value which indicates how many different blocks have been altered by the engine over the last [ b ] (total blocks of the covering) changes. Values in the range of 1-3 usually indicate a "stuck" condition by the engine, i.e. the engine only changes up to just 3 different blocks which is usually a cycle between these blocks therefore a stuck condition. We usually aim to have a value greater than 5.
Please also check the help file for more info on these new features.

cheers
lottoarchitect

Bruxo
Newbie
Newbie
Posts: 1
Joined: Wed Jul 08, 2020 3:24 pm

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by Bruxo » Wed Jul 08, 2020 3:29 pm

Is out there any video showing how to use WG ?

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

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by lottoarchitect » Sun Jul 12, 2020 10:03 am

Hi Bruxo, in its simplest form WG is very simple to operate. Set the v,k,t,m and an initial b parameter and click optimize. The idea in covering is to reach coverage to 100% (or less if we aim for open-cover constructions). The only crucial part of user's intervention is to adjust the engine bias (at the optimisation panel). The optimization logic is you should let the engine fluctuate the coverage a bit which allows room for the engine to introduce even "bad moves" which later on usually result in an even better coverage. Experimenting with bias will give a rough idea on what bias to set.
Finally, if no matter what we do we cannot bring an improvement the typical adjustment is to add more blocks to the covering and continue optimization and repeat that process till we reach the desired coverage.
A more thorough explanation of the v,k,t,m parameters alongside how to adjust the bias (the optimization panel) is available at the help file.

Now, WG has a lot of features and can cater for different constructions possible but the main idea of the optimization is the above. The more you use WG, the more you'll understand the logic behind it and make even better constructions. I could make a video saying "set v,k,t,m and b here, then click optimize". Doesn't sound like a useful video really. I can understand the visual aspect of seeing this and possibly I may produce one at some time.

V Dogg
Casual
Casual
Posts: 13
Joined: Wed Aug 26, 2020 2:34 am

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by V Dogg » Sun Nov 01, 2020 1:08 am

Question about Wheel Generator - after you hit optimize, how long does it normally take for the program to finish and for the wheel to come up? Got a 4 if 5 wheel with 15 numbers.

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

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by lottoarchitect » Mon Nov 02, 2020 12:22 am

Hi V Dogg, wheel building is an open search problem, belongs to the NP-hard class of mathematical problems to be precise. That means, it is not possible to establish a stop-condition for the "best found" as there is always a chance a better solution to be found during the scan. This has been discussed in more depth at the forums but the point is, we stop the engine if we find the achieved result satisfactory. If not, we continue scanning, also adjusting bias/scan methods over the time in order to find an even better outcome. The currently best wheel found is accessible as soon as we press the "optimize" button and this is the wheel which will be saved by the menu covering->save or covering->copy to clipboard or to view it from menu display->best wheel. Do not expect a message to pop up and say "job done", there cannot be one due to the nature of the optimization process and therefore it will never "finish" the scan.

V Dogg
Casual
Casual
Posts: 13
Joined: Wed Aug 26, 2020 2:34 am

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by V Dogg » Mon Nov 02, 2020 12:46 am

Appreciate the reply! Just one other question - how long should I allow WG to run to achieve an optimal result?

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

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by lottoarchitect » Mon Nov 02, 2020 12:00 pm

It is not about time, it is mostly about getting improvements. If after a few minutes we don't get improvements, the typical action is to adjust the bias slider to the left (and also downgrade with the bias multiplier when needed to make the search a bit tighter at each adjustment). So, if e.g. you optimize with bias 0 and x1 multiplier and see no improvement after a while, lower the bias to e.g. -200 (exact values don't matter much) and give it a go with this new setting. If no improvement occurs after a while, we go down to e.g. -400 bias. If we go below -600 or lower we can switch the multiplier to the next lower division (i.e. x0.1 and bias to a value like +1000). Inspect the bias graph to see the effect of bias/multiplier adjustment. Making the bias scan tighter lowers the bias value in the graph.

Also larger wheels (like b>1000) will benefit more from having a higher multiplier like x10 or even x100 as a starting point. The bias adjustment process is the same (lowering bias and multiplier as needed). For smaller wheels (b < 100) the typical multiplier can be x1 or x10 and adjust only the bias slider. The whole point in optimization is to have the main coverage (shown in progress panel) fluctuate a bit and this to give the impression it reaches during the ups and downs to the best coverage achieved (shown in the parenthesis in the same line). If it constantly fluctuates at higher values, this usually means the bias/multiplier is too high and we should lower the overall bias. Bias adjustment is done in gradual steps, so avoid sudden big changes like going from bias 0 to e.g. -700 in one step. Once you get the "feeling" of how much impact a change has, the adjustment will be second nature.

The simple scan process is considered complete if we really get to the point of having a quite tight search like no coverage fluctuation occurs at the main coverage line and after a while we still don't get an improvement. In such situations, we may decide to stop the optimization and use the outcome. However even this situation may not be the best, we can decide to loosen the bias (move slider to the right/increase multiplier) so to increase bias to allow room for fluctuation and this may also bring a better outcome after a while. Always keep in mind, very tight searches (no coverage fluctuation) are usually worse in terms of optimization to having some fluctuation.

So, for the time question, there isn't an answer really, it depends on how much the user wants to keep scanning to find a better outcome if possible. Small coverings like b < 50 may be of very good quality in less than an hour (but there is always a chance to find a better outcome if scanning for more time), bigger coverings and attempts to make world record coverings may take days. Its all a matter of how much we insist on a particular covering. The judge is the user, if the result is quite satisfactory we can stop the engine. In my world record attempts where things are very tight and finding a solution to just one missing combination, I may have the program run all night to find that one solution. For most everyday uses of normal sizes wheels, a typical one hour run including all the bias adjustments is usually more than enough but this is a rather vague guideline.

V Dogg
Casual
Casual
Posts: 13
Joined: Wed Aug 26, 2020 2:34 am

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by V Dogg » Tue Nov 03, 2020 2:28 am

Gotcha! One last thing - if after letting it run for an hour or so the numbers in the best covering menu don't change at all, do I need to fine tune the bias settings a bit until I get something I like? I haven't been doing this, just letting it run after setting the v, k, t, m settings.

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

Re: New Wheel Generator 1.8.5.1 and GAT Engine 3.0.2 versions

Post by lottoarchitect » Tue Nov 03, 2020 12:37 pm

WG's current algorithm is semi-automatic. The core optimization principle is to have a "correct" bias for the current state of the covering which allows bad moves by making the covering worse temporarily which later will generate a better outcome. There can't be an exact definition on what would be the correct bias for every situation, which can even drastically change during the optimization of the same covering - this largely depends on how the blocks intersect among them. The semi-automatic mechanism in WG tries to reduce the required bias adjustments by the user but still the user has to make these adjustments during the optimization. What we observe to judge if we have a "correct" bias is the fluctuation of the main coverage. As mentioned in the previous reply, what we look for is to see the coverage fluctuate and sporadically approach/reach the current best coverage found. That means the introduced bad moves of the engine have a balance vs the target of being close to an improvement. If the current coverage is constantly higher than the current best found, we certainly have a higher bias than needed and very unlikely this would bring up an improvement. So, what we do when we reach that state is to lower the bias. The bias adjustment process is done when the bias setting we currently have does not produce any fluctuation at all and no further improvements occur. My advice is to always start and keep using the standard algorithm and reserve the other (extensive/cyclic) for some final attempt to find something more. The reason is those algorithms (extensive/cyclic) cause a very tight search which is good for a small local improvement but make the overall coverage a very tight structure which is very hard to "break" by the fluctuation alone, so we use these at the end as a last attempt to get something more out of the covering we attempt.
So, start with a good fluctuation which produces improvements over time. When no improvements occur and we see the fluctuation (current coverage) stay constantly higher than the best coverage found, reduce bias/multiplier. No need to open the "Display->best wheel" window. Whenever a new best wheel is found, the best coverage indicated also reduces. All the info you need to judge the bias operation is already shown in the progress panel, specifically the improvements line and the main coverage line. The waiting time to see if a bias adjustment is needed is more like 5 minutes of no improvement with the current bias settings.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 16 guests