A frequently observed pattern is a strong corner where a candidate is part of a bi-location pairing in both rows and columns. Sometimes you can create a multi-branched AIC-net using both strong link pathways. A nice alternative way of looking at things that keeps the AIC single-threaded is to form an X-wing out of that strong corner. An alternate digit in the strong corner cell can serve as one exit, and the extra weak links in the opposite cornered box can often combine to form a useful strong link in that box. Here is an example...

Myth, thanks for explaining this in more depth. I look on any new source of a strong link as a little gem these days. But here you get more than one little gem, you get the added benefit of: extra weak links in the opposite cornered box can often combine to form a useful strong link in that box. Such as the (5)r1c5|r2c6 = (5-7)r2c5 above, a construct that ordinarily wouldn't be possible. 2 'new' strong links for the price of one! Love it!

As I understand it, essentially you need to have a sashimi X-wing pattern present to make this work.

Myth, one of your previous notation suggestions that I liked very much and is quite versatile, was to use (5#2)r1c9,r6c5 to indicate a node where the cells would be occupied by two (5)s. I would therefore like to promote your previous concept for a wider uptake and use it again with "strong corners":

I find it more palitable to consider (5#1)r1c5,r2c6 as a single node with one ongoing strong link rather than two alternative nodes each with a weak link to the next one. It also makes the chain easier to accept in the reverse direction.

I obviously wouldn't have any problem with that alternate notation either, David . It is not very well known over here, though it does come in handy when notating AIC2 (K-pattern) loops, URs, BUG-Lites, and MUGs.

Here digits shown are both bi-local in the row 1 and the two boxes and can be accompanied by any number of other candidates. This produces this AIC using the two strong corners.

(5)r1c6 = (5#2)r1c1,r3c4 -[RR]- (6#2)r1c4,r3c1 = (6)r1c3

The Resolvable Rectangle theorem tells us that [56] [65] is an invalid combination as it's impossible for a rectangle of cells located in two boxes to have a two digit solution unless one of those cells is a given.

The interesting point here is that the two candidates involved don't co-reside in any of the RR cells!The linking corner cells can be any of the four cells in the two boxes which see the opposite corners of the RR, or even group nodes made up of two of them in the same box.

This has been a purely theoretical analysis, and it would be interesting to know if such a situation can ever occur in a real puzzle.

It's been a toss-up as which thread to post this item in, but because of the notation used and the introduction of the possibility of group nodes being used as strong corners, I opted for this one.

Myth, I know you wouldn't disagree that the elimination in your example can be obtained in other ways.eg (9)c9=(9-5)g9=(5)a9-(5=1)b8-(1=6)b7 =><1> <6> c9.and fully realise that your purpose is to illustrate a potential pattern.But the question is : will that potential pattern ever be simpler to spot than a simpler alternative ?[/code]

Myth, since you described this 'strong corner', I've come across 2 occurrences of it already- one of them leading to a very helpful deduction, which leads me to believe that this pattern arises frequently enough to be very useful in the future.

Contrary to what I said earlier, there really doesn't appear to be a true sashimi pattern there; all you basically need is the 'strong corner' and one or two targets for the weak link. My only point being that it deserves a good name- any ideas? How about naked wing or catty-corner! (BTW: hats off that you can still come up with stuff like this- its hard to find new tools for the manual-solving bag these days.)

I don't follow any of the above discussion, but that's nothing new for me. What does concern me is that I see something (don't recall technique name) and wonder why anything more complicated would be proposed.

daj95376 wrote:I don't follow any of the above discussion, but that's nothing new for me. What does concern me is that I see something (don't recall technique name) and wonder why anything more complicated would be proposed.

If I'm following your point correctly (and maybe I'm not): This puzzle was the UK Extreme #104 from the Eureka forum and there were several solutions posted for it. Myth brought the 'strong corner' part of his solution over here for interest sake to point out another source of a strong link, not as the most efficient way of solving this part of the puzzle.

Last edited by DonM on Sun Oct 12, 2008 11:12 am, edited 1 time in total.

What does concern me is that I see something (don't recall technique name) and wonder why anything more complicated would be proposed.

Essentially that was my point earlier.However it may be that DonM

I've come across 2 occurrences of it already- one of them leading to a very helpful deduction, which leads me to believe that this pattern arises frequently enough to be very useful in the future.

has found a position where this pattern was easier to see that any simpler alternative.DonM : if it is convenient, could you post the grid you referred to ?

I probably will- it's part of a challenge puzzle series that we do on Eureka & I haven't posted the puzzle there yet. Once I do, I can post the part I referred to above here.

But, unless I'm missing something, both your & Dannie's solutions are just general alternatives for this particular puzzle, not alternatives that would subsume the 'strong-corner' principle in other puzzles (though I must admit I didn't look at yours too closely because I find it easier to visualize r#c# notation).

But, unless I'm missing something, both your & Dannie's solutions are just general alternatives for this particular puzzle, not alternatives that would subsume the 'strong-corner' principle in other puzzles

Entirely right.But it would be nice to have just one instance where the pattern was easier than something else that exists already,

(though I must admit I didn't look at yours too closely because I find it easier to visualize r#c# notation)

Never could understand why notation which seeks to be succinct uses twice as many characters as necessary to specify a cell (r1c1 v a1).Can you ?

aran wrote:Never could understand why notation which seeks to be succinct uses twice as many characters as necessary to specify a cell (r1c1 v a1).Can you ?

You have a point (and a point that has been made before), but I'm afraid it's too late to go back now- r#c# is pretty much the standard here and on Eureka. (Digressing: When it comes to compact, logical languages in general, I've often thought that we all would have done well to stick with Latin.)

Last edited by DonM on Sun Oct 12, 2008 12:23 pm, edited 4 times in total.