The New Sudoku Players' Forum

[P.O.]

let's not make a drama out of a simple question of vocabulary; i am quite ready to accept your definitions and your classifications, all the debates on the questions of terminologies are perfectly indifferent to me, the only thing which interests me in the techniques used to solve the puzzles is their logic and their power of resolution not their name or position in any ranking.

[eleven]

As you could see, having no common name for these special chains, you are using, leads to confusion.

[denis_berthier]

already many years ago these chains were called "memory chains" (Denis and P.O. use them), because you have to remember all direct consequences of former steps.

The name "memory chains" was introduced years ago, many years after I defined (in my book [HLS 2007]) whips, braids and other kinds of chains with z- and t- candidates.
"Memory chains" is often used to hide the source of inspiration and/or the absence of any clear definition of what is being talked about.
P.O. has very recently written a BFS program that outputs some (never defined) chains and forcing chains (with an inconsistent notion of length, counting a Pair/Triplet/Quad as a Single and counting a forcing chain as if it had independent branches). All this seems to be no more than his own implementation of braids, S-braids and forcing-S-braids (but with the wrong notion of length and with no distinction between different types of chains).

In my chains, you don't have to remember "all direct consequences of former steps". You only have to remember the sequence of right-linking candidates. That's why it is logically consistent to consider that z- and t-candidates are not part of the chains. In short, you don't have to remember more than in any AIC.
Many manual solvers use such techniques. They are not harder than ALS-chains. Indeed, they are much easier than AAALS, AHH.... chains.

As to the name chain vs net, AnotherLife's only purpose is to find arguments against such chains - so I wouldn't care too much about his opinion, which words he uses or which deliberately complicated drawings he makes.

