The New Sudoku Players' Forum

[SteveG48]

Now let's look at what you've written in the brackets:

(1)r8c5 =BUG= (51)r8c69

What this says to me is that if 1 is not true in r8c5 then BUG is true.

I understand. I had the same difficulty when I first saw those expressions. That's not what it says, however. Once I figured that out, it's seemed quite natural: just a single link with an explanation in the middle.

Hmm. That almost convinces me. The part about a single link (double =) with an explanation in the middle. I could grow to like it. The double = is itself an explanatory symbol in that it isn't necessary in the Boolean sense. If that, then why not more explanation incorporated in the link?

PS. AICs have other weird expressions too, starting with things like (3=5) which make zero sense unless you know how it's to be interpreted. The most unintuitive sudoku notation I've seen is the truth and link sets which are pretty much impossible to interpret with just common sense (Denis Berthier was right about that and Allan Barker should have listened -- even though everything else he did was brilliant).

Right to an extent, but anyone who's at all interested in this sort of thing learns first of all that the symbols = and - have a different meaning in Sudoku notation than in other places. It's not a matter of interpretation; it's a matter of accepting a new definition for old operators. I don't see it as weird.

[eleven]

There's a BUG+2

SpAce,

i know that you like long discussions. I don't, especially not about notations.
Yes, you can argue, that the expression is logically correct, but it does not look like that. Looking at the guardians there is a BUG+3, therefore i would expect this one in the brackets, when you write BUG, but you use an almost BUG+2, combined with an implication of one guardian.

You wanted a feedback, and i tell you i really dislike it, and also the other versions, though they would be better understandable.
You know, i am not a fan of AIC's, but this even reminds me on the fun challenges to write a completely unreadable (logically correct, useful) c program.

[SpAce]

i know that you like long discussions.

Not really. I like the results of such discussions, as I usually learn something. I like learning. I also like sharing what I've learned, because it makes a feedback loop which helps me learn more and find mistakes in my own thinking.

I don't, especially not about notations.

I'm glad that you've nevertheless endured some with me, because I've learned a lot from them!

You wanted a feedback, and i tell you i really dislike it

And I appreciate that feedback. I knew my notation was controversial, but I was a bit surprised that both your and Steve's feedback concentrated on parts I wasn't really expecting to be challenged. That made it an exceptionally good learning experience.

You know, i am not a fan of AIC's, but this even reminds me on the fun challenges to write a completely unreadable (logically correct, useful) c program.

Well, if one can excel in those kinds of challenges, it's pretty certain one can also write perfectly correct and legible programs for normal use (or as legible as anything with C can be). The other way around is not necessarily true. Since this puzzle had little potential for diverse solutions in the first place, and Steve and Clement had pretty much emptied the slot machine already, I took it as an opportunity to play with notations because it was the only interesting thing left. It doesn't mean I would normally write it like that, but I like to have options and know the limits of the languages I use. So, I consciously test those limits and probably will continue to do so. Feedback like this helps to define practical limits and find holes in my own thinking, so I'm grateful for it. We all do this for our own reasons, and I think the main thing is that everyone can enjoy the parts they like.

[SpAce]

As I said, I was actually expecting more feedback on some other features of that controversial chain, but didn't really get any. What do you guys think of the 3D extension, i.e. the ability to treat rows, columns, and boxes just like digits? I kind of like that a lot myself, because it makes especially X-Chains much shorter and also easier to read (once used to the format). However, I have one question about it. How to deal with group links?

Let's look at a different example taken from here, a Grouped 2-String Kite. In normal Eureka I would write it like this:

(3)r3c7 = r3c45 - r12c6 = (3)r6c6 => -3 r6c7

In 3D Eureka I would write it like this:

3r3c(7=45) - 3r(12=6)c6 => -3 r6c7

But should it actually be like this:

3r3c(7=4|5) - 3r(1|2=6)c6 => -3 r6c7

