It is currently Thu Oct 19, 2017 5:55 am

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
Offline
 Post subject: Re: Go problems don't bring any result?
Post #81 Posted: Mon Dec 19, 2016 3:38 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
RobertJasiek wrote:
Wha exactly is the chunk, what does it consist of, what reading is part of it and how is the problem solved if just referencing to the chunk? What is the difference to regular reading with reference to known positions and what, if any, is the time advantage?

Sadly, it depends ...
The experience of the player in question plays an important role, the individual way of thinking is another parameter.

I do not have read your book, so I would like to assume that "regular reading" describes a METHOD (for solving problems, but not restricted to tsume-go) that is based on the RESULTs of CHUNKING (/ SHAPE ANALYSIS = i.e your "known positions").
In my opinion, "chunking" / "shape analysis" is the answer to your un-defined terms "obvious" / "non-obvious".

+ + + + + +

Let me try to explain a bit deeper ...

Regarding the last problem in this thread, I was very fascinated by Bill's explanation using "halve eyes", a term that does not exist in "my" world / terminology. However, this is a good example of showing the benefit of letting a player develop their OWN "rules" (on the basis of working through a lot of exemplary cases).

Based on these elements of the problem ...

Click Here To Show Diagram Code
[go]$$Bm9 Not yet connected
$$ -------------------------------
$$ . . . . O . X X . O . . P . . .
$$ . . . X O O . O O O O P X . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]

Click Here To Show Diagram Code
[go]$$Bm9 Line of (potential) false eye
$$ -------------------------------
$$ . . . . O . X X . O . M O . . .
$$ . . . X O O . O O O O O Z . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]

... Bill "chunked" ...

Click Here To Show Diagram Code
[go]$$Bm9 A half eye (1)
$$ -------------------------------
$$ . . . . O . X X . O C . O . . .
$$ . . . X O O . O O O O O X . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]


... "half an eye" that -- if I remember correct -- is used by Bill in other contexts as well, while ...

Click Here To Show Diagram Code
[go]$$Bm9 A defect (d) in White's encirclement
$$ -------------------------------
$$ . . . . O . X X . O . d O . . .
$$ . . . X O O . O O O O O X . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]

... my chunk was a "defect" in White's encirclement (with "defect" also used in other contexts).

But what is the difference in thinking ?

Bill: "There is only half an eye at the right, because Black can exploit White's defect in her encirclement."
Cassandra: "There is a defect in White's encirclement that can be exploited by Black, so there is no sure eye for White."

In principle, the result is equivalent.
If we go a bit further, we realise that ...

Click Here To Show Diagram Code
[go]$$Bm9 A half eye (2)
$$ -------------------------------
$$ . . . . O . X X . O C . . . . .
$$ . . . X O O . O O O O O X . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]

... -- for Bill -- the "open" position is the same case as the one shown before (apparently, he already knows what a throw-in serves for), while ...

Click Here To Show Diagram Code
[go]$$Bm9 A hole (h) in White's encirclement
$$ -------------------------------
$$ . . . . O . X X . O . h . . . .
$$ . . . X O O . O O O O O X . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]

... it is a slightly different case in "my" world. "My" differentiation between "hole" and "defect" serves those players who have not yet reached Bill's state of knowledge and also might have difficulties with sacrificing stones (necessary for playing a throw-in).

Adapted to the individual mindset, Bill "sees" halve eyes, while I "see" defects / holes (and also "potential" eyes, with potential having a broader / other meaning than "half").
No one of us is forced to adopt / utilise a way of thinking that would be "unusual" for him, resulting in unnecessary thinking efforts. However, we come to an identical conclusion.

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #82 Posted: Mon Dec 19, 2016 4:59 am 
Tengen

Posts: 4452
Liked others: 0
Was liked: 589
OC, I have a rough idea of what chunking is in go and use it myself. No word / psychologic definition is needed; I am not asking for that. I also do not have a problem with some automatic processing within a chunk already known to the player or with everybody building and using his own chunks.

