The New Sudoku Players' Forum

[Cenoman]

Here is how 1r9c5 is eliminated with TDP considering the 5 of C5.

Code: Select all

            -> 4r7c5 - - -
          /                \
 5r1c5 ->                   -> 1r9c6 => -1r9c5
          \                /
            -> 3r3c5 -> 8r3c6

 5r7c5 -> 2r7c2 -> 2r1c3 -> 4r6c3 -> 8r6c4 -> 1r6c5 => -1r9c5

 5r9c5 => -1r9c5

It's hard to be convinced by such a diagram.
If I write my kraken your way, i.e. omitting the left node of my strong link terms, I get:
5r1c5 -> 7r1c46.r2c4 (ALS b2p134)-> 8r3c6 -> 1r9c6
5r7c5 -> 2r7c2 -> 2r4c1 -> 1r6c5 (ALS r6c345)
5r9c5
I mention explicitly the ALSs used, otherwise it is not understandable

In the first chain you use AHS weak links rather than ALS strong links in box 2, and in the second chain you use conjugates 2s of row 1 rather than colummn 1. No matter. With the same options, I would get

5r1c5 -> 3r3c5 -> 8r3c6 -> 1r9c6 (the lower part of your first chain)
5r7c5 -> 2r7c2 -> 2r1c3 -> 1r6c5 (ALS r6c345)
5r9c5

Two concerns:
-First: I wondered why you needed a branching to demonstrate 5r7c5 -> 1r9c6
In my PMs (Pencil Marks) r9c6=18, in yours r9c6=148, and many other cells have candidates eliminated by basics. At least, you should check that you have comprehensively processed the basic moves (e.g. NP 25 r17c2 and HP 89 r45c2 are not accounted for...)
-Second: in r6c345 you also use the ALS and you try to explicit that in your diagram '2r1c3 -> 4r6c3 -> 8r6c4 -> 1r6c5'
2r1c3 -> 4r6c3 and 4r6c3 -> 8r6c4 are clear implications, since r6c3 and r6c4 are bivalues. But 8r6c4 -> 1r6c5 is not a self standing implication, as r6c5=148. You must have memorised 4r6c3.
Your diagram should mention it, e.g. by tagging with a "*" the concerned cells, or by drawing the branching:
2r1c3 -> 4r6c3* -> 8r6c4 -> *1r6c5 (as supporters of memory chains do)

Code: Select all

2r1c3 -> 4r6c3 -> 8r6c4 -> 1r6c5
                 \     /
                    ->

In this example, you could have used the dual AHS instead:
2r1c3 -> 2r9c3 -> 9r6c8 -> 1r6c5
but it will not work in every case (e.g. with AHS containing several bystander digits).

I am not ready to depart from writing chains in Eureka formalism. Please, continue to post your solutions in yours, with explaining diagrams if needed. I promise to try to decipher them from time to time.

PS at the moment of posting this message, I see SpAce's one with the same topics. I apologize for being redundant, but I swear not to have read any word of SpAce's message when writing mine.

[Mauriès Robert]

Hi Cenoman,
Thank you for your comments. I read SpAce's too.
Understand that with TDP, I build a chain with only one principle : B1, B2, ... Bn being candidates composing the chain, any candidate Bn+1 placed by the basic techniques(*) IF candidates B1, B2,..., Bn are placed is a candidate of the chain.
It is a complex chain in general (what I think you call a net) and it is not always easy to write it with a series of symbols. It is easier to mark the candidates of the track on the puzzle, which is what I usually do.
With this TDP approach I do not bother with all the terminology that is yours (strong and weak links, nodes, ALS, etc...) which in my opinion complicates things a lot for someone who is not familiar with this Eureka language. I also note that SpAce often corrects poor writing by both sides, which shows that there is no unanimity on the writing of language.
I still try to make myself understood by your community by detailing through these diagrams how I build the tracks and sometimes I still make some writing mistakes.
Anyway, thank you for taking an interest in what I do.
Robert
(*) Singles, closed sets (doublets, triplets,...), alignments.

