June 25, 2020

Post puzzles for others to solve here.

Re: June 25, 2020

Postby SpAce » Sun Jun 28, 2020 3:53 am

rjamil wrote:I think, yzfwsf gives enough visual material with one line explanations that will clear the picture.

Let me study all aspects of BUG+n from just 4-5 examples and try to convert in to generic exemplars form.

yzfwsf's examples are great, but at least so far they haven't helped to fix your fundamental mistake. You should finally start listening to us. Ever since the previous discussion, yzfwsf has been saying the same exact thing as I: only one of the GUARDIAN CANDIDATES (i.e. guardians) is guaranteed to be true. NOTHING ELSE is guaranteed, ever, so your logic can't depend on anything else. Yet you seem to think otherwise.

You should forget everything about guardian cells and guardian digits and focus only on the individual guardian candidates. Absolutely NOTHING is guaranteed about the guardian cells or the guardian digits. You're consistently wrong when you assume such nonsense.

You can't fix this until you accept the simple fundamental truth that both I and yzfwsf have been trying to teach you since the beginning. What exactly is so impossible in it that you choose to consistently ignore it and go back to your nonsense-logic every single time??? Don't you understand what we're saying, or don't you trust that we are right? I really, really hope it's not the latter reason.

This is the simple fundamental truth:

yzfwsf wrote:Only one of all the guardians in all guardian cells must be true, not one of guardians in each guardians cell.Say bug+6, 6 guardians in 3 cells ,only 1 of 6 must be true, not 3 of 6 are true

(Just to be clear: it's possible that more than one guardian is true, but there's no guarantee of that, and it makes no difference to the elimination logic anyway.)
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Re: June 25, 2020

Postby SpAce » Sun Jun 28, 2020 4:15 am

SteveG48 wrote:I think that works. As you say, it's pretty complicated. Maybe this is a case where simple words would do best.

Words? I don't see any reason for such desperate measures. A complicated AIC may not be the best solution here, but I still wouldn't give up symbolic notation. Personally I'd probably write it like this:

(9,8)r12c1 -> BUG => -(9,8)r12c1; stte

...or directly:

(9,8)r12c1 -> BUG => +(8,9)r12c1; stte

The immediately resulting 14-cell BUG is so obvious if (9,8)r12c1 is assumed that I don't think any complicated chains are needed to show the details.
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Re: June 25, 2020

Postby Cenoman » Sun Jun 28, 2020 2:36 pm

Hi Steve and SpAce,
I felt a bit upset with my faulty BUG-lite, yesterday. So back to the BUG or DP search.

As I said in my message to rjamil, I consider that, by definition, the pattern BUG+n encompasses all not solved cells in a puzzle. That said, there is only one choice for the guardian in row 2: 9r2c7, as there are three 9s in row 2 (and not three 8s). Now, if you consider the following 14 unsolved cells, and try to find a BUG configuration, you find one, with 8r2c7, 9r1c79 as guardians.
Code: Select all
 
 --------------+-------------------+
     4    7    |  38+9  1    38+9  |
     29   6    |  29+8  7    5     |
     29   8    |  4     6    29    |
 --------------+-------------------+
     3    9    |  6     5    1     |
     7    1    |  89    89   4     |
     6    5    |  23    23   7     |
 --------------+-------------------+
     8    4    |  7     39   39    |
     5    2    |  1     4    6     |
     1    3    |  5     28   28    |
 --------------+-------------------+

14 unsolved cells out of 16, how would you call that ?
To me, it's a BUG-lite+3 !
(9)r1c79 == (8)r2c7 - (8=39)r17c9 => -9 r3c9; ste or any other chain you'd prefer.
No need of other words than "BUG-lite"

Now, consider
Code: Select all
 --------------+-------------------+
     4    7    |  389   1    389   |
     29   6    |  29+8  7    5     |
     29   8    |  4     6    29    |
 --------------+-------------------+
     3    9    |  6     5    1     |
     7    1    |  89    89   4     |
     6    5    |  23    23   7     |
 --------------+-------------------+
     8    4    |  7     39   39    |
     5    2    |  1     4    6     |
     1    3    |  5     28   28    |
 --------------+-------------------+

Not a BUG because of non bivalue cells r1c79.
(29)b3p69 has two possible arrangements in the potential DP:
(2,9)b3p6,9 =>(3)r6c7&r7c9 => b3 void of 3
(9,2)b3p6,9 =>(8)r5c7&r9c9 => b3 void of 8
It's a DP with no solution and a single guardian:
=> +8r2c7; ste
Cenoman
Cenoman
 