What I do have problems with is the pretence that using a particular chunk by a particular player would "automatically" contribute to finding "the" solution. It is very easy to use a chunk and pretend to oneself to have found the solution. However, in most cases I have observed by players / teachers showing or referring to a chunk, the usage lacks verification explaining why the solution is found. The major problem being the missing specification of interfaces between chunk, other used methods (such as reading) and the alleged solution. Showing some or all internal aspects of a chunk provides nothing about its interfaces to the other used parts of problem solving. In particular, in this thread, several messages have discussed some internal aspects of chunks but hardly anything about interfaces.

This is how to stay weak at problem solving. Deceive yourself about usage of a chunk already revealing the answer and reject any critical thinking about why usage is correct in the context of the other aspects of attempting to solve a particular problem.

To make chunking useful, correct understanding of their embedding in the overall process of problem solving is mandatory. Otherwise, chunking merely makes claims about a solution but does not verify whether a claim is correct.

Concerning the particular chunk on discussion, instead regular reading takes ca. 1/3s to 3s. Fast enough to call it "automatic". Since the subtree's regular reading is part of the whole regular reading, interface verification is not needed but given automatically. Not so for chunking. Even if the chunk itself is processed within 1/3s, how long does it need to formulate and verify the interface? We are at days of attempted descriptions now - I remain to be convinced that embedded use of the chunk is done within 3s or faster, especially since every player might use his own variant of a chunk.

Regular reading is a method described.

In its current description, regular reading does not rely on the results of chunking. It may use preliminary, known, thereby terminal positions with their known statuses so as not to read the deeper subtrees again. (You might call this chunking, but it is not chunking in general; it is only the specific kind of preliminary, known, thereby terminal positions. I would also not call this shape analysis but, if you wanted, it would only be the specific kind of preliminary, known, thereby terminal positions.)

"obvious" versus "non-obvious" need not be defined because everything with doubt is simply treated as non-obvious without bothering for a definition. Therefore, chunking or shapes are not needed to distinguish obvious from non-obvious. They may, but need not, be used for a distinction, but if related thinking becomes complicated, this is having doubts and we simply assess "non-obvious".

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #83 Posted: Mon Dec 19, 2016 6:02 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
RobertJasiek wrote:
What I do have problems with is the pretence that using a particular chunk by a particular player would "automatically" contribute to finding "the" solution.


Who said that?

Quote:
This is how to stay weak at problem solving.


Chunking is just the opposite. As the psychological research indicates.

Quote:
Deceive yourself about usage of a chunk already revealing the answer and reject any critical thinking about why usage is correct in the context of the other aspects of attempting to solve a particular problem.


You are deceiving yourself, I am afraid.

Quote:
To make chunking useful, correct understanding of their embedding in the overall process of problem solving is mandatory. Otherwise, chunking merely makes claims about a solution but does not verify whether a claim is correct.


Actually, chunking is useful in verification.

Quote:
In its current description, regular reading does not rely on the results of chunking.


Mentally solving any sufficiently difficult problem requires chunking.

_________________
"Still on the right side of the grass."

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #84 Posted: Mon Dec 19, 2016 6:16 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
RobertJasiek wrote:
What I do have problems with is the pretence that using A PARTICULAR chunk by A PARTICULAR player would "AUTOMATICALLY" contribute to finding "THE" solution.

Who did claim that (emphasis mine) ?

In "Bill's" last problem, there are at least TWO chunks, one at the left (very likely identical to Bill and me), and another one at the right (slightly different to Bill and me).

Chunking serves the purpose of reducing the complexity of a problem by dividing it into (mostly; with regard to the purpose of analysis) independent sub-parts. As a matter of course, checking the validity for the current problem is mandatory.
There is NO need to waste time for thinking about "WHY" the usage of a special set of chunks really served solving the problem in question. Unless you want to "create" an even larger chunk for your future usage.

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #85 Posted: Mon Dec 19, 2016 6:39 am 
Tengen

Posts: 4452
Liked others: 0
Was liked: 589
Has the psychological research been for go problem solving using chunks?

How is chunking used for verification? For the moment, an answer for one problem would be good enough.