? The latter seems logically more correct and in line with how ALS nodes are handled in normal Eureka. However, the former is more readable and in line with how X-groups are normally marked (and a bit shorter). Since the row/col/box manipulations of the 3D notation always deal with a single digit and cells that see each other (at least in this iteration), can we safely drop the '|', as OR is the only possibility in those situations?

[SteveG48]

Honestly, I would prefer what you call normal Eureka.

I recognize that it could be just familiarity that makes me prefer it, but even though the 3D notation is shorter, I don't think it would be as easy for beginners to learn. Back when a lot of us where going to the "abbreviated" notation, I switched back because David suggested that it just wasn't as easy for beginners, and they might be discouraged. I think the same applies here. I can see us ending up with parentheses both in the candidates lists the cell indicators, with ORs and ANDs as you've already suggested. Clarity gives way to brevity.

Now let's look at part of one of your examples. You suggest 3r3c(7=45) might be written 3r3c(7=4|5). I interpret the former to mean that if 3 is not true in cell r3c7 then it is true in the 2 cell set r3c4 and r3c5. We have implicitly agreed that it does not mean that 3 is true in both of those cells (which would be untrue). The latter I translate as if 3 is not true in the cell r3c7 then it is true in either the single cell r3c4 or the single cell r3c5. Both statement are logically true in the example, but in general, if all I need is to know that a candidate is true in a set of cells, I see no reason to be any more explicit than that.

[SpAce]

Honestly, I would prefer what you call normal Eureka.

As always, I like honest feedback!

I recognize that it could be just familiarity that makes me prefer it

Well, it's hard to know for sure. Unlearning is very hard, and if one has years of experience with one style, everything else feels unnatural for a long time.

but even though the 3D notation is shorter, I don't think it would be as easy for beginners to learn.

Again, that's hard to know. The notation does seem a bit more complicated, but it's also more consistent and provides several logical benefits. Consistent and logical things are usually easier to learn than the opposite kind. To me the main attraction is not the shortness but the fact that every axis of the 3D cube is treated the same way, which makes understanding many patterns and especially more complicated concepts (such as truth and linksets) easier. The linking action is definitely easier to see that way.

Back when a lot of us where going to the "abbreviated" notation

What is the "abbreviated" notation? Is it similar to what we're discussing ("3D Eureka" -- my term) or something else?

I switched back because David suggested that it just wasn't as easy for beginners, and they might be discouraged.

Well, David is so far removed from the real concerns of beginners, that I wouldn't put too much weight on his suspicions of what's discouraging and what's not. I've made the jump from basics to complex AICs in the past year and a half, so -- even though I acknowledge that I can speak only for myself -- at least I have some very recent experience of the struggles that jump requires. A bit of added complexity in one part could actually make other things a lot simpler. If I'd seen 3D Eureka from the start, I think it would have made perfect sense -- and things that make sense are easy to learn. (The biggest problem in learning Eureka at all is that the main teaching sites, such as SudokuWiki and Hodoku, use the much inferior NL notation, which is why I learned it before even knowing about Eureka).

As I said, X-Chains are a clear example which would benefit from the 3D notation. Not only does it make them shorter, but it also makes them easier to understand because the strong links are all inside the nodes which are connected by weak links. The shape of the pattern is easier to grasp that way because the linking axes are clearly seen. The same is true about any Wing-patterns, perhaps even more so. The whole Wing-concept used to be very hard for me to grasp, because the various named Wings seemed to have nothing in common at first glance. In Eureka notation XY-Wings have three nodes; W-Wings, M-Wings, H-Wings, L-Wings etc have four, and an S-Wing has even five nodes. They look nothing like each other. What they all have in common, however, is three strong links and two weak links -- but that's not obvious because the chains have a different number of nodes (in fact, someone had to point it out to me). With the 3D notation they can all be written just like XY-Wings -- three nodes with the strong links inside them and two weak links connecting them. That makes it much easier to compare the wing types and see how they're similar and different.

Added: I acknowledge that I'm using the term "node" improperly above. The number of real, logical nodes, remains the same regardless of the notation. What I meant was the apparent chain nodes, but I don't know a good term for those.