Posts: 2975
Joined: 21 November 2016
Location: France

Re: June 25, 2020

Postby SteveG48 » Sun Jun 28, 2020 3:31 pm

SpAce wrote:Words? I don't see any reason for such desperate measures. A complicated AIC may not be the best solution here, but I still wouldn't give up symbolic notation. Personally I'd probably write it like this:

(9,8)r12c1 -> BUG => -(9,8)r12c1; stte

...or directly:

(9,8)r12c1 -> BUG => +(8,9)r12c1; stte

The immediately resulting 14-cell BUG is so obvious if (9,8)r12c1 is assumed that I don't think any complicated chains are needed to show the details.


Agreed. I like the second one, which is what my "words" would have said.
Steve
User avatar
SteveG48
2019 Supporter
 
Posts: 4481
Joined: 08 November 2013
Location: Orlando, Florida

Re: June 25, 2020

Postby SpAce » Mon Jun 29, 2020 12:30 pm

Hi Cenoman,

Cenoman wrote:I felt a bit upset with my faulty BUG-lite, yesterday. So back to the BUG or DP search.

That's why I love mistakes -- both mine and others'! They're wonderful because they often lead to new discoveries and better understanding. Here too! I'm glad you didn't give up, because you actually found the simplest solution to the dilemma we had. Thanks for that! Failing to see it was my mistake.

Now, if you consider the following 14 unsolved cells, and try to find a BUG configuration, you find one, with 8r2c7, 9r1c79 as guardians.
...
14 unsolved cells out of 16, how would you call that ?
To me, it's a BUG-lite+3 !
(9)r1c79 == (8)r2c7 - (8=39)r17c9 => -9 r3c9; ste or any other chain you'd prefer.
No need of other words than "BUG-lite"

Indeed! No need to go through the complicated 'implied BUG' route I suggested. Thus, the only fix Steve's solution needed was:

8r2c7 =BUG-Lite+3= 9r1c79 - (9=8)r1c1 => -8 r2c1 ; stte

Why didn't I think that??? Well, let me at least suggest an even simpler way to write the solution:

Code: Select all
.-------------.-----------.-----------------.
| a#8-9  2  6 | 5  4    7 | 38+9  1    38+9 |
| a#9-8  1  4 | 3  29+  6 | 29+8  7    5    |
|  5     3  7 | 1  29+  8 | 4     6    29+  |
:-------------+-----------+-----------------:
|  4     7  2 | 8  3    9 | 6     5    1    |
|  3     6  5 | 2  7    1 | 89+   89+  4    |
|  1     9  8 | 4  6    5 | 23+   23+  7    |
:-------------+-----------+-----------------:
|  2     5  1 | 6  8    4 | 7     39+  39+  |
|  7     8  3 | 9  5    2 | 1     4    6    |
|  6     4  9 | 7  1    3 | 5     28+  28+  |
'-------------'-----------'-----------------'

BUG-Lite+3 (c5789) using #externals

(8)r1c1 == (9)r2c1 => -8 r2c1, -9 r1c1; stte

Would you all agree with that?

Now, consider
...
Not a BUG because of non bivalue cells r1c79.
(29)b3p69 has two possible arrangements in the potential DP:
(2,9)b3p6,9 =>(3)r6c7&r7c9 => b3 void of 3
(9,2)b3p6,9 =>(8)r5c7&r9c9 => b3 void of 8
It's a DP with no solution and a single guardian:
=> +8r2c7; ste

That works too. It's quite elegant logic, though hard to express without words.

Cenoman, I think we can all agree that you have officially redeemed yourself, and very nicely at that! :D Let me also assure you that you could afford quite a few more and much bigger mistakes before anyone would even begin to doubt your mastery of DPs. That said, don't be afraid of making them if they lead to improvements like this! (In general, people should be less fearful of mistakes. They're often needed for any evolution to happen, or at least the fastest route to it.)

And Steve, thank you for the most interesting solution! I think we all learned something from it.
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Re: June 25, 2020

Postby SpAce » Mon Jun 29, 2020 1:55 pm

Steve, this is mainly for you (and anyone interested in notational details). While trying to put Cenoman's latter DP solution into a chain format, rather unsuccessfully, I found a solution to another notational problem with which we've struggled in the past:

Code: Select all
(8)r2c7
||
(2,9)b3p49 - (2|9=3,3)r6c7,r7c9 - (3)r1c79 = !
||
(9,2)b3p49 - (9|2=8,8)r5c7,r9c9 - (8)b3p143 = !

=> +8 r2c7; stte

Notice the two split nodes in the middle of the two chains. The correct but awkward way to write them used to be:

(2|9)r6c7,r7c9 = (3)r6c7&r7c9

as opposed to the enticing but ambiguous:

(2|9=3)r6c7&r7c9

Now I suggest this:

(2|9=3,3)r6c7,r7c9

That's not only correct but also short and readable! As you may have noticed, I recently started using that form in place of the 'r6c7&r6c9' notation in general (most recently in today's second solution), mainly because I try to avoid the unreadability of the '&' as much as possible. I didn't think of this problem then, but it seems to be a rather perfect fix for it too. What do you think? With the comma there's no problem with using the same digit twice (or more) within the same node.
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Re: June 25, 2020

Postby SteveG48 » Mon Jun 29, 2020 2:49 pm

SpAce wrote:Now I suggest this:

(2|9=3,3)r6c7,r7c9

That's not only correct but also short and readable! As you may have noticed, I recently started using that form in place of the 'r6c7&r6c9' notation in general (most recently in today's second solution), mainly because I try to avoid the unreadability of the '&' as much as possible. I didn't think of this problem then, but it seems to be a rather perfect fix for it too. What do you think? With the comma there's no problem with using the same digit twice (or more) within the same node.


That looks good, and is consistent with our use of the comma to indicate that candidates are assigned to cells in the same order that the cells are listed. I like it. My only problem, as usual, is that it's one more bit of specialized notation that newcomers will need to learn. Anyone who comes here and is interested in Boolean notation will know the meaning of | and &. Likewise, anyone interested in Sudoku had better get used to the special use of - and = . Beyond that, people will need to learn any notation that we add, and we still don't have a tutorial to point to.
Steve
User avatar
SteveG48
2019 Supporter
 
Posts: 4481
Joined: 08 November 2013
Location: Orlando, Florida

Re: June 25, 2020

Postby SpAce » Mon Jun 29, 2020 10:35 pm

SteveG48 wrote:That looks good, and is consistent with our use of the comma to indicate that candidates are assigned to cells in the same order that the cells are listed. I like it.

Great! By the way, I'm not sure if I've posted this before, but some time ago I finally found the comma reference I'd been searching for ages:

David P Bird wrote:The Boolean term (7,8)r2c6,r3c6 is true when cells occupied by the digits match according to their listing orders and false otherwise. I have no problems with this because I believe that within reason we should be able to use any True/False condition we want in a chain provided it's clear what's needed to make it true.

(Note: I edited out the superfluous 'HP' because I didn't want obsolete parts to distract from the main thing.)

So, I think we can consider the comma quite standard, after all, since it was advocated by David himself. I can't say I've seen it used much in the old chains, though. I remember one example from ronk, but that's about it. Yet I think we can all agree by now that it's actually quite useful. (Apparently David always used a comma between the cells too if it was used between the digits, but I've relaxed that rule. I only use it with the cells if it avoids ambiguity or improves readability (or if it's unavoidable).)

My only problem, as usual, is that it's one more bit of specialized notation that newcomers will need to learn. Anyone who comes here and is interested in Boolean notation will know the meaning of | and &.

Sure, but I think the comma is easier to figure out than most others. I've noticed that some players who've had trouble with '|' and '&' have surprisingly adopted the ',' and used it quite correctly. After all, the comma is a relatively standard separator in ordered tuples. Personally, I've also started using ',' in place of '&' in many cases just to improve readability. It's logically correct because a,b -> a&b (but not vice versa).

I think the biggest complexity with the three operators is when they're used between cells (or nodes) instead of (or in addition to) candidates within a node. I don't think those semantics have ever been clearly defined. I'm suggesting the following:

Code: Select all
(1&2)r45c2&r3c67 <-> 1r45c2 & 2r45c2 & 1r3c67 & 2r3c67

(1&2)r45c2,r3c67 <-> (1r45c2 | 1r3c67) & (2r45c2 | 2r3c67)

(1&2)r45c2|r3c67 <-> (1r45c2 & 2r45c2) | (1r3c67 & 2r3c67)


(1,2)r45c2&r3c67 <-> 1r4c2 & 2r5c2 & 1r3c6 & 2r3c7