If chunking shall divide a problem into subproblems, then please explain this (for one problem would be good enough a start). So far, demonstrations of chunks used for a problem have NOT been a division of the problem into chunks but there is more to solving the problem (such as an interface in between two chunks, assumptions for using the chunks, interface between a chunk and the solution, repeated use of a chunk in different variations of reading etc).

Since checking the validity for the current problem is mandatory, where is the validity check for using the chunks in the current problem? Being mandatory, it is not a waste of time.

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #86 Posted: Mon Dec 19, 2016 6:40 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
RobertJasiek wrote:
... especially since every player might use his own variant of a chunk.

Where is the problem with individually different sets of chunks ?

In the end, Bill's solution sequence was identical to mine.

Bill is a Dan player, I am only a strong SDK. Therefore, it is natural (as could be seen in my "shape analysis" explanations above) that Bill's chunks are "larger" than mine. Very likely, Bill will be faster with solving a particular problem, just because he has fewer chunks to manage than I have to combine.

And also, there will be players (independent of their strength; even weaker Kyu players) who feel Bill's special chunk about "halve eyes" to be very near to their state of thinking. And they will like to use it.

Other players might feel more comfortable with my more detailled kind of "shape analysis".

+ + + + + +

In my experience, the main weakness that can be encountered in the field of tsume-go is "the art of identifying the vital spot(s)", but not "the art of reading".

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #87 Posted: Mon Dec 19, 2016 6:45 am 
Tengen

Posts: 4452
Liked others: 0
Was liked: 589
As I have said, it is NOT a principle problem that different players use different chunks.

EDIT:

But from the possibility of different players using different chunks follows that demonstrations need a) much abstraction to then be applicable by different players or b) explanations for usage by one particular player presented in a manner so that everybody else can construct and derive application for different chunks and usage details.

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #88 Posted: Mon Dec 19, 2016 7:25 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
More on chunking. :)

I have seen this in an actual game. The setup may not be exactly what it was in the game, but the play is.

Click Here To Show Diagram Code
[go]$$W Kill! Oops!
$$ ---------------------
$$ | . . X 2 1 . . . . .
$$ | X X . 3 4 O . . . .
$$ | O O X X X O . . . .
$$ | . . O . O X O . . ,
$$ | . O . . O . . . . .
$$ | . . . . . . . . . .
$$ | . . . . . . . . . .[/go]


It looks like White had learned the sequence, :w1: - :b2:, :w3:, as a killing sequence, from a well known problem that is similar to this setup. However, he failed to recognize the crucial difference between the two positions, namely the extra dame for the three Black stones.

:w1: - :b2:, :w3: is, OC, a chunk. But, as RJ might point out, White failed to verify that it works in this case. As I have said, chunking occurs automatically, and my suspicion is that White learned this chunk automatically, and, as a result, incorrectly. In the problem Black cannot play :b4: because of damezumari. The three stones have at that point only 2 dame. White should have learned the dame count as part of the chunk. Learning that kind of thing is not all that likely to happen with automatic chunking, which is why I talk about chunking in the context of sub-problems and subgoals, and why I talk about understanding.

BTW, the extra dame is what psychologists call a just noticeable difference (JND). If you use flashcards for training, I recommend making flashcards with JNDs from the original problem or position, to avoid making the kind of mistake in a real game that White made.

_________________
"Still on the right side of the grass."


Last edited by Bill Spight on Mon Dec 19, 2016 8:17 am, edited 1 time in total.
Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #89 Posted: Mon Dec 19, 2016 7:58 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
Cassandra wrote:
And also, there will be players (independent of their strength; even weaker Kyu players) who feel Bill's special chunk about "halve eyes" to be very near to their state of thinking. And they will like to use it.


BTW, there is nothing special about half eyes. They have been part of the go literature for many years. More recently, although more than 20 years ago, Howard Landman discovered other eye values. See http://www.polyamory.org/~howard/Go/Eyespace.ps or "Eyespace values in go" in Games of No Chance.

Quote:
Bill is a Dan player, I am only a strong SDK. Therefore, it is natural (as could be seen in my "shape analysis" explanations above) that Bill's chunks are "larger" than mine. Very likely, Bill will be faster with solving a particular problem, just because he has fewer chunks to manage than I have to combine.