[StrmCkr]

Krakens are dead end set/aic logic using any of its nodes to bridge to another chain or aic.
there is no fn trial and error evolved.

tdp. Doesn't not. Build networks of nodes its pure brute force trialing localized points for subnet truths. Memory chains
its black and white written clearly in his documentation.


If u really need me to re-post the private message in detail again outlying the inherent brute force aspect of it i will
Its clear when u can test a grid for digits track a and b and uncover full solutions which you have often skipped mentioning.

[SpAce]

Code: Select all

2r1c3 -> 4r6c3 -> 8r6c4 -> 1r6c5
                 \     /
                    ->

Now I feel dumb! Why didn't I draw it that way? Much better! Also more in line with the memory chain representation.

PS at the moment of posting this message, I see SpAce's one with the same topics. I apologize for being redundant, but I swear not to have read any word of SpAce's message when writing mine.

Not a problem at all. I'm just glad you reinforced my message and provided more and better examples and alternatives too. Redundancy is much better than contradiction!

[SpAce]

Hi Cenoman,
Thank you for your comments. I read SpAce's too.

But no need to thank for mine (even though I thought I mostly defended your point of view on krakens)? Have I offended you? You've avoided responding to my comments lately. (I'd be particularly interested in your thoughts on what I said about deadly patterns and proving uniqueness, as you've been mentioning it as a reason to avoid them.)

With this TDP approach I do not bother with all the terminology that is yours (strong and weak ties links, knots ?, ALS, etc...) which in my opinion complicates things a lot for someone who is not familiar with this Eureka language.

First, those terms are not particular to the Eureka language. They're standard sudoku concepts regardless of the language used to express them, and as far as I know, they've been around before Eureka. They're just as valid if you use the obsolete Nice Loop notation (like Hodoku), or the implication chain notation, or set logic, or even TDP. Eureka just happens to be the best available language to express those concepts in chaining logic. The second most important sudoku language is the set logic notation (and its most common subset for fishes) because some types of logic are hard to express with chains.

Secondly, the main reason why you think it complicates things is that you haven't bothered to learn it. If you had, you'd realize that such a common and relatively expressive language actually simplifies things a lot, because it allows compact and unambiguous communication. Your notation doesn't and it never will, because it's not a matter of learning it better. It's an inherent weakness that simply can't be overcome, because it doesn't have nearly the same expressive power.

Your notation is more verbose, yet it communicates much less, even with attached images and diagrams (which it really requires to be understandable at all). How is that a good thing? Even a mediocre Eureka user can read and write detailed pieces of logic way faster and more accurately than an expert in TDP, and the logic can even be followed without seeing the related grid. The only advantage of the TDP notation is that it's indeed simpler, but that simplicity comes at a cost that no expert player who's already learned better tools wants to pay.

I also note that SpAce often corrects poor writing by both sides, which shows that there is no unanimity on the writing of language.

Here you're closer to the truth, but not quite. It's true that Eureka is not a trivial language if you want to write it fully correctly. However, there's actually little relevant disagreement about what's correct and what's not. AIC links are defined in terms of logic gates (as mentioned by StrmCkr), which means that every AIC (whether written in Eureka or some other language) can be converted into boolean logic and analyzed as such. If the boolean logic works it's correct, otherwise not. Those are the kinds of mistakes I point out because they're not matters of opinion.

Purely stylistic issues are much less relevant, and there's quite a bit of allowable variance there, although we all have strong and sometimes opposite opinions about them. In fact, I've taken a LOT of flak about my stylistic choices, so it's not like I'm the only one complaining about others' chains.

Last but not least, even if Eureka is used slightly incorrectly, it rarely if ever fails to communicate the intent. That's the important part. The main reason why I obsess about the correctness is because I find it interesting. Some others do not, and that's fine. There's zero malice in my corrections. I just like to help those who might be interested in learning the finer details, and even more importantly I learn myself at the same. Everyone is free to opt out if they find it annoying.

[Mauriès Robert]

Hi SpAce,