I think the same applies here. I can see us ending up with parentheses both in the candidates lists the cell indicators, with ORs and ANDs as you've already suggested.

That's why I wanted to discuss this. I recognize the risk of introducing complexity or readability issues, but I think that with a set of right limitations those can be controlled. For example, (at least currently) I think there should be only one set of parenthesis in a node, limited to the part where linking action occurs (but that could be any of n, r, c, or p -- instead of just n as in normal Eureka). All other parts in a node are fixed so they don't normally require brackets (but there may be exceptions). However, in larger ALS nodes that results in poor readability, which is why I thought about adding the optional dot separator for the n-candidates.

Clarity gives way to brevity.

I agree, but they're not mutually exclusive concepts. Some forms of brevity, such as removing white space, are really bad for clarity. Other forms, however, can actually improve it because the eyes and the brain can catch a bigger portion of the whole at once. I know it wasn't always so, but these days I find shorter chains with larger nodes easier to follow than the same presented as many separate cells. There, however, I acknowledge that most beginners probably have a different preference. (I remember vividly how hard it was at first to read chains with large connected ALS nodes -- but then again, I think part of that problem could be alleviated with clearly marked linking digits).

Now let's look at part of one of your examples. You suggest 3r3c(7=45) might be written 3r3c(7=4|5). I interpret the former to mean that if 3 is not true in cell r3c7 then it is true in the 2 cell set r3c4 and r3c5. We have implicitly agreed that it does not mean that 3 is true in both of those cells (which would be untrue). The latter I translate as if 3 is not true in the cell r3c7 then it is true in either the single cell r3c4 or the single cell r3c5. Both statement are logically true in the example, but in general, if all I need is to know that a candidate is true in a set of cells, I see no reason to be any more explicit than that.

I think we understand it exactly the same way. I also take that so that you think there's no need to use the '|' in single digit situations because it's implied? I think I agree with that, even though it introduces a bit of inconsistency. The readability problem of the other choice seems bigger.

Edit: Added a clarification for the improper use of "node".

[SteveG48]

What is the "abbreviated" notation? Is it similar to what we're discussing ("3D Eureka" -- my term) or something else?

Abbreviated notation refers to listing only the relevant candidates in a set (logically perfectly correct) rather than all the candidates (also correct, but longer). I think it was Eleven who tried listing all the candidates but with the relevant ones in a different font. Nice, but extra work for the writer.

[SpAce]

Abbreviated notation refers to listing only the relevant candidates in a set (logically perfectly correct) rather than all the candidates (also correct, but longer). I think it was Eleven who tried listing all the candidates but with the relevant ones in a different font. Nice, but extra work for the writer.

Ah yes, that abbreviation. I've always preferred the longer form, though these days I'm fine with both (except with loops where those bystander digits are actually important). I do remember, however, that the short form was very confusing when I was more of a newbie, so I agree with David on that. Then again, I welcome both forms because a bit of confusion is good for deeper learning -- at least for those who have enough motivation to dig deeper. For example, I needed some help from veterans to understand why the short form was even correct (seemed unintuitive), but when I did, that deepened my overall understanding of the ALS logic and AICs in general. That's why my pedagogic philosophy somewhat differs from David's.

I don't think techniques and notations need to be dumbed down to make more people understand them. I think they just should be well-documented, with progressive examples from simple to complex, so that interested parties can find the information they need to understand and use them in full. Unfortunately that information is very scattered, which makes some techniques quite hard to learn. That also includes more complex Eureka scenarios.

For example, I still haven't found good documentation -- or even clear definitions -- of MSLS and multi-fish, though I'm slowly getting the idea (I think). Just yesterday I made an accidental discovery that Sue de Coq is a mild case of MSNS. Had I known that before, it would have made it much easier to connect the dots and understand more complicated MSLS examples (which is all that's included in the main how-to-document). In any case, I've pretty much come to the conclusion that it's easier and more useful to learn the all-powerful principles of Allan Barker's well-documented set logic (even without Xsudo) than to try to understand supposedly more human-friendly special cases of it in isolation. But, this is off-topic.