Or vice versa, given your research into tsumego. :)

Click Here To Show Diagram Code
[go]$$B Black to play and kill
$$ -------------------------------
$$ . . . . O . 1 . . . . . . . . .
$$ . . . X O O . O O O . . B . . .
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]


My feeling is, if this position occurred in a game between you and me, we would stop local play after :b1:, without giving it much thought. The :bc: stone is just too close for White to live.

Quote:
In my experience, the main weakness that can be encountered in the field of tsume-go is "the art of identifying the vital spot(s)", but not "the art of reading".


My impression is that, as life and death problems become more difficult, damezumari looms larger. What do you think?

_________________
"Still on the right side of the grass."

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #90 Posted: Mon Dec 19, 2016 8:09 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
RobertJasiek wrote:
How is chunking used for verification?


Verifying a solution means that for each play by the solver, an answer must be found for every possible reply by the opponent. That means that verification may well be a sufficiently large problem in itself that will require chunking.

_________________
"Still on the right side of the grass."

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #91 Posted: Mon Dec 19, 2016 8:12 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
Dear Bill,

Bill Spight wrote:
As I have said, chunking occurs automatically, and my suspicion is that White learned this chunk automatically, and, as a result, incorrectly.

Perhaps your conclusion is a bit over-hasty ?

Quote:
In the problem Black cannot play :b4: because of damezumari. The three stones have at that point only 2 dame.

This is undoubtedly correct. However, ...

Quote:
White should have learned the dame count as part of the chunk.

... how could White have gained this knowledge in the absense of further examples (for study) ?

Quote:
Learning that kind of thing is not all that likely to happen with automatic chunking, which is why I talk about chunking in the context of sub-problems and subgoals, and why I talk about understanding.

Again, this is undoubtedly correct. Repetition matters !!!
E.g.

Click Here To Show Diagram Code
[go]$$B Zero liberties
$$ --------------------
$$ | O . . . O X . . .
$$ | O . O O O X . . .
$$ | O O O X X X . . .
$$ | X X X X . . . . .
$$ | . . . . . . . . .[/go]

vs.
Click Here To Show Diagram Code
[go]$$B Zero liberties
$$ ------------------
$$ | . . . O X . . .
$$ | . O O O X . . .
$$ | O O X X X . . .
$$ | X X X . . . . .
$$ | . . . . . . . .[/go]

Click Here To Show Diagram Code
[go]$$B One liberty
$$ ------------------
$$ | . . . O . . . .
$$ | . O O O X . X .
$$ | O O X X X . . .
$$ | X X X . . . . .
$$ | . . . . . . . .[/go]

Click Here To Show Diagram Code
[go]$$B Two liberties
$$ ------------------
$$ | . . . O . . . .
$$ | . O O O X . X .
$$ | O O X X X . . .
$$ | . X X . . . . .
$$ | . . . . . . . .
$$ | . X . . . . . .
$$ | . . . . . . . .[/go]


Quote:
BTW, the extra dame is what psychologists call a just noticeable difference (JND). If you use flashcards for training, I recommend making flashcards with JNDs from the original problem or position, to avoid making the kind of mistake that White made in a real game.

Good idea. Its application could be extended to cases, where several stones that are in atari (or could be put in atari) are only on the tsume-go board to bedazzle your mind ;-)

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)


Last edited by Cassandra on Mon Dec 19, 2016 8:24 am, edited 1 time in total.
Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #92 Posted: Mon Dec 19, 2016 8:21 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
Accidental duplicate. :oops:

This space left intentionally blank. ;)

_________________
"Still on the right side of the grass."


Last edited by Bill Spight on Mon Dec 19, 2016 8:28 am, edited 1 time in total.
Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #93 Posted: Mon Dec 19, 2016 8:22 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
Bill Spight wrote:
Or vice versa, given your research into tsumego. :)

OK, "chunking" / "shape analysis" matures over time :)

Quote:
Click Here To Show Diagram Code
[go]$$B Black to play and kill
$$ -------------------------------
$$ . . . . O . 1 . . . . . . . . .
$$ . . . X O O . O O O . . B . ? ?
$$ . . X . X O O X O X . X . . . .
$$ . . . . X X X X X X . . X . . .
$$ . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . .[/go]

