computer-go: Human thinking

[Heikki Levanto <heikki@xxxxxx>]

Don Dailey <drd@xxxxxxxxxxxxxxxxx> wrote:

> I've  always  been  struck by  how  much  language,  whether  human or
> computer affects the way we think.  We all carry on internal dialogues
> with ourselves (talking to  ourselves) and as far  as I know we all do
> it in some language we are familiar with.  There are certain things we
> are aware of (feelings and moods) that  we don't always "verbalize" so
> we apparantly don't absolutely need a  highly structured language, but
> it seems to help a lot.  I can't imagine reasoning something out in my
> mind without verbalizing it internally.

This is getting to the edge of topicality on this list, but I can not help
adding a few comments to this.

I can think of lots of situations where my thinking is not "verbalized" in a
high-level language. Music is one example where I do not *have* such
language, and yet I can think of a piece and how to play it. Another happens
occasionally in playing go. I know when I read ladders, I verbalize
"black-white-black-white", or more often "run-block-run-block". Yet I also
"see" the liberties and other features of the situation. Even more extreme
examples happen in relatively quick games where I may spend some time
looking at a group, decide not to do anything about it, and "just" bang a
stone in some other location on the board. No "thinkig aloud" that I am
aware of was spent on deciding where to play the stone...

Ok, to be more on topic, a quick reply to the programming language
discussion. You wrote:

> Any of us  who use many   computer languages probably  realize that we
> might  approach problems  differently  if we  use different languages.
> The language encourages us down certain pathways.  A simple example of
> this is that I tend to use associative arrays more if I am programming
> in perl.  

Again, I think it goes deeper than this. If you program in C, and happen to
have a reasonably good associative array in your go-toolkit, you tend to use
it more often than if you have to write it yourself. Maybe not quite as
often as you would in perl, where associative arrays are part of the very
being of the language - and are often used to work around some other
limitations of the language, for example in place of structures, classes,
and objects.  (no, let's not start a flame war on that).

So, part of the "language-specific" things can be done with a good library. 
This begs two questions for further discussion:

  1) What would a good go-toolbox-library contain? Do we all have to develop
our own, or would some be willing to share their work? Some open source
projects seem to do so, but with more or less restrictive licenses (GnuGo,
OpenGo)

  2) What, if any, would be good go-language features that can not easily be
provided as library functions? Do languages have other properties that would
make them more or less suited for go programming, either in the language
itself, or in the traditional way it is used? Perhaps some more exotic
languages might come in handy (knowledge representation, parallelism, "AI",
topology, set theory...)??


As to the question of hardware, I consider it to be the last serious
optimization trick, not worth worrying about until we know what we wish to
optimize. I do not believe low-level stuff like placing stones and counting
liberites will be much faster on special hardware, not if you count the time
it takes to communicate with the thing. And higher-level stuff seems to be
far too complex, and evolving all the time. That said, I think there might
be some advantages to be gained from a pattern matcher, that could take a
whole board image, and a large library of patterns, and quickly give a list
of matches. or perhaps some sort of tactical reader. Both of these tend to
suffer from the fact that to use them you'd need to add some higher-level
logic (conditions for using the pattern, and move generation and evaluation
for the tactical reader). With the speed computers grow these days, you
would need really great improvement from the special hardware to compete
with the PCs you can expect to buy by the time your special hardware can be
made available... 

-- 
Heikki Levanto     LSD Levanto Software Development   heikki@xxxxxxxxxxxxxxxxx
               "In Murphy we Turst"