Page 6 of 8

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 1:28 am
by Cassandra
Sooner or later, Bill's "chunks" will be firmly anchored in the long term memory, including the specific analytic result.
This will largely reduce the amount of "reading" that has to be done in the working memory from current occasion.
The "workload" can be concentrated on combining already known chunks.

Some tiny complements ...
Bill Spight wrote:
Click Here To Show Diagram Code
[go]$$Bm9 A half eye (1)
$$ -------------------------------
$$ . . . . O . X X . O C . W . . .
$$ . . . 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]
The marked point is a half eye.
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]
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]
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]
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]
+ + + + + + + + + + + + +

About the development of "chunking" / "reading" ...
Click Here To Show Diagram Code
[go]$$B One-move problem
$$ -------------------------------
$$ . . . . O . X X . O . 1 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]
----------
Click Here To Show Diagram Code
[go]$$B Three-move problem (part 1)
$$ -------------------------------
$$ . . . . O . X X . O X 1 2 . . .
$$ . . . 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]
Click Here To Show Diagram Code
[go]$$B Three-move problem (part 2) = already known
$$ -------------------------------
$$ . . . . O . X X . O . 3 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]

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 2:25 am
by RobertJasiek
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?

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 2:58 am
by John Fairbairn
Whaexactlyisthechunkwhatdoesitconsistofwhatreaingispartofitandhowistheproblemsolvedifjustreferencingtothechunkwhatisthedifferencetoregularreadingwithreferencetonownpositionsandwhatifanyisthetimeadvantage
What exactly is a word, what does it consist of, what sentence is it part of, and how is the sentence read if just referencing the words? What is the difference compared to reading with reference to known letters and what, if any is the time advantage?

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 3:06 am
by Bill Spight
Cher Robert,

If you wish to know more about chunking, there is a good bit about it in the psychological literature. The original article about it appeared in the 1950s, I think. Suppose that you set up this problem for a rank beginner and then showed him the main line solution. Then you removed the played stones and asked him to recreate the main line. The odds are good that he could not do it, because 9 moves is too much to hold in short term memory. It is also too much to hold in working memory, with some exceptions. But it is possible to combine parts of the sequence into a small number of chunks, which are not too much for working memory. Chunking happens automatically, so a player with some experience might be able to repeat the sequence, making use of already learned chunks, even if the problem is too hard for him.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 3:07 am
by Bill Spight
John Fairbairn wrote:
Whaexactlyisthechunkwhatdoesitconsistofwhatreaingispartofitandhowistheproblemsolvedifjustreferencingtothechunkwhatisthedifferencetoregularreadingwithreferencetonownpositionsandwhatifanyisthetimeadvantage
What exactly is a word, what does it consist of, what sentence is it part of, and how is the sentence read if just referencing the words? What is the difference compared to reading with reference to known letters and what, if any is the time advantage?
A nose by any other name would smell as sweet. :D

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 3:38 am
by Cassandra
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.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 4:59 am
by RobertJasiek
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".

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 6:02 am
by Bill Spight
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?
This is how to stay weak at problem solving.
Chunking is just the opposite. As the psychological research indicates.
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.
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.
In its current description, regular reading does not rely on the results of chunking.
Mentally solving any sufficiently difficult problem requires chunking.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 6:16 am
by Cassandra
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.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 6:39 am
by RobertJasiek
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.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 6:40 am
by Cassandra
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".

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 6:45 am
by RobertJasiek
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.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 7:25 am
by Bill Spight
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.

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 7:58 am
by Bill Spight
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.
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.
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?

Re: Go problems don't bring any result?

Posted: Mon Dec 19, 2016 8:09 am
by Bill Spight
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.