My feeling is, if this position occurred in a game between you and me, we would stop local play after :b1:, without giving it much thought. The :bc: stone is just too close for White to live.

Probably White might want to establish one of her stones in the shadowed area ?
;-)

Quote:
My impression is that, as life and death problems become more difficult, damezumari looms larger. What do you think?

Yes, indeed. Damezumari is one of the somewhat "problematic" issues, because it depends on the visualisation of stones that will be played in the future.
The "under-the-stones"-issue is another one, as is sacrifycing own stones for spoiling your opponent's shape.

I think that tsume-go usually are considered to be "more difficult", the larger the potential eye space and the "more open" the position is.

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #94 Posted: Mon Dec 19, 2016 8:34 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
RobertJasiek wrote:
But from the possibility of different players using different chunks follows that demonstrations need a) much abstraction to then be applicable by different players or b) explanations for usage by one particular player presented in a manner so that everybody else can construct and derive application for different chunks and usage details.

I do not consider a) being the "best" kind of presentation.

I like b) more. Supply the student with a lot of suitable examples and let him / her derive their own "rules".
Every "rule" has its exeptions, and it will benefit the student to know THEIR exceptions for THEIR "rules".

However, creating this set of examples might be very time-consuming, boring and exhaustive for the author ;-)

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #95 Posted: Mon Dec 19, 2016 8:38 am 
Tengen

Posts: 4452
Liked others: 0
Was liked: 589
Bill Spight wrote:
Verifying a solution means that for each play by the solver, an answer must be found for every possible reply by the opponent.


No. Such would be the brute force verification. Verifications can be much lighter.

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #96 Posted: Mon Dec 19, 2016 8:41 am 
Tengen

Posts: 4452
Liked others: 0
Was liked: 589
Cassandra wrote:
creating this set of examples might be very time-consuming, boring and exhaustive for the author


I know. Therefore you do not supply some with sufficient details yet. Random hint:

Click Here To Show Diagram Code
[go]$$W
$$ -----------------------------------
$$ . . . . O . X X . O . X O 1 . . O .
$$ . . . X O O . O O O O O X . . . . O
$$ . . X . X O O X O X . X . . . . . .
$$ . . . . X X X X X X . . X . . . . .
$$ . . . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . . . .[/go]

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #97 Posted: Mon Dec 19, 2016 8:48 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
Cassandra wrote:
Dear Bill,

Bill Spight wrote:
As I have said, chunking occurs automatically, and my suspicion is that White learned this chunk automatically, and, as a result, incorrectly.

Perhaps your conclusion is a bit over-hasty ?

Quote:
In the problem Black cannot play :b4: because of damezumari. The three stones have at that point only 2 dame.

This is undoubtedly correct. However, ...

Quote:
White should have learned the dame count as part of the chunk.

... how could White have gained this knowledge in the absense of further examples (for study) ?


By asking why Black cannot play :b4: below, which would live. :)

Click Here To Show Diagram Code
[go]$$W Kill!
$$ ---------------------
$$ | . . X 2 1 . . . . .
$$ | X X . 3 4 O . . . .
$$ | O O X X X O . . . .
$$ | . . O O O O . . . ,
$$ | . O . . . . . . . .
$$ | . . . . . . . . . .
$$ | . . . . . . . . . .[/go]


Also, if the player already has the concept of a half eye, he could add this position to the collection of half eyes.

Click Here To Show Diagram Code
[go]$$W Half eye
$$ ---------------------
$$ | . . B B W . . . . .
$$ | X B . . . W . . . .
$$ | O W B B B W . . . .
$$ | . . W W W O . . . ,
$$ | . O . . . . . . . .
$$ | . . . . . . . . . .
$$ | . . . . . . . . . .[/go]


With a little thought he could add this position, as well. :)

Click Here To Show Diagram Code
[go]$$W Half eye
$$ ---------------------
$$ | . . B B W W . . . .
$$ | X B . . B W . . . .
$$ | O W B B . W . . . .
$$ | . . W W W O . . . ,
$$ | . O . . . . . . . .
$$ | . . . . . . . . . .
$$ | . . . . . . . . . .[/go]