For me, as the result of really thinking about the question, the difference between a chain and a net is whether there is OR-branching or not. I've never seen any other proposal for making the distinction (other than using "net" as a disguised insult).
There is no OR-branching in any of my chains (except forcing-chains - that start with an OR.

OR-branching is equivalent to following several streams of reasoning in parallel and comparing them permanently.
P.O.'s argument for forcing chains ("the branches are independent") is obviouysly invalid.

[marek stefanik]

To throw my two cents in here...
(I'll ignore the highly speculative paragraph about P.O.'s inspiration for his chains/nets).

In my chains, you don't have to remember "all direct consequences of former steps". You only have to remember the sequence of right-linking candidates. That's why it is logically consistent to consider that z- and t-candidates are not part of the chains. In short, you don't have to remember more than in any AIC.

And you have to remember the target, conveniently placed at the very end of the notation.
By this logic it would be consistent to ignore the llcs as well. But limiting the chain/net to rlc's would make them "all direct consequences of former steps", which no one wants...
All you need to remember when using AICs is the head and tail of the chain. You might want to remember more (for notation or NLs), but you don't have to.

For me, as the result of really thinking about the question

I like this term for opinion. This part of your work might get copied.

OR-branching is equivalent to following several streams of reasoning in parallel and comparing them permanently.
P.O.'s argument for forcing chains ("the branches are independent") is obviouysly invalid.

If someone else looks at the notation, they can check each branch independently. I believe that is what P.O. meant.

Marek

[denis_berthier]

In my chains, you don't have to remember "all direct consequences of former steps". You only have to remember the sequence of right-linking candidates. That's why it is logically consistent to consider that z- and t-candidates are not part of the chains. In short, you don't have to remember more than in any AIC.

And you have to remember the target.

In chains with z-candidates, you have to remember the target, yes. Same as in oddagons, which doesn't seem to be a problem for anybody.

By this logic it would be consistent to ignore the llcs as well.

A chain is a continuous sequence of candidates. Ignore the llcs and continuity disappears. What's your logic here?

All you need to remember when using AICs is the head and tail of the chain. You might want to remember more (for notation or NLs), but you don't have to.

If you want to produce a pattern-based solution (not only solve the puzzle), you obviously have to.

For me, as the result of really thinking about the question

I like this term for opinion. This part of your work might get copied.

No discussion is possible with people who don't know the difference between thinking and opinion.
I can only see that you have no concrete idea to propose about chains vs nets.

OR-branching is equivalent to following several streams of reasoning in parallel and comparing them permanently.
P.O.'s argument for forcing chains ("the branches are independent") is obviouysly invalid.

If someone else looks at the notation, they can check each branch independently. I believe that is what P.O. meant.

The complexity of a pattern can't be usefully defined as the complexity of reading it. It has to be the complexity of finding it. Only this view can reflect the difficulty of a puzzle for a player.

[marek stefanik]

In chains with z-candidates, you have to remember the target, yes. Same as in oddagons, which doesn't seem to be a problem for anybody.

Based on the solutions I've seen on the forum, most people think about oddagons without targets.
We identify the oddagon and its guardians and either directly eliminate candidates seen by all of them directly or build a kraken from them.

A chain is a continuous sequence of candidates. Ignore the llcs and continuity disappears. What's your logic here?

Poor phrasing on my part.
What I meant to say was that when finding the chain/net or following its logic, llcs have the same role as z- or t- candidates (unlike z- candidates it is the candidate of the given varible that is seen by the most recent rlc).
Your definition of chains requires the llcs for continuity (braids?), but if that is their only purpose, eleven's claim about "all direct consequences of former steps" holds, since llcs, z- and t-candidates are part of the step involving their CSP-variable, where the direct consequence is the rlc (here 'consequence of' is ambiguous).

All you need to remember when using AICs is the head and tail of the chain. You might want to remember more (for notation or NLs), but you don't have to.

If you want to produce a pattern-based solution (not only solve the puzzle), you obviously have to.

I said it was needed for notation, otherwise you just forget it afterwards anyway...

I can only see that you have no concrete idea to propose about chains vs nets.

Au contraire, there are several options one could pick and I refuse to argue about definitions.
On top of your requirement of no or-branching one might require reversibility (without or-branching) allowing z-chains but not whips.
Or even prohibit a link to depend on a 'target', not allowing z-chains either.

OR-branching is equivalent to following several streams of reasoning in parallel and comparing them permanently.
P.O.'s argument for forcing chains ("the branches are independent") is obviouysly invalid.

If someone else looks at the notation, they can check each branch independently. I believe that is what P.O. meant.

The complexity of a pattern [...]

I explained the independence of the branches, not whether they are easier or harder to manage than memory chains. I refuse to discuss such a subjective matter.

Marek

[denis_berthier]

In chains with z-candidates, you have to remember the target, yes. Same as in oddagons, which doesn't seem to be a problem for anybody.

Based on the solutions I've seen on the forum, most people think about oddagons without targets.
We identify the oddagon and its guardians and either directly eliminate candidates seen by all of them directly or build a kraken from them.

How is remembering the guardians easier than remembering a single target?

A chain is a continuous sequence of candidates. Ignore the llcs and continuity disappears. What's your logic here?

Poor phrasing on my part.
What I meant to say was that when finding the chain/net or following its logic, llcs have the same role as z- or t- candidates (unlike z- candidates it is the candidate of the given variable that is seen by the most recent rlc).

NO. llcs don't have the same role as z- and t- candidates in my chains. We've already had this discussion and you bring nothing new to it.

All you need to remember when using AICs is the head and tail of the chain. You might want to remember more (for notation or NLs), but you don't have to.

If you want to produce a pattern-based solution (not only solve the puzzle), you obviously have to.

I said it was needed for notation, otherwise you just forget it afterwards anyway...

My purpose in solving is not notation but full resolution path.

I can only see that you have no concrete idea to propose about chains vs nets.

Au contraire, there are several options one could pick and I refuse to argue about definitions.
On top of your requirement of no or-branching one might require reversibility (without or-branching) allowing z-chains but not whips.
Or even prohibit a link to depend on a 'target', not allowing z-chains either.

Yes, that's exactly what some of my chains do. Again, you're bringing nothing to the discussion.

OR-branching is equivalent to following several streams of reasoning in parallel and comparing them permanently.
P.O.'s argument for forcing chains ("the branches are independent") is obviouysly invalid.

If someone else looks at the notation, they can check each branch independently. I believe that is what P.O. meant.[...] I explained the independence of the branches, not whether they are easier or harder to manage than memory chains. I refuse to discuss such a subjective matter.

There's nothing subjective. It's just you that don't understand the major difference between reading a solution and finding it.

[marek stefanik]

How is remembering the guardians [in oddagons] easier than remembering a single target?

It's not. I don't think remembering the target is an issue, I only mentioned it because it was missing in your explanation.

In my chains, you don't have to remember "all direct consequences of former steps". You only have to remember the sequence of right-linking candidates.

My purpose in solving is not notation but full resolution path.

Oh, no, have I been using stte wrong the whole time? I mean, I never remember the exact order I fill them in... Should I just use stoom (singles to out of memory) instead?

I can only see that you have no concrete idea to propose about chains vs nets.

Au contraire, there are several options one could pick and I refuse to argue about definitions.
On top of your requirement of no or-branching one might require reversibility (without or-branching) allowing z-chains but not whips.
Or even prohibit a link to depend on a 'target', not allowing z-chains either.

Yes, that's exactly what some of my chains do. Again, you're bringing nothing to the discussion.

The problem is, you are arguing about a definition. A definition of a word different people use differently, ie. there is no established one. There is nothing to bring to the discussion besides that.

There's nothing subjective.

I suppose we call it off with the conclusion that you are the one using the objectively correct complexity hierarchy of solving techniques, while roughly everyone else is wrong.

Marek

[P.O.]

Marek is right i was speaking about the checking of the forcing chain and that is done by reading each branch one at a time, obviously;

the algorithm to find the forcing chains does not work exactly like the one for ordinary chains; let's consider the first forcing chain of this puzzle 43; here is a sketch of the algorithm used to find it:
it starts by identifying the candidates that are in a trilocation relationship, in this case n3 in r189 c8 that i call the roots;

Code: Select all

 (((3 0) (1 8 3) (1 3 5 8)) ((3 0) (8 8 9) (3 4 5 8)) ((3 0) (9 8 9) (3 4 5)))


for each root a tree of links is built with the current settings of the algorithm, in this case MaxTreeDepth 3 ALS ON no more than TRIPLET:

Hidden Text: Show

Code: Select all

((3 0) (1 8 3) (1 3 5 8))
   (((3 1 1) (7 7 9) (2 3 8))
    ((1 1 1 11) ((3 7 3) (1 5 8)) ((3 8 3) (1 5 7 8)))
    ((1 1 1 11) ((1 4 2) (1 9)) ((1 5 2) (1 2 8)))
    ((3 1 1 2) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)))
    ((8 1 2 223) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
    ((5 1 3 223) ((1 1 1) (2 3 5)) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
    ((2 1 3 223) ((1 1 1) (2 3 5)) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8))))
