Artificial Intelligence Program For The Game Of Go In Lisp

[CAI GENGYANG]

So I want to build an artificial intelligence program based on the MonteCarlo Tree Search Algorithm for the game of Go (which I am best at ! , having represented my current country in several national and international Go tournaments in the past) and I want to write this in Lisp.

Wikipedia link --- https://en.wikipedia.org/wiki/Monte_Carlo_tree_search

Where and how do I start ?

[tar...@google.com]

You should perhaps start with the basics first:

1. Decide how to represent a Go board and the pieces on it.
2. Write a function that proposes a move for either the white or black player. This doesn't have to be very good at the beginning. You can improve it later.
3. Write a framework that will repeatedly apply your move generator to the board until the game is done.
4. Write a function that will compute who won.

Once you have that in place, you can work on implementing the Monte Carlo tree search algorithm.

[Pascal J. Bourguignon]

Start trying to develop some natural intelligence.

You've not demonstrated that you had any, so good luck trying to build
an artificial one.

On the other hand, if you're able to survive long enough (doubtful, but
who knows), you might be able to get fitted with an artificial
intelligence chip in the future…

--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

[Matthew Carter]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:

> CAI GENGYANG <gengy...@gmail.com> writes:
>
>> So I want to build an artificial intelligence program based on the
>> MonteCarlo Tree Search Algorithm for the game of Go (which I am best
>> at ! , having represented my current country in several national and
>> international Go tournaments in the past) and I want to write this in
>> Lisp.
>>
>> Wikipedia link --- https://en.wikipedia.org/wiki/Monte_Carlo_tree_search
>>
>> Where and how do I start ?
>
> Start trying to develop some natural intelligence.
>
> You've not demonstrated that you had any, so good luck trying to build
> an artificial one.
>
> On the other hand, if you're able to survive long enough (doubtful, but
> who knows), you might be able to get fitted with an artificial
> intelligence chip in the future…

Hahaha

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

[Mike Stump]

In article <b7c69898-cf6f-4c47...@googlegroups.com>,

<tar...@google.com> wrote:
>On Monday, September 28, 2015 at 9:07:11 AM UTC-7, CAI GENGYANG wrote:
>> So I want to build an artificial intelligence program based on the MonteCarlo Tree Search Algorithm for the game of Go (which I am best at ! ,
>having represented my current country in several national and international Go tournaments in the past) and I want to write this in Lisp.
>>
>> Wikipedia link --- https://en.wikipedia.org/wiki/Monte_Carlo_tree_search
>>
>> Where and how do I start ?
>
>You should perhaps start with the basics first:
>
>1. Decide how to represent a Go board and the pieces on it.
>2. Write a function that proposes a move for either the white or black player. This doesn't have to be very good at the beginning. You can
>improve it later.

To elaborate, you want a function that will produce a list of valid moves. To play, you can merely choose the first valid move.

To refine, you loop on each move, produce the score for that position, and then play the highest scored move.

[Mike Stump]

In article <29fcc65c-69a2-4c5d...@googlegroups.com>,

First, you should unlearn the term artificial intelligence, it doesn't
mean what you think it means.

So, the steps are:

buy computer
learn programming
install lisp
learn lisp
fire up emacs
then type in the program

:-)

If go is too hard for you, then I'd recommend tic-tac-toe. If you
can't figure that out by yourself, then, you should ask about the part
that you are stuck on. Now, before you laugh, mcts would be the same
code for either tic-tac-toe or go, if you code it right. Also, most
of the rest of the code is identical to go, if you do it right.