This half eye frequently occurs in life and death problems. The key play to take away the potential eye is the same.

Click Here To Show Diagram Code
[go]$$W Half eye
$$ ---------------------
$$ | . . B B . W . . . .
$$ | X B . . . W . . . .
$$ | O W B B . W . . . .
$$ | . . W W W O . . . ,
$$ | . O . . . . . . . .
$$ | . . . . . . . . . .
$$ | . . . . . . . . . .[/go]


And here is another one. :D

Edit:

Click Here To Show Diagram Code
[go]$$W Half eye
$$ ---------------------
$$ | . . B . . W . . . .
$$ | X B . . B W . . . .
$$ | O W B B . W . . . .
$$ | . . W W W O . . . ,
$$ | . O . . . . . . . .
$$ | . . . . . . . . . .
$$ | . . . . . . . . . .[/go]


And another one. :)

_________________
"Still on the right side of the grass."


Last edited by Bill Spight on Mon Dec 19, 2016 9:06 am, edited 2 times in total.
Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #98 Posted: Mon Dec 19, 2016 8:49 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
RobertJasiek wrote:
Bill Spight wrote:
Verifying a solution means that for each play by the solver, an answer must be found for every possible reply by the opponent.


No. Such would be the brute force verification. Verifications can be much lighter.


One of the things that makes it lighter is the utilization of chunks. :)

_________________
"Still on the right side of the grass."

Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #99 Posted: Mon Dec 19, 2016 8:54 am 
Judan

Posts: 6393
Liked others: 1502
Was liked: 2397
RobertJasiek wrote:
Cassandra wrote:
creating this set of examples might be very time-consuming, boring and exhaustive for the author


I know. Therefore you do not supply some with sufficient details yet. Random hint:

Click Here To Show Diagram Code
[go]$$W
$$ -----------------------------------
$$ . . . . O . X X . O C B O 1 . . O .
$$ . . . X O O . O O O O O X . . . . O
$$ . . X . X O O X O X . X . . . . . .
$$ . . . . X X X X X X . . X . . . . .
$$ . . . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . . . .[/go]


That's from a different problem. :)

But 1) it does not invalidate the assertion that :bc: takes away the distinct eye at :ec:, and 2) it gives me the excuse to do what I had in mind, which was to show continuations after :b9: in the main line. :)

Click Here To Show Diagram Code
[go]$$Wm10 Continuation
$$ -----------------------------------
$$ . . . . O . X X . O . X O 1 3 . . .
$$ . . . X O O . O O O O O X 2 . . . .
$$ . . X . X O O X O X . X . . . . . .
$$ . . . . X X X X X X . . X . . . . .
$$ . . . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . . . .[/go]


White has a "ladder".

Click Here To Show Diagram Code
[go]$$Wm10 Net
$$ -----------------------------------
$$ . . . . O . X X . O . X O 1 3 . . .
$$ . . . X O O . O O O O O X 2 . 4 . .
$$ . . X . X O O X O X . X . . . . . .
$$ . . . . X X X X X X . . X . . . . .
$$ . . . . . . . . . . . . . . . . . .
$$ . . . . . . . . . . . . . . . . . .[/go]


Or a net. :)

_________________
"Still on the right side of the grass."


Last edited by Bill Spight on Mon Dec 19, 2016 9:04 am, edited 1 time in total.
Top
 Profile  
 
Offline
 Post subject: Re: Go problems don't bring any result?
Post #100 Posted: Mon Dec 19, 2016 8:55 am 
Lives in sente
User avatar

Posts: 705
Liked others: 6
Was liked: 90
Rank: German 1 Kyu
Bill Spight wrote:
And another one. :)

As I already wrote, your chunks are larger than mine :)

BTW. Your "half-eye"-problems are a beautiful confirmation that my idea "let players derive their own rules" has some merits.

_________________
The really most difficult Go problem ever: http://igohatsuyoron120.de/index.htm
Igo Hatsuyoron #120 (still unresolved by professionals, maybe solved by three amateurs)

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group