But no need to thank for mine (even though I thought I mostly defended your point of view on krakens)? Have I offended you? You've avoided responding to my comments lately. (I'd be particularly interested in your thoughts on what I said about deadly patterns and proving uniqueness, as you've been mentioning it as a reason to avoid them.)

No, no problem with you, no desire not to answer you, but all this takes a lot of time for me. I'm trying to do the right thing.
I have seen that you are defending my point of view on Kraken and I thank you for that, just as I thank you for all our exchanges since the beginning of my presence at this forum.
Concerning the notations, I understood well the interest of indicating the memory marker by an asterisk or another symbol, as I understood the one to indicate the strong and weak links, but I think I would stay on my way, not that I don't want to learn, but because I am resistant to the multiplication of conventions and definitions: the less we have and the better it is for me. I therefore defend my conception of things with TDP which is, I recognize, more of a visual method with colour markings (complex chains) whose written transcription is not appropriate.
With regard to deadly patterns, as you know, I think they should not be used because you have to demonstrate the uniqueness or unsolvable nature of the puzzle and not accept them, but I understand that others like you do not have that opinion. However, I recognize that if they are used, resolutions can be faster and you have proven this with the qiuyanzhe puzzle.
In this case, you used the aspect (non-solution) of the BUG-lite. For me, this means establishing contradictions (empty cells), which we do very well with TDP but I avoid using the contradiction as much as possible on this forum because I understood that it was not well seen.

Your notation is more verbose, yet it communicates much less, even with attached images and diagrams (which it really requires to be understandable at all). How is that a good thing? Even a mediocre Eureka user can read and write detailed pieces of logic way faster and more accurately than an expert in TDP, and the logic can even be followed without seeing the related grid. The only advantage of the TDP notation is that it's indeed simpler, but that simplicity comes at a cost that no expert player who's already learned better tools wants to pay.

Dans une phrase comme celle-ci, je ne compte pas moins de 6 symboles à connaître : (), =, -, (,), b, p
(2)r9c4 = (2,5)r7c42 - r8c13 = (59)b9p68 - (91)r6c85 = (1,8)r9c56 - r345c6 = (835)b2p8214,(8)r9c6 => -58 r9c4;
Je ne vois pas où est la simplicité, alors que moi je me contente de -> | et ----, très visuels
With kind regards
Robert

[SpAce]

Hi Robert,

No, no problem with you, no desire not to answer you, but all this takes a lot of time for me.

Ok, glad to hear that!

Dans une phrase comme celle-ci, je ne compte pas moins de 6 symboles à connaître : (), =, -, (,), b, p
(2)r9c4 = (2,5)r7c42 - r8c13 = (59)b9p68 - (91)r6c85 = (1,8)r9c56 - r345c6 = (835)b2p8214,(8)r9c6 => -58 r9c4;
Je ne vois pas où est la simplicité, alors que moi je me contente de -> | et ----, très visuelst

Note that the above part was not translated, but here's what Google gives:

In a sentence like this, I have no less than 6 symbols to know: (), =, -, (,), b, p
(2) r9c4 = (2,5) r7c42 - r8c13 = (59) b9p68 - (91) r6c85 = (1,8) r9c56 - r345c6 = (835) b2p8214, (8) r9c6 => -58 r9c4;
I don't see where the simplicity is, whereas I am content with -> | and ----, very visual

I thought I said exactly that -- your notation is clearly simpler and thus easier to learn. It's also much less expressive and slower to read for someone who understands both. That's the trade-off.

You may not see a reason to learn Eureka, but it's just as certain that someone who already knows Eureka well has absolutely no reason to switch to your style. It's like someone who can program in C++ or Java would probably not be interested in switching to Basic. More powerful tools often have a steeper learning curve, but the investment is usually worth it.

PS. My chains, especially ones like the above, aren't really a fair comparison anyway. I regularly use the most complex and controversial language features to push the envelope. Thus my chains are not even meant to be the easiest to understand, because I have different goals. If someone's interested, though, I can provide simpler translations.