denis_berthier wrote:As stated in the BUM, rules for dealing with puzzles beyond g-T&E (mainly rules with inner Subsets or inner whips/braids) are not available in this first public release of CSP-Rules.
Ok, I can understand that. Have you defined notations for them? Can you produce any examples?
And I already answered about them:
- whips and forcing-whips are built on the same partial-whips
- it'd be inconsistent to allow forcing whips without whips of same length
I'm not sure I understand why. I can't see any logical necessity for forcing whips active if forcing whips are active (pun intended)
(and it's a topic also for conjugated tracks, but Robert doesn't even mention it).
I don't know how Robert deals with single tracks that lead to a contradiction within conjugated tracks, but he has to face the same question.
I'm pretty sure Robert has answered that question, and it's probably written in his documentation. I've also answered it before because it's exactly the same with GEM. If one of the two parities (or conjugated tracks, or forcing whip branches) leads to a contradiction, there's no need to look for further verity-agreements between the two branches. In that case one parity is false and the other true, which obviously yields more results than what the two could achieve together. Both Robert and I would most likely use the found contradiction, which would immediately destroy the underlying GEM-coloring, conjugated tracks, or forcing whip. I don't think there should be anything unclear about that.
However, it might take a long time to develop a branch so far that it would produce a contradiction, or one might not be found at all, especially if it would require deeper OR-branching. That's why it's not the main goal of the two-prong approach at all. It's about finding agreements between the branches, and some purists might not even accept anything else if their aversion to direct contradictions is severe enough. Simulating such a purist approach with SudoRules is impossible if whips are automatically active with forcing whips.
All of that should apply to forcing whips/braids. At shorter lengths they would find mainly verity eliminations through agreements, but eventually one or the other branch would run into a contradiction (unless OR-branching is needed, in which case it just gets blocked). Accepting the contradiction would yield a normal whip/braid for one of the branches, eliminating the original assumption of that branch and validating the other branch. Yet, accepting it should be the user's choice and not yours.
The proper way to use forcing whips/braids would be to build both branches simultaneously and gradually, picking any found trap eliminations on the way, and keep building it instead of jumping to search simpler patterns after each increment of length. That's exactly what Robert has been telling you as well. I doubt your implementation is doing it like that because it wouldn't match your idea of the simplest-first strategy. However, it really is the simplest and the most efficient way to solve for a manual solver, at least in most cases.
One more possibility I've added recently is focusing the search for activated patterns (whips...) on pre-selected candidates. Use function "try-to-eliminate-candidates" instead of "solve".
As I've said before, that's a very good addition. I'll try it at some point. Can you give an example of the full command with the necessary parameters?
I have no interest in searching for rare puzzles that might or might not unlock rules that are normally blocked by layers of forced simpler rules.
(I don't hugely appreciate when a piece of software thinks it knows better what I want.)