(1,2)r45c2,r3c67 <-> 1r45c2 & 2r3c67

(1,2)r45c2|r3c67 <-> (1r4c2 & 2r5c2) | (1r3c6 & 2r3c7)


(1|2)r45c2&r3c67 <-> (1r45c2 | 2r45c2) & (1r3c67 | 2r3c67)

(1|2)r45c2,r3c67 <-> 1r45c2 | 1r3c67 | 2r45c2 | 2r3c67

(1|2)r45c2|r3c67 <-> 1r45c2 | 2r45c2 | 1r3c67 | 2r3c67 (same as above)

Would you agree with those? (1&2) is of course normally written (12) but I wanted to make it explicit for this.)

--
Edit. r67c3 -> r3c67 everywhere (thanks, Cenoman)
Last edited by SpAce on Wed Jul 01, 2020 6:23 pm, edited 1 time in total.
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Re: June 25, 2020

Postby Cenoman » Tue Jun 30, 2020 4:12 pm

SpAce wrote: I'm suggesting the following:

Hidden Text: Show
Code: Select all
(1&2)r45c2&r67c3 <-> 1r45c2 & 2r45c2 & 1r67c3 & 2r67c3

(1&2)r45c2,r67c3 <-> (1r45c2 | 1r67c3) & (2r45c2 | 2r67c3)

(1&2)r45c2|r67c3 <-> (1r45c2 & 2r45c2) | (1r67c3 & 2r67c3)


(1,2)r45c2&r67c3 <-> 1r4c2 & 2r5c2 & 1r6c3 & 2r7c3

(1,2)r45c2,r67c3 <-> 1r45c2 & 2r67c3

(1,2)r45c2|r67c3 <-> (1r4c2 & 2r5c2) | (1r6c3 & 2r7c3)


(1|2)r45c2&r67c3 <-> (1r45c2 | 2r45c2) & (1r67c3 | 2r67c3)

(1|2)r45c2,r67c3 <-> 1r45c2 | 1r67c3 | 2r45c2 | 2r67c3

(1|2)r45c2|r67c3 <-> 1r45c2 | 2r45c2 | 1r67c3 | 2r67c2 (same as above)

Would you agree with those? (1&2) is of course normally written (12) but I wanted to make it explicit for this.)

What is exacly the intention ? Comprehensively list the possible configurations of digits 1, 2 in four independent cells ? or list possible configurations in an actual case.
In the table above, r6c3 and r45c2 are in the same box 4 and cannot be allocated digits 1, 2 independently.
Code: Select all
   1  2  3
 +---------+
4|         |
5|         |
6|         |
 +---------+
7|         |
Cenoman
Cenoman
 
Posts: 2975
Joined: 21 November 2016
Location: France

Re: June 25, 2020

Postby SpAce » Tue Jun 30, 2020 5:07 pm

Hi Cenoman,

Cenoman wrote:What is exacly the intention ? Comprehensively list the possible configurations of digits 1, 2 in four independent cells ? or list possible configurations in an actual case.
In the table above, r6c3 and r45c2 are in the same box 4 and cannot be allocated digits 1, 2 independently.

Oops! Thanks for noticing! I must have meant r45c2 and r3c67. Does it work better with that? The two groups of cells weren't supposed to see each other. I was pretty tired when I wrote that. The idea was to list the 3x3 cases of using the three operators & , | for both candidates and cells.
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Re: June 25, 2020

Postby SpAce » Wed Jul 01, 2020 11:27 pm

Back to the semantics of those operators. I don't think we have any problem of understanding them in the context of digits. All of these are pretty clear:

Code: Select all
(12)  : 1 AND 2
(1&2) : 1 AND 2
(1,2) : 1 AND 2 (split and ordered in a split and ordered group of cells)
(1|2) : 1 OR  2

However, the semantics of the same operators applied to a group of cells is not so clear, especially without any attached digits:

Code: Select all
r1c12  : ?
r1c1&2 : r1c1 AND r1c2
r1c1|2 : r1c1 OR  r1c2
r1c1,2 : ?

The AND and OR operators are relatively straight-forward, at least with the previously suggested semantics, but the other two are not. What exactly does the comma mean here? Does it imply splitting and ordering or not? What exactly does the default case r1c12 mean? In the digit context we could always replace (12) with (1&2), but what operator is implied in r1c12?