Now, in programming, one way to learn programming is to simply copy
the code that most closely does what you want, and enhance it. You
can start by doing this with google ("monty carlo tree search in
lisp")[2] (aka https://gist.github.com/nowl/4752490). Once you have it
working and it does what you want, you can change the board
representation to match go, and change the valid move generator to
match go, then, you're done.

[Matthew Carter]

Whenever I start to learn a new programming language, a quick program I
write up is the higher or lower game (not sure if there is a fancy name
for it), which basically performs as follows:

* System generates a random number from 1 to 100
* User is prompted to enter a guess
* If the user's is higher, they are told so (vice versa)
* When the user guesses the correct number, the game ends and total
guesses are printed

It lets me quickly warm up to the language syntax, how it is
compiled/interpreted, built in random call, and user input.

For some languages, this is definitely easier than others (some are not
too keen on letting user's input data in an interactive manner without
jumping through some hoops).

Any other game can then be modified off that as a starting point for the
most part (adding more functions/logic as needed to each segment of it).

[CAI GENGYANG]

Ok,

So I decided to start by learning from this piece of code on GitHub (a Go Board game written in Common Lisp) : https://github.com/elodin-/Go-board-game/blob/master/GoBoard.lisp and am trying to understand what it means ...

The first paragraph on "Board Functions" has these 8 lines of code :

(defparameter size 7)

;union count
(defparameter strng 0)

(defvar *board* (make-array (list size size) :element-type 'list :initial-element '(N 999 0)))

(defun filled (x y)
(aref *board* x y))

(defun setC (x y val lib union)
(setf (aref *board* x y) (list val lib union)))

Could someone help to explain what each line means?

Thanks a lot ....

[Pascal J. Bourguignon]

CAI GENGYANG <gengy...@gmail.com> writes:

> Ok,
>
> So I decided to start by learning from this piece of code on GitHub (a
> Go Board game written in Common Lisp) :
> https://github.com/elodin-/Go-board-game/blob/master/GoBoard.lisp and
> am trying to understand what it means ...

Yeah, sure. Babies learn their mother tongue by reading the great
philosophers…

[Rob Warnock]

CAI GENGYANG <gengy...@gmail.com> wrote:
+---------------
| Help .... I want to understand what it means ....
+---------------

Have you read the relevant sections of the Common Lisp specification?

http://www.lispworks.com/documentation/HyperSpec/Front/index.htm


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[WJ]

Rob Warnock wrote:

> CAI GENGYANG <gengy...@gmail.com> wrote:
> +---------------
> > Help .... I want to understand what it means ....
> +---------------
>
> Have you read the relevant sections of the Common Lisp specification?

Here's what the experts say about CL (COBOL-Like):

"an unwieldy, overweight beast"
"intellectual overload"
"did kill Lisp"
"A monstrosity"
"ignores the basics of language design"
"killed Lisp"
"sucks"
"an aberration"
"the WORST thing that could possibly happen to LISP"
"incomprehensible"
"a nightmare"
"not commercially viable"
"no future"
"a significantly ugly language"
"hacks"
"unfortunate"
"a disaster"
"bad"

In context:


Guy L. Steele, Jr., July 1989:

I think we may usefully compare the approximate number of pages
in the defining standard or draft standard for several
programming languages:

Common Lisp 1000 or more
COBOL 810
ATLAS 790
Fortran 77 430
PL/I 420
BASIC 360
ADA 340
Fortran 8x 300
C 220
Pascal 120
DIBOL 90
Scheme 50


-----


Brooks and Gabriel 1984, "A Critique of Common Lisp":

Every decision of the committee can be locally rationalized
as the right thing. We believe that the sum of these
decisions, however, has produced something greater than its
parts; an unwieldy, overweight beast, with significant costs
(especially on other than micro-codable personal Lisp
engines) in compiler size and speed, in runtime performance,
in programmer overhead needed to produce efficient programs,
and in intellectual overload for a programmer wishing to be
a proficient COMMON LISP programmer.


-----


Bernard Lang:

Common Lisp did kill Lisp. Period. (just languages take a
long time dying ...) It is to Lisp what C++ is to C. A
monstrosity that totally ignores the basics of language
design, simplicity and orthogonality to begin with.


-----

Gilles Kahn:

To this day I have not forgotten that Common Lisp killed
Lisp, and forced us to abandon a perfectly good system,
LeLisp.

-----


Paul Graham, May 2001:

A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp.

Historically, Lisp has been good at letting hackers have their
way. The political correctness of Common Lisp is an aberration.
Early Lisps let you get your hands on everything.

A really good language should be both clean and dirty:
cleanly designed, with a small core of well understood and
highly orthogonal operators, but dirty in the sense that it
lets hackers have their way with it. C is like this. So were
the early Lisps. A real hacker's language will always have a
slightly raffish character.

Organic growth seems to yield better technology and richer
founders than the big bang method. If you look at the
dominant technologies today, you'll find that most of them
grew organically. This pattern doesn't only apply to
companies. You see it in sponsored research too. Multics and
Common Lisp were big-bang projects, and Unix and MacLisp
were organic growth projects.


-----


Dick Gabriel:

Common LISP just was never designed to be a commercially
viable LISP. It was intended to serve as a compromise between
the manufacturers of LISP machines and other vendors of LISP
products. Never did we think of it as an industrial strength
system... So, to the extent that ANSI's ongoing efforts to
standardize on Common LISP exercise some influence over how LISP
is accepted in the world at large, I anticipate a disaster.


-----

Jeffrey M. Jacobs:


I think CL is the WORST thing that could possibly happen to LISP.
In fact, I consider it a language different from "true" LISP.

*****

Common LISP is the PL/I of Lisps. Too big and too
incomprehensible, with no examination of the real world of
software engineering.

... The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and
then we'll all go down the tubes". Everybody had vested
interests, both financial and emotional.

CL is a nightmare; it has effectively killed LISP
development in this country. It is not commercially viable
and has virtually no future outside of the traditional
academic/defense/research arena.



-----


Dick Gabriel:

Common Lisp is a significantly ugly language. If Guy and I
had been locked in a room, you can bet it wouldn't have
turned out like that.


-----

Paul Graham:

Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?


-----

Daniel Weinreb, 24 Feb 2003:

Having separate "value cells" and "function cells" (to use
the "street language" way of saying it) was one of the most
unfortunate issues. We did not want to break pre-existing
programs that had a global variable named "foo" and a global
function named "foo" that were distinct. We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general.


-----


Daniel Weinreb, 28 Feb 2003:

Lisp2 means that all kinds of language primitives have to
exist in two versions, or be parameterizable as to whether
they are talking about the value cell or function cell. It
makes the language bigger, and that's bad in and of itself.


-----


Paul Graham:

I consider Loop one of the worst flaws in CL, and an example
to be borne in mind by both macro writers and language designers.


[ In "ANSI Common Lisp", Graham makes the following comments: ]

The loop macro was originally designed to help inexperienced
Lisp users write iterative code. Instead of writing Lisp code,
you express your program in a form meant to resemble English,
and this is then translated into Lisp. Unfortunately, loop is
more like English than its designers ever intended: you can
use it in simple cases without quite understanding how it
works, but to understand it in the abstract is almost
impossible.
....
the ANSI standard does not really give a formal specification
of its behavior.
....
The first thing one notices about the loop macro is that it
has syntax. A loop expression contains not subexpressions but
clauses. The clauses are not delimited by parentheses;
instead, each kind has a distinct syntax. In that, loop
resembles traditional Algol-like languages. But the other
distinctive feature of loop, which makes it as unlike Algol as
Lisp, is that the order in which things happen is only
loosely related to the order in which the clauses occur.
....
For such reasons, the use of loop cannot be recommended.



-----


Dan Weinreb, one of the designers of Common Lisp:

... the problem with LOOP was that it turned out to be hard to
predict what it would do, when you started using a lot of
different facets of LOOP all together. This is a serious problem
since the whole idea of LOOP was to let you use many facets
together; if you're not doing that, LOOP is overkill.


-----


Barry Margolin, 05 Apr 2001
(http://groups.google.com/group/comp.lang.lisp/msg/8a48cedb8b3bcb52)

>(My second rule of thumb concerning LOOP would be the negative of
>Barry Margolin's: The more complex the looping, the more you need/want
>to use LOOP.)

My recommendation is based on seeing many question in the past of the form
"What happens if you use both XXX and YYY in the same LOOP?" The
unfortunate fact is that when we were writing the standard we didn't have
time to nail down all the possible interactions between different LOOP
features, so many of these are not well specified. And even if we did get
it right in the standard, it's likely to be difficult to find them and I
wouldn't trust that all implementors got it right (many of those questions
were probably from implementors, trying to figure out what they were
supposed to do). And even if they all got it right, someone reading your
code may not be able to figure it out.

So, with all those potential problems, my feeling is that if you have to
ask, it's probably better to use something other than LOOP.


-----

Barry Margolin:

> 3. Loop is very powerful, granted, and many people are trying to
> argue that "you can do so much with loop that it's unreadable."
> This is not an argument.

But it is! Because any use of LOOP has the potential to be
unreadable, the reader must read it carefully to verify that
it's just one of the cases that doesn't require careful
reading!


-----

From: John Foderaro <j...@unspamx.franz.com>
Newsgroups: comp.lang.lisp
Subject: Re: the "loop" macro
Date: Sun, 26 Aug 2001 10:51:26 -0700

I'm not trying to join a debate on loop. I just wanted to present
the other side of [the issue so that] the intelligent people can
then weigh the arguments on both sides.

I'm not suggesting that loop can be fixed either by adding
parenthesis or coming up with ways of indenting it to make it
understandable. It's a lost cause.

[Kaz Kylheku]

On 2015-09-29, WJ <w_a_...@yahoo.com> wrote:
> I think we may usefully compare the approximate number of pages
> in the defining standard or draft standard for several
> programming languages:

But first, we should add some new data:

> Common Lisp 1000 or more

Ada 2012 832

> COBOL 810
> ATLAS 790

C11 683
Fortran 2010 603
C99 538

> Fortran 77 430
> PL/I 420
> BASIC 360
> ADA 340
> Fortran 8x 300
> C 220

1000 pages is not even twice C, and C is what: a high level
assembler coupled with a paltry library.

Now add the documentaton for the libs that you need to do *anything* with C,
like just to have hash tables, lists and trees, or better string manipulation.

[Pascal J. Bourguignon]

CAI GENGYANG <gengy...@gmail.com> writes:

> Are you saying that this is too tough a piece of code to start learning from for a beginner ?

Exactly.

Start by learning the CL operators and conceptions, writing and
DEBUGGING simple programs.

When you type a form at the REPL and you get an error, you must not
paste it here, you must be able to understand from the form and the
error message what you did wrong, and to correct it yourself.

Until you're able to do that, there's no hope of doing anything more
complex than a student exercise.

[Pascal J. Bourguignon]

It would be interesting to add a column with the number of "concepts" in
the language (and perhaps another with the ratio).

[Mike Stump]

In article <ce1af379-91ea-4e33...@googlegroups.com>,

CAI GENGYANG <gengy...@gmail.com> wrote:
>So I decided to start by learning from this piece of code on GitHub (a Go Board game written in Common Lisp) :
>https://github.com/elodin-/Go-board-game/blob/master/GoBoard.lisp and am trying to understand what it means ...
>
>The first paragraph on "Board Functions" has these 8 lines of code :
>
>(defparameter size 7)

If you have to ask about this, you might not have finished google
("tutorial on lisp"). Go finish that now, and then ask a specific
question that can't be answered by google nor documentation on lisp,
or a dictionary.

Try it this way, what do you think it does? Examine the rest of the
code and confirm that it does what you think it does. Alter it, and
see if your understanding of what it does is correct.

[WJ]

Pascal J. Bourguignon wrote:

> > Where and how do I start ?
>
> Start trying to develop some natural intelligence.

Stop and think.

If he had a plentitude of intelligence, he wouldn't
be using CL (COBOL-Like).

[CAI GENGYANG]

Hi,

So I hope this post doesn't get ignored and marked as spam because it's a geniune one.
Chapter 2.9(Compilation) of PG's "onlisp": http://ep.yimg.com/ty/cdn/paulgraham/onlisp.pdf teaches how to compile Lisp functions either individually or by file. I was just going through all the exercises in this chapter and was going fine until I hit an error message which I just couldn't debug (The part where I am trying to compile make-adder). It gives this error message, which I am unsure how to debug :


CL-USER 10 : 1 > (compile 'make-adder)

Error: Undefined function MAKE-ADDER in form (SYMBOL-FUNCTION MAKE-ADDER).
1 (continue) Take the function definition of another function name.
2 Try to take the function definition of MAKE-ADDER again.
3 Return a value from the call to (SYMBOL-FUNCTION MAKE-ADDER).
4 Set the function definition of MAKE-ADDER to another function.
5 (abort) Return to level 1.
6 Return to debug level 1.
7 Return to level 0.
8 Return to top loop level 0.
- show quoted text -


How do you take the function definition of another function name , ... return a value from the call to (SYMBOL_FUNCTION MAKE_ADDER), set the function definition of MAKE_ADDER to another function etc etc ... (steps 1 to 8)?

[Pascal J. Bourguignon]

CAI GENGYANG <gengy...@gmail.com> writes:

> Hi,
>
> So I hope this post doesn't get ignored and marked as spam because it's a geniune one.
> Chapter 2.9(Compilation) of PG's "onlisp":
> http://ep.yimg.com/ty/cdn/paulgraham/onlisp.pdf teaches how to compile
> Lisp functions either individually or by file. I was just going
> through all the exercises in this chapter and was going fine until I
> hit an error message which I just couldn't debug (The part where I am
> trying to compile make-adder). It gives this error message, which I am
> unsure how to debug :

> CL-USER 10 : 1 > (compile 'make-adder)
>
> Error: Undefined function MAKE-ADDER in form (SYMBOL-FUNCTION MAKE-ADDER).

It means: you have not defined any function named MAKE-ADDER.

Why didn't you define a function named MAKE-ADDER?

Wouldn't seem logical to you to define such a function before trying to
compile it?

> How do you take the function definition of another function name ,

(fdefinition another-function-name)

> ... return a value from the call to (SYMBOL_FUNCTION MAKE_ADDER),

(SYMBOL_FUNCTION MAKE_ADDER)

> set the function definition of MAKE_ADDER to another function etc etc

(setf (fdefinition 'MAKE_ADDER) (function another))

> ... (steps 1 to 8)?

What are steps 1 to 8?

[CAI GENGYANG]

Ok, so I managed to get the code to work after defining a function called make-adder. When I compile it, I get the following result :

CL-USER 25 : 5 > (defun make-adder (x) (1+ x))
MAKE-ADDER

CL-USER 26 : 5 > (compile 'make-adder)
MAKE-ADDER
NIL
NIL

CL-USER 27 : 5 > (compiled-function-p (make-adder 2))
NIL


The last line CL-USER 27 : 5 > (compiled-function-p (make-adder 2)) gives a "NIL" result instead of "T" , which is the result given in the book.

Any idea how I can get it to produce "T" instead of "nil" ?

And also, what exactly is "T" ? I keep seeing it but don't really understand what it means ?

[Rob Warnock]

CAI GENGYANG <gengy...@gmail.com> wrote:
+---------------

| Ok, so I managed to get the code to work after defining a
| function called make-adder. When I compile it, I get the
| following result :
|
| CL-USER 25 : 5 > (defun make-adder (x) (1+ x))
| MAKE-ADDER

+---------------

This function does *NOT* "make an adder"; it just
adds one to its arg.

+---------------

| CL-USER 27 : 5 > (compiled-function-p (make-adder 2))
| NIL

+---------------

Why would you expect anything different?
The number 3 is not a function:

> (defun make-adder (x) (1+ x))
MAKE-ADDER

> (compile *)
MAKE-ADDER
NIL
NIL
> (make-adder 2)
3
> (compiled-function-p 3)
NIL
>

+---------------

| The last line CL-USER 27 : 5 > (compiled-function-p (make-adder 2))
| gives a "NIL" result instead of "T" , which is the result given in the book.

+---------------

That's because you're *not* using the definition for MAKE-ADDER
given in the book. [Hint: Calling a random function "MAKE-ADDER"
doesn't make it a function that makes adders.]

+---------------

| And also, what exactly is "T" ? I keep seeing it but don't
| really understand what it means ?

+---------------

As I told you before, READ THE SPEC, LUKE!!

http://www.lispworks.com/documentation/HyperSpec/Body/v_t.htm

[Pascal J. Bourguignon]

CAI GENGYANG <gengy...@gmail.com> writes:

> Ok, so I managed to get the code to work after defining a function
> called make-adder. When I compile it, I get the following result :
>
> CL-USER 25 : 5 > (defun make-adder (x) (1+ x))
> MAKE-ADDER
>
> CL-USER 26 : 5 > (compile 'make-adder)
> MAKE-ADDER
> NIL
> NIL
>
> CL-USER 27 : 5 > (compiled-function-p (make-adder 2))
> NIL
>
>
> The last line CL-USER 27 : 5 > (compiled-function-p (make-adder 2))
> gives a "NIL" result instead of "T" , which is the result given in the
> book.

This section of "On Lisp" unfortunately introduces a new concept while
providing examples with more than one changing variable.

Notice that for most readers, this situation doesn't present a problem,
on the contrary, since that demonstrate clearly the independence of the
new concept from the variating ones.

But this doesn't seem to be the case with you.


This section about closures assumes that you already know what a named
function is and what an anonymous function is. It comes after having
already explained what scopes are (and the difference between lexical
scope and dynamic scope).

It gives a first example of a closure where two named functions are
enclosed:

(let ((counter 0))
(defun new-id () (incf counter))
(defun reset-id () (setq counter 0)))

It is assumed you tried them out, calling various sequences of (new-id)
and (reset-id) to concretely understand what's happening here, how many
counter variables there are, and realize that new-id and reset-id are
not usual functions.

Having understood this notion of closure, On Lisp mentions that the
lexical variable enclosed in the closures can also be a variable local
to another function. However, in presenting the new make-adder example,
it changes everything.


It seems that in your case, one would have to move more slowly,
presenting this succession of examples:



;; Normal function:
(defun add3 (x) (+ x 3))

;; Closure:
(let ((increment 3))
(defun add3c (x) (+ x increment)))

;; Function with a local function, and returning the local function:
(defun make-add3f ()
(flet ((add3 (x) (+ x 3)))
(function add3)))

;; Function with a local closure, and returning the local closure
(defun make-add3c ()
(let ((increment 3))
(flet ((add3 (x) (+ x increment)))
(function add3))))

;; Function with a local closure, and returning the local closure, using the function parameter:
(defun make-adderc (increment)
(flet ((adder (x) (+ x increment)))
(function adder)))

;; Function with an anonymous local closure, and returning the local closure, using the function parameter:
(defun make-adder (increment)
(lambda (x) (+ x increment)))




(add3 4)
;; --> 7
(add3c 4)
;; --> 7
(make-add3f)
;; --> #<Compiled-function (:internal add3 make-add3f) (Non-Global) #x3020020EB7EF>
(funcall (make-add3f) 4)
;; --> 7
(make-add3c)
;; --> #<ccl:compiled-lexical-closure (:internal add3 make-add3c) #x30200229EA0F>
(funcall (make-add3c) 4)
;; --> 7
(make-adderc 3)
;; --> #<ccl:compiled-lexical-closure (:internal adder make-adderc) #x3020022FE9EF>
(funcall (make-adderc 3) 4)
;; --> 7
(make-adder 3)
;; --> #<ccl:compiled-lexical-closure (:internal make-adder) #x30200221E9EF>
(funcall (make-adder 3) 4)
;; --> 7


Unfortunately, it is not by copy-pasting this code to the REPL and
verifying that it gives the same results on your computer that you will
have learned anything.

It's by doing yourself, what I did here, that you would have learned
something, from the On Lisp book (or any book).


Babies learn how to speak their mothertongue in a couple of years by
themselves, without being told anything about the grammar and the
semantics of their language. Dictionaries and grammar rules might be
studied in school years later, but they are seldom used to learn
anything about the language. Dictionaries can be useful only to learn
about technicalities and and jargons.

Now, you can do the experiment, of taking a babie, and reading him a
dictionary and grammar rules, and see how effective it is to help him
learn the language.


Similarly, to learn anything, there's very little teachers can do at
all. Knowledge or know-how-to is not transmitted from teacher to pupil
(or from book author to book reader). Instead, knowledge is elaborated
by each brain, by the proper activity of each brain. The teacher or the
book writer learns more by teaching and writing the books than the
pupils or readers will ever learn by reading or assisting to the
courses. They learn because to write the book or make up the lesson,
they have to think, and this is this thinking process that builds
knowledge.

Now, readers and pupils can still learn something. But not from the
mere reading or listening act, (or even not from just reading and
writing, ie. copying, even if at a REPL). All you can learn by doing
that is to behave like a parrot.

The only way readers and pupil can learn anything, the only way their
brains can elaborate knowledge, is by thinking. And to learn something
specific to the subject matter, you would have to think about what
you've read. One kind of thinking you can do in mathematics and
programming, is like what I've done here, by taking one example, and
transforming it using small logical steps, to another example. In this
case, I've transformed a concrete function add3, into a function
generating a family of functions similar to add3.

But you cannot understand that, unless you do it yourself. And since
I've shown you what I've done, (or at least the steps I took, I could
have detailed formally each derivation, but it would be as interesting
as the proof of the 4-color map theorem), it will be harder for you to
think your own thoughts, and find your own derivation, and therefore
your own understanding.


Remember: basically, teaching books do not contain any knowledge for
you to replicate like a parrot. What they contain are puzzles, that you
must solve YOURSELF if you want to be the one who will be learning from
these books.


And we are here at news:comp.lang.lisp to help you solve your puzzle
when you're stuck, not to read the books for you. And I don't mean to
help you solving the whole puzzle, but to help you with some small part
of the puzzle: you still have to find the puzzle solutions yourself.

[Richard Fateman]

Do you live near another human who (a) reads english (b) is interested
in learning Lisp programming?

I suggest you find such a person and discuss your issues with him/her
instead of posting at comp.lang.lisp.

[CAI GENGYANG]

There are very few Lisp programmers (if any) here in Singapore ...

[hughag...@gmail.com]

> > intelligence chip in the future...

>
> Hahaha
>
> --
> Matthew Carter (m...@ahungry.com)
> http://ahungry.com

comp.lang.lisp is a very mean-spirited place! Telling this guy that he has no "natural intelligence" wasn't called for --- that is really the same as saying that he is a moron.

Pascal J. Bourguignon beat me up too:
https://groups.google.com/forum/#!searchin/comp.lang.lisp/fmite/comp.lang.lisp/-nWfXAs_4ug/moiaKx78CPsJ

I play Go too, so I hope Cai Gengyang does write a Go program. I suggest going to KGS and playing some of the bots there. In many cases, the source-code is available for download. I'm not aware of any bots written in Common Lisp --- presumably due to the performance issue --- but it could be done.

If I were going to try it, I would use a language such as Go (from Google), Erlang or Oforth that has support for multi-core computers. I'm only 6 kyu though (KGS name: Classic), so I'm not really qualified to attempt a Go program. The bots so far are all in the single-digit kyu level, but I've never heard of anybody getting a bot into the dan level --- so, the field is wide-open!

I lost to a bot earlier today, but I'm in a slump right now and not playing well --- normally I don't lose to bots --- bots have an awkward style of play (I can always tell when a human opponent is cheating by using a bot, and I beat him anyway).

[Kaz Kylheku]

That's an ill predicament to wish upon a stranger, who isn't armed with the
comfortable separation which Usenet places between us and various pestilences,
and its affordances such as kill files.

[CAI GENGYANG]

Go is indeed a very interesting game in the sense that to master it requires both extremely good pure "brute-force" mental calculation skills in tight areas --- i.e. calculating life and death problems in small tight corner areas and battles (especially in timed competitions where you have to calculate moves really really fast) and also what I would call "creativity" and "intuition" in mid game areas where it might not be possible to calculate every sequence to a 100% certainty , so human players have come up with "rules of thumbs" over the centuries to generate high-probabilistic moves in such situations.

What differentiates the average player/professional from the truly great master often is the ability to generate such moves in competitive timed-games.

A famous example is the "ear-reddening" move played by Shusaku in 1846. A move apparently so devastating and out-of-the box that caused his opponents ear's to turn red when he saw it.

https://en.wikipedia.org/wiki/Ear-reddening_game

This move is indeed fascinating because it has an effect of influencing all 4 surrounding areas of the board and it is unlikely (correct me if I am wrong) that any modern computer/artificial intelligence is able to come up with such a move in a timed competitive game.

Whether this move is mathematically the "best" solution for this situation(assuming that Go is a finite game , another point to be debate) , it does in a sense show what the human brain is capable of conjuring up

You are wrong on one point though --- the strongest bots are now strong 6-7 dan amateur level.

AI has advanced very far, when i first started playing Go 20 years ago, the strongest machines couldn't beat a beginner. Now the strongest machines have a strength of about 6-7dan amateur level and I have about a 40-60% win ration against the strongest machine (Zen), though I wasn't playing seriously ... It is strong at calculation , but not so good in terms of creativity and probably still a long long way from being able to defeat a top professional Go player in an even-handicap game.

[hughag...@gmail.com]

On Wednesday, September 30, 2015 at 9:31:47 PM UTC-7, CAI GENGYANG wrote:
> Go is indeed a very interesting game in the sense that to master it requires both extremely good pure "brute-force" mental calculation skills in tight areas --- i.e. calculating life and death problems in small tight corner areas and battles (especially in timed competitions where you have to calculate moves really really fast) and also what I would call "creativity" and "intuition" in mid game areas where it might not be possible to calculate every sequence to a 100% certainty , so human players have come up with "rules of thumbs" over the centuries to generate high-probabilistic moves in such situations.
>
> What differentiates the average player/professional from the truly great master often is the ability to generate such moves in competitive timed-games.
>
> A famous example is the "ear-reddening" move played by Shusaku in 1846. A move apparently so devastating and out-of-the box that caused his opponents ear's to turn red when he saw it.

My ears turn red in about half the games that I play --- not because my opponent played a particularly brilliant stone, but just because I'm embarrassed by my own idiot blunders.

The reason why I don't quit (I have considered quitting more than once) is because I have occasional moments when I'm really playing like a dan --- this is why I know that it is possible. I remember one game in particular in which I was playing a 2K and suddenly inspiration struck, so I played a stone and ended up killing the entire edge of the board --- what appeared to be a rock-solid group with multiple eyes collapsed in a cascade of ataris. Computer programming is similar. I remember when I was writing the cross-compiler for the MiniForth processor. It seemed very complicated and I really despaired of succeeding. I took bicycle rides to think, and then suddenly while riding through Papago Park I had an inspiration. I did this, and then everything that had been complicated became easy. Since then, I have heard quite a lot of people say that Forth cross-compilation is easy, but pretty soon they make statements about it that indicate they don't know how to do it, and if they did succeed they did it the hard way. In 20 years, I have never met anybody who knew the trick (this includes the Forth-200x Standard committee).

I am reminded of a book I read about Buddhism. It was said that a common question that critics ask is: how do you know that enlightenment exists if you aren't enlightened? The answer was that everybody has their occasional moments. Doing that consistently is quite another matter of course.

Anyway, I think that it is great that you aspire to write a Go program --- but "artificial intelligence" is somewhat unrealistic --- computers never have moments of inspiration, but they just grind the data until they get an answer.

[hughag...@gmail.com]

I have read a theory that the brain experiences time flowing alternately forward and back. The brain sorts this out though so the person consciously experiences time flowing forward. This doesn't always work out very well though, which is why some people are dyslexic. Also, this is why the brain is able to pick up subliminal messages that are recorded backwards --- it is the subconscious that picks up the messages, not the conscious, as the conscious mind experiences time only flowing forwards.

I have also read that it is theoretically impossible for a baseball player to hit a fast ball because doing so requires swinging the bat before adequate information is available as to where the ball will be. The only explanation seems to be that the brain is obtaining information from the future. No joke! There really is no other explanation except information flowing backwards through time.

Anyway, I think that people should stop using the term "artificial intelligence" --- the term is just too arrogant --- computers aren't going to do that, ever!

Getting back to the subject of Go, most of the time when I'm doing life-and-death problems I think backwards. I imagine the group being dead, then ask: "How did we get here?" I mentally unplay the sequence, then I play it forward on the board to kill the group.

My suggestion for brave Cai is to start by writing a program that can solve life-and-death tsumego with brute-force search. Then (here is the fun part), upgrade the program so that it can generate life-and-death tsumego automatically. Way back in the 1980s, I read an article in Compute! magazine in which a guy wrote a Z80 program to solve those puzzles where you go through a labyrinth to get to the secret room. Then, he upgraded the program to generate the labyrinth automatically. The would make the labyrinth a rectangle, but then he would also twist the whole thing so it would come as a circle or even as a spiral. This program would be similar, except that it would be for Go tsumego.

BTW: Cai, what is your rank? You are a dan? If so, contact me privately and we can discuss this subject (I don't think anybody on comp.lang.lisp wants to hear about Go, which they know nothing about) --- I might be able to help you with the program, but it would have to be in Forth as I don't do Lisp. :-)

[CAI GENGYANG]

About 5 dan in rank if I play seriously in competitions ... I'll send you a pm

[CAI GENGYANG]

I can't seem to see your full email address, my email is gengy...@gmail.com. Try sending me pm ? Thanks

[Lars Brinkhoff]

hughag...@gmail.com writes:
> I remember when I was writing the cross-compiler for the MiniForth
> processor. It seemed very complicated and I really despaired of
> succeeding. I took bicycle rides to think, and then suddenly while
> riding through Papago Park I had an inspiration. I did this, and then
> everything that had been complicated became easy.

Would you like to tell more about your insights? Which were the hard
problems, and what were their solutions?

[Mark Tarver]

On Wednesday, 30 September 2015 11:20:33 UTC+1, CAI GENGYANG wrote:

> And also, what exactly is "T" ? I keep seeing it but don't really understand what it means ?

You need to get a good introduction to Lisp and sit down with it before even thinking about tough AI problems. comp.lang.lisp is not the place to learn Lisp; in fact, I would say unless you want to put up with more of the same abuse you have already endured, I'd stay away from here. Don't let it spoil your learning experience and joy which is precious.

good luck

Mark

[hughag...@gmail.com]

Does Shen have any advantage over Scheme or Lisp for AI? I don't know what is different about Shen --- it is possible that I don't know enough about Scheme/Lisp to understand your answer --- you'll have to keep it simple.

Also, the term AI is undefined. As I said before, computers aren't intelligent in the same way that people are, and they aren't going to be. So, what is the term AI generally taken to mean?

[hughag...@gmail.com]

I sent you a private email, as I don't think Forth cross-compilation is a topic very many people are interested in on comp.lang.lisp..

If people are interested, they can send me a private email --- I have a Forth language that I'm developing for use on 64-bit desktop-computers, and I'm interested in getting feedback --- I've already been "beat up" by Pascal J. Bourguignon for not providing garbage-collection in my Stundurd micro-controller, and this language doesn't have GC either, although it does have generators (loosely based on Icon's generators).

BTW: Any thoughts regarding Icon from the comp.lang.lisp crowd? I've been thinking that I might suggest to Cai that he try Icon for his Go program rather than Lisp or Forth. You guys seem to be a highly opinionated bunch, so presumably you have opinions on Icon as well as Forth and the game of Go and everything else under the sun. I might learn something, which is why I ask. I remember learning a lot on comp.lang.asm.x86 --- the possibility of learning something on comp.lang.lisp exists, although there tends to be more heat than light over here (CLAX has its flame-wars too, of course).