((3 1 1) (7 7 9) (2 3 8))
   (((2 2 10) (4 7 6) (1 2 5)) ((2 2 2 11) ((7 9 9) (2 8)) ((9 9 9) (2 4 5))))
((1 1 1 11) ((3 7 3) (1 5 8)) ((3 8 3) (1 5 7 8)))
   (((1 2 1 13) ((1 4 2) (1 9)) ((1 5 2) (1 2 8))))
((8 1 2 223) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
   (((8 2 12) (8 3 7) (3 4 8 9)) ((8 2 1 13) ((7 7 9) (2 3 8)) ((7 9 9) (2 8))))
((8 2 12) (8 3 7) (3 4 8 9))
   (((2 3 113) (9 9 9) (2 4 5))
    ((5 3 2 32) ((8 8 9) (3 4 5 8)) ((9 8 9) (3 4 5)))
    ((4 3 2 32) ((8 8 9) (3 4 5 8)) ((9 8 9) (3 4 5)))
    ((9 3 1 11) ((8 4 8) (3 9)) ((8 6 8) (2 3 5 9)))
    ((9 3 1 11) ((9 2 7) (2 3 7 9)) ((9 3 7) (1 3 4 9)))
    ((8 3 2 4) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
    ((8 3 1 2) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((6 3 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((4 3 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((3 3 1 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8))))
((2 2 10) (4 7 6) (1 2 5))
   (((2 3 2 2) ((7 9 9) (2 8)) ((9 9 9) (2 4 5))))
   

((3 0) (8 8 9) (3 4 5 8))
   (((8 1 10) (8 3 7) (3 4 8 9)) ((9 1 9) (8 4 8) (3 9))
    ((3 1 1) (2 7 3) (3 8 9)) ((1 1 102) (1 4 2) (1 9))
    ((2 1 1 31) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((2 1 1 51) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((8 1 1 11) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((5 1 1 11) ((9 8 9) (3 4 5)) ((9 9 9) (2 4 5)))
    ((5 1 1 11) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((4 1 1 11) ((9 8 9) (3 4 5)) ((9 9 9) (2 4 5)))
    ((4 1 1 11) ((8 1 7) (2 3 4)) ((8 3 7) (3 4 8 9))))
((8 1 10) (8 3 7) (3 4 8 9))
   (((9 2 1 11) ((8 4 8) (3 9)) ((8 6 8) (2 3 5 9)))
    ((9 2 1 11) ((9 2 7) (2 3 7 9)) ((9 3 7) (1 3 4 9)))
    ((8 2 1 2) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((8 2 2 2) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
    ((2 2 1 201) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((6 2 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((4 2 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((3 2 1 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8))))
((9 1 9) (8 4 8) (3 9))
   (((1 2 9) (1 4 2) (1 9)) ((9 2 1) (2 6 2) (7 8 9)) ((9 2 1) (1 9 3) (5 8 9))
    ((4 2 111) (8 1 7) (2 3 4))
    ((5 2 1 31) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((2 2 1 31) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((9 2 1 2) ((9 2 7) (2 3 7 9)) ((9 3 7) (1 3 4 9))))
((3 1 1) (2 7 3) (3 8 9))
   (((9 2 2 11) ((5 7 6) (1 5 8 9)) ((6 7 6) (5 8 9)))
    ((9 2 2 11) ((1 9 3) (5 8 9)) ((2 9 3) (6 7 8 9)))
    ((3 2 1 2) ((1 1 1) (2 3 5)) ((1 2 1) (2 3 5 8)))
    ((8 2 2 223) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((6 2 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((4 2 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8))))
((1 1 102) (1 4 2) (1 9))
   (((9 2 76) (8 4 8) (3 9))
    ((1 2 2 2) ((7 5 8) (1 2 6 7)) ((9 5 8) (1 2 5 7)))
    ((1 2 1 2) ((3 7 3) (1 5 8)) ((3 8 3) (1 5 7 8)))
    ((5 2 1 213) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((2 2 1 213) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((8 2 1 201) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((2 2 1 201) ((7 7 9) (2 3 8)) ((7 9 9) (2 8))))
((2 1 1 31) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
   (((9 2 77) (8 4 8) (3 9)) ((5 2 1 31) ((9 8 9) (3 4 5)) ((9 9 9) (2 4 5)))
    ((4 2 1 31) ((9 8 9) (3 4 5)) ((9 9 9) (2 4 5)))
    ((5 2 1 213) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((2 2 1 213) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9))))
((2 1 1 51) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
   (((9 2 77) (8 4 8) (3 9)) ((4 2 76) (8 1 7) (2 3 4))
    ((8 2 111) (8 3 7) (3 4 8 9))
    ((8 2 1 201) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((2 2 1 201) ((7 7 9) (2 3 8)) ((7 9 9) (2 8))))
((5 1 1 11) ((9 8 9) (3 4 5)) ((9 9 9) (2 4 5)))
   (((9 2 77) (8 4 8) (3 9)) ((5 2 1 15) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((2 2 1 213) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9))))
((5 1 1 11) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
   (((9 2 77) (8 4 8) (3 9)))
((4 1 1 11) ((9 8 9) (3 4 5)) ((9 9 9) (2 4 5)))
   (((4 2 1 15) ((8 1 7) (2 3 4)) ((8 3 7) (3 4 8 9))))
((4 2 76) (8 1 7) (2 3 4))
   (((4 3 2 2) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8))))
((9 2 1) (2 6 2) (7 8 9))
   (((4 3 111) (8 1 7) (2 3 4))
    ((5 3 1 31) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((2 3 1 31) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9))))
((9 2 1) (1 9 3) (5 8 9))
   (((9 3 2 2) ((5 7 6) (1 5 8 9)) ((6 7 6) (5 8 9))))
((8 2 2 223) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
   (((9 3 77) (8 4 8) (3 9)) ((2 3 111) (8 1 7) (2 3 4))
    ((4 3 101) (8 3 7) (3 4 8 9))
    ((5 3 1 211) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9)))
    ((2 3 1 211) ((8 5 8) (2 5)) ((8 6 8) (2 3 5 9))))
((2 2 1 201) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
   (((9 3 77) (8 4 8) (3 9)) ((4 3 76) (8 1 7) (2 3 4))
    ((2 3 1 15) ((9 1 7) (1 2 3 4 7)) ((9 2 7) (2 3 7 9))))
   
   
((3 0) (9 8 9) (3 4 5))
   (((3 1 1) (2 7 3) (3 8 9)) ((8 1 1 31) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
    ((2 1 1 31) ((7 7 9) (2 3 8)) ((7 9 9) (2 8))))
((3 1 1) (2 7 3) (3 8 9))
   (((9 2 2 11) ((5 7 6) (1 5 8 9)) ((6 7 6) (5 8 9)))
    ((9 2 2 11) ((1 9 3) (5 8 9)) ((2 9 3) (6 7 8 9)))
    ((3 2 1 2) ((1 1 1) (2 3 5)) ((1 2 1) (2 3 5 8)))
    ((8 2 2 223) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((6 2 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((4 2 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8))))
((8 1 1 31) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))
   (((8 2 12) (8 3 7) (3 4 8 9))
    ((8 2 2 13) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8))))
((8 2 12) (8 3 7) (3 4 8 9))
   (((9 3 1 11) ((8 4 8) (3 9)) ((8 6 8) (2 3 5 9)))
    ((9 3 1 11) ((9 2 7) (2 3 7 9)) ((9 3 7) (1 3 4 9)))
    ((8 3 2 2) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
    ((6 3 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((4 3 3 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8)) ((3 3 1) (4 6 8)))
    ((3 3 1 223) ((2 1 1) (3 4 6)) ((2 3 1) (3 4 6 8))))
((9 2 2 11) ((5 7 6) (1 5 8 9)) ((6 7 6) (5 8 9)))
   (((9 3 2 13) ((1 9 3) (5 8 9)) ((2 9 3) (6 7 8 9))))


then the trees are analyzed and the links process to find eliminations, in this case 6 are found

Code: Select all

Eliminations: 6
0: ((((8 8 9) (3 4 5 8)) ((7 2 7) (2 3 7 8))) 8)
1: ((((7 2 7) (2 3 7 8)) ((3 3 1) (4 6 8)) ((2 3 1) (3 4 6 8))) 8)
2: ((((9 6 8) (2 3 5 7 9)) ((8 3 7) (3 4 8 9))) 9)
3: ((((2 7 3) (3 8 9)) ((1 2 1) (2 3 5 8)) ((1 1 1) (2 3 5))) 3)
4: ((((8 3 7) (3 4 8 9))) (3 4 9))
5: ((((8 8 9) (3 4 5 8))) (8))


i chose the last one in my solution, so its chain is recovered

Code: Select all

Elimination: ((((8 8 9) (3 4 5 8))) (8))

((3 0) (9 8 9) (3 4 5))
((8 1 1 31) ((7 7 9) (2 3 8)) ((7 9 9) (2 8)))

((3 0) (8 8 9) (3 4 5 8))

((3 0) (1 8 3) (1 3 5 8))
((8 1 2 223) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
((8 2 12) (8 3 7) (3 4 8 9))


that i translate in some readable notation

Code: Select all

3r189c8 => r8c8 <> 8
 r1c8=3 - 258b1p128 - b7n8{r7c2 r8c3}
 r8c8=3 -
 r9c8=3 - 28r7c79


considering the subset 258b1p128 it is only for convenience that i write it as a whole triplet the algorithm never use a subset as a whole it decomposes it in groups of candidates that become distinct links, in this case a group of two 8, a group a three 5 and a group of three 2:

Code: Select all

 ((8 1 2 223) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
 ((5 1 3 223) ((1 1 1) (2 3 5)) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))
 ((2 1 3 223) ((1 1 1) (2 3 5)) ((1 2 1) (2 3 5 8)) ((3 2 1) (2 5 8)))


[denis_berthier]

then the trees are analyzed and the links process to find eliminations,

Exactly what I said: you have to combine the 3 trees in order to find any elimination. How could it be different, anyway?
By combining the trees, you multiply their complexities.

[denis_berthier]

My purpose in solving is not notation but full resolution path.

Oh, no, have I been using stte wrong the whole time? I mean, I never remember the exact order I fill them in... Should I just use stoom (singles to out of memory) instead?

What does stte have to do here? Are you so unable to concentrate on a precise topic?

The problem is, you are arguing about a definition. A definition of a word different people use differently, ie. there is no established one. There is nothing to bring to the discussion besides that.

Yes, for people who earn their bread by playing on ambiguity, I understand it's hard to comply with precise definitions.

There's nothing subjective.

I suppose we call it off with the conclusion that you are the one using the objectively correct complexity hierarchy of solving techniques, while roughly everyone else is wrong.

The fact is, as of now, everyone else (including you) is unable to produce a consistent definition of complexity. So don't waste more of my time with your phoney arguments.

[marek stefanik]

What does stte have to do here? Are you so unable to concentrate on a precise topic?

My point was that since you see no connection between full resolution paths and notations and require the solver to create a full resolution path, it seems that you want manual solvers to memorise everything they do even beyond singular steps, which is neither sensible nor necessary. But at least it somewhat explains your contempt for us.

Yes, for people who earn their bread by playing on ambiguity, I understand it's hard to comply with precise definitions.

I have no problems with established definitions, rather with people trying to enforce their definitions regardless of the consensus (which regarding this topic there seems to be none).

The fact is, as of now, everyone else (including you) is unable to produce a consistent definition of complexity. So don't waste more of my time with your phoney arguments.

The problem is, with manual solvers in the picture, most such questions are purely subjective.
With a simplified problem, considering only computer programs and assuming some other conditions (such as forms of pencilmarking used), there still is no general answer.
The complexity of AICs depends on the lenght and the number of bivalues/bilocals in the grid, whereas the complexity of braids depends on the lenght and the number of unresolved variables.
There is no universal relation between the two numbers, other than one obviously being smaller than the other (or equal – BUGs).

Marek

[denis_berthier]

.
The manual solver argument has been used ad nauseam by people unable to have any rational arguments.
End of discussion.