The seemingly obvious r1c1&2 doesn't work as a synonym for r1c12 if we maintain that (1)r1c1&r1c2 should mean 1r1c1 & 1r1c2 (which is a contradiction). The other option r1c1|2 does work in this case, since (1)r1c12 -> 1r1c1|1r1c2. However, that interpretation runs into problems if we have more digits:

    (12)r1c1245 <-/-> (12)r1c12|45 <-/-> (12)r1c1|2|4|5
The first option means that both 1 AND 2 are found somewhere within those four cells (but obviously not in the same cell), e.g. 1r1c5 AND 2r1c1 is a valid combo. On the other hand, with my suggested semantics the second option is only valid with (12)r1c12 OR (12)r1c45 (in other words, both digits must be found in one or the other cell group -- or both but that's not possible in this case). The last option is not valid at all, because it represents four ORed single-cell groups, and (12) being two ANDed digits can't fit into a single cell.

So, if both & and | are out of the game, what would work? The only operator left is the comma, so it must be it. But what exactly does it mean in this context? To maintain any kind of consistency, I think it should imply splitting and ordering just like with the digits -- and it definitely does when used in combination with a comma in the digits. That's a bit of a problem because r1c12 does not imply any ordering, so r1c1,2 is not really a synonym for it. This is:

    r1c12 <-> (r1c1,2 | r1c2,1)
That's in line with the digit context:

    (12) <-> ((1,2) | (2,1))
However, unlike the digit context where (12) <-> (1&2), there actually isn't any single operator that could be used within r1c12 to get the exact same semantics. The comma is pretty close and works in most practical cases, but it's not a synonym because it's not commutative: r1c1,2 is not the same as r1c2,1. What I would like to have is a fully commutative operator for cell groups, similar to & with the candidates, for when splitting and ordering is not wanted. My suggestion is the dot '.' :

    r1c12 <-> r1c1.2 <-> r1c2.1 <-> (r1c1,2 | r1c2,1)
Now you're thinking that it doesn't make any sense, because why would we ever write r1c1.2 when we can write r1c12. You're right, we never would. However, the real need is for nodes with cells that don't see each other. Currently there's no way to write them with the same exact semantics of a seamless group like r1c12 (i.e. an unordered, unsplit group of cells). The only option to write them is with the comma r1c1,r9c9 but it's not exactly the same.

While the comma syntax almost always works in practice, it's not semantically accurate because it implies a split and ordered group of cells whether we want one or not. It can also cause actual problems when we do want a split and ordered group of cells (i.e. one or more commas are used with the attached digits) but not with that exact splitting point.

With the suggested dot syntax we wouldn't have such problems, because it wouldn't imply any ordering or splitting:

    r1c12.r9c89 <-> r9c89.r1c12 <-> r1c1.r1c2.r9c8.r9c9 <-> r9c8.r1c2.r9c9.r1c1 <-> ...
The dot could also be used in other contexts as a more readable replacement for '&' (with the exact same semantics, unlike the comma I've been using for that purpose). Thus we'd have these four operator options (and one default) for both digits and cells:

Digits:

  1. (12) : <-> (21) <-> (1.2) <-> (1&2)
  2. (1.2) : <-> (2.1) <-> (12)
  3. (1,2) : <-/-> (2,1) ; -> (12)
  4. (1&2) : <-> (2&1) <-> (1.2) <-> (12) <-> ((1,2) | (2,1))
  5. (1|2) : <-> (2|1)
(Of those, only a,c,e are really needed in practice, but b,d are there for symmetry and completeness.)

Cells:

  1. r1c12 : <-> r1c21 <-> r1c1.2 <-> {r1c1 r1c2} : unsplit, unordered set of cells
  2. r1c1.2 : <-> r1c2.1 <-> r1c1.r1c2 <-> r1c2.r1c1 <-> r1c12
  3. r1c1,2 : <-/-> r1c2,1 ; <-> (r1c1,r1c2) : split, ordered tuple of cells
  4. r1c1&2 : <-> r1c2&1 <-> (r1c1 & r1c2)
  5. r1c1|2 : <-> r1c2|1 <-> (r1c1 | r1c2)
All five of these options have their uses.

--

So, what do you guys think of that? I know Steve must really hate the idea of adding yet another symbol :D Sorry! I'm not really happy about it either, but I think it would make logical sense because there's an actual gap to fill. So, just a warning: I'll probably be testing the dot idea for a while to see how it works in practice.
User avatar
SpAce
 
Posts: 2671
Joined: 22 May 2017

Previous

Return to Puzzles