The New Sudoku Players' Forum

[omerosler]

Hello,
I've discovered a new solving technique based on some special subsets of candidates which are a generalization of ALSes.
Those sets are called ---terminology might change--- ALSS (Almost locked subsets) and can be used exactly like ALSes in ALS-XZ/Chain rule
A more thorough description and discussion is found in: http://forum.enjoysudoku.com/new-technique-almost-locked-sub-sets-t33134.html
I want to fork HoDoKu to use this technique as well and the change seems minimal;
Just add to the list of ALSes all the ALSSes (and marking them to distinguish the techniques later in the config system) you can find
However, I have a slight problem:
ALSSes which are not ALS arise from different places, and the problem I have affects almost all of them:
Example is one that avoids DP, an example is given in the thread which I'll repeat:

Code: Select all

 +---------------------------------------------------------------------------+
 |  -        -         -      |  -     -     -     |  -        -        -    |
 |  -        -         -      |  -     -     -     |  -        -        -    |
 |  -        -         -      |  -     -     -     |  -        -        -    |
 |----------------------------+--------------------+-------------------------|
 |  4-       ab12347   4-     |  -     -     -     |  -        ab1247   a47  |
 |  c3456    c3456     -      |  -     c56   -     |  -        -        -    |
 |  -        b12       -      |  -     -     -     |  -        b12      -    |
 |----------------------------+--------------------+-------------------------|
 |  -        -         -      |  -     -     -     |  -        -        -    |
 |  -        -         -      |  -     -     -     |  -        -        -    |
 |  -        -         -      |  -     -     -     |  -        -        -    |
 +---------------------------------------------------------------------------+


The {347} of the 'a' cells form an ALSS to avoid a DP => Something that sould be detected in the UniquenessSolver.java file
The ALS(S)-XZ pattern (which yields eliminations) described is implemented in the AlsSolver.java file (or in a new file with almost the same code) so in order to register the ALSS into this solver UniquenessSolver.java must import the ALS solver; but that's only the case when the ALSS method is enabled or needed which is a result of configuration;
How do I make such conditional dependency (something like #if in C/C++ is a way) [where StackOverflow says every way to simulate #if in Java requires some external tools which I don't see integrated to HoDoKu just for this one technique]?
Is there a workaround that would work specificly in HoDoKu?
Thanks in advance,
Omer Rosler

[JasonLion]

In Java you would typically have the import always there, needed or not, and then make a class static final variable that you initialize to either true or false and make everything conditional (using regular if statements) on using or not using the solving technique based on the value in the variable. The complier will then be smart enough to either include or ignore the code as needed. However, I don't know anything about how the HoDoku code is setup, so it is possible they have some other approach already in place.

By the by, it is best to keep your solving technique and your programming questions as separate as possible. It is not really appropriate to duplicate all of that text about your solving technique here when it is so totally off topic for your programming question. The duplicate text leads to confusion and tends to distract from your actual question. If you were talking about aspects of the implementation of the solving technique details things might be different, but your programming question as asked is totally unrelated.

[omerosler]

In Java you would typically have the import always there, needed or not, and then make a class static final variable that you initialize to either true or false and make everything conditional (using regular if statements) on using or not using the solving technique based on the value in the variable. The complier will then be smart enough to either include or ignore the code as needed. However, I don't know anything about how the HoDoku code is setup, so it is possible they have some other approach already in place.

Well, I forgot that import is lightweight, it was a stupid question (too used to the 40+ years old C++ #include copy and paste system...)
And didn't know the compiler can optimise those away, so that's the answer, thank you!

By the by, it is best to keep your solving technique and your programming questions as separate as possible. It is not really appropriate to duplicate all of that text about your solving technique here when it is so totally off topic for your programming question. The duplicate text leads to confusion and tends to distract from your actual question. If you were talking about aspects of the implementation of the solving technique details things might be different, but your programming question as asked is totally unrelated.

Okay, won't happen again.