UAs collection and vectors

 

Bands 1+2 UAs and vectors

 

The generation of UAs for bands 1+2 is described in a separate chapter.

 

The UA collection is stored is a table sized to accept up to  2000 UAs of size <= 20cells

The primary set is limited to 5 digits. The “more” primary set has 6 of 7 digits but only one or 2 mini rows are filled in one of the 2 bands. Other UAs are added to the primary table  when an XY is checked but still has several solutions.

 

For each new step (first 2 cells in X and first 2/3 cells in Y) A reduced table is built, discarding all UAs hit by the four cells.

 

These UAs are the basis for the main filter. The residual count is limited to 512. This limit is only for the step table. All UAs in the primary table are kept in the limit of 2000 UAs.

 

In the same function int G17INDEXSTEP::ShrinkUas() a first vector is built with as many bits to ‘1’  as UAs in the step table. Then the cells table is built.

 

For each cell, UAs not hit have a bit set to ’1’ (so the initial value is the vector just created);

Combining all relevant cells vectors by a logical and will give the final status of not it UAs for a given set of cells.

 

As the 2 first X cells and the first 2 Y cells hit no UA by construction, they can be ignored.

 

The X vectors and Y vectors are built once in each step. As the outer loop in the step is for X, the Y vector are built at the step level. The X vectors are built at the chunk level.

 

GUAs generation and vectors

 

The process for GUAs generation and GUAs vectors building has the same sequence as for UAs.

However, we have big differences  changing slightly the scope.

 

Each socket has more or less the same potential in GUAs as the main table. If the number of bands 3 is big enough (>15 for an average 9 “bands 3” per “bands 1+2” in the 566 656 search)  all sockets are in use, so we collect GUAs for 81 “sockets 2” and 81 “sockets 3”.

 

At the start, each socket has it’s own table of GUAs.  Unused sockets tables remain empty. Each table has a fix size (150 GUAs), enough to collect UAs of size 18/19.

 

For each active socket, the generation is the same as for the main UAs in the limit of 5 digits.

For the main UAs, we have a compulsory step, the validation of an XY passing the filter. This was the source of additional UAs.

 

Here, we don’t have such a step. The table created at the start will remain un changed during the process.

 

This pushed to generate more GUAs of small size at the start. A more step has been added for UAs with 6/7 digits. The more GUAs searched have only 2 cells in a mini row in one of the band 1,2 (including the 2 cells of the socket, this will give at the end a UA with 4 cells in 2 bands for the entire grid). Only part of the sockets give starts for such a search. Having the four cells locked the generation takes place in the third band with a “revised gangster” something very close to what has been done for the “more UAs” bands 1+2

 

After the validation of an XY, we have to collect  sockets failing to hit all the relevant table. With a variable number of active sockets and a variable number of GUAs per socket; the “best process” is not so easy to define, but this is not anymore a critical code. Only some 1/1000 of the XY reach this point.

 

With a maximum of 150 GUAs per socket at the start,  we should not pass 60 GUAs per socket in a step. The average count will be smaller.

 

To keep the power of the 128 bits instructions, All the sockets tables are shrink in a unique table at the step level (same 2 first cells in X, same  2/3  first cells in Y). An index gives for each active socket the start and the end point in the main table.

 

Defining the optimal conditions requires many tests. So far

 

The size of the common table is fix and set to 10x128 GUAs in the step

For a given socket, a maximum of 30 GUAs are kept at the step level.

 

This seems weak when nearly all sockets are active (81+81 giving an average 8 GUAs per socket), but the risk is to loose sockets 3, of smaller interest.

More tests could show if  20x128 GUAs (or more) works better

 

Collecting active GUAs for a valid XY

 

See void G17XY::Go_Guas_collect()

 

Again, we start form the downstream process to understand the preparation work.

 

The first action, very similar to the critical loop is to build the XY GUAs vector. Each X vector and Y vector has been prepared; so again, this is just a “and” of both.

 

xyvg = xvg; xyvg &= yvg;

 

Building the common GUAs table, we have stored for each active socket the start and the end point.

We have 0 (lost GUAs)  one or 2 blocks of 128 bits to check for a given socket.

 

This test requires a vector of active UAs per socket. This vector if built when cells vectors are created.

 

Having active sockets, the bands 3 are scanned to apply the relevant sockets to the bands 3.

 

This is done twice

 

Before the  validity check of an XY in the critical or subcritical stacks

After the validity check for all sockets to have the list of bands 3 to study.

 

In the first case, the target is to see if all bands 3  have a stack with more than 6 given, In the first case, the target is to collect the status of bands 3 to pass to the next phase.

 

Building the common GUAs table and  GUAs vector.

 

For each cell,X,Y we had a fix vector structure of size 4x128 bits. We have now for each cell, socket,X,Y a fix vector structure of 128x ‘10’ (currently 10, could be more)

 

Each of the valid socket 2 socket 3 GUAs table is first scanned to extract still valid GUAs in the limit of ‘30’ GUAs per socket. If the socket has remaining GUAs, the index is loaded with the corresponding pointers.

 

Then (similar to what was done for UAs), a base vector is built, then one vector per cell,

A vector per socket is added using the index.

 

Later, in a similar way to what was done for UAs, a X GUAs vectors and Y GUAs vectors are built.