Author: Vincent Diepeveen
Date: 15:31:01 07/13/01
Go up one level in this thread
On July 13, 2001 at 17:52:29, Joshua Lee wrote:
>I was wondering about any developments in the higher level programming
>languages.
>I think if plain english was used certain things in chess that are easy to
>verbalize in chess could easily turn those computers from "Bean Counters" to
>"Positionally Clean" Counters. People say computers are tactically as strong if
>not better than gm's in tactics i say sometimes as it takes the best software on
>the fastest available computers well over a 3 minute time control to solve quite
>a few tactical problems. So sometimes yes and sometimes no however this leaves
>defense and positional play which if anyone out there thinks the computer is GM
>level positionally i would refer them to Dortmund games from last year or the
>Nederlands ch that same year or even the lone win of Van der Weil over Rebel....
> So then what do the GM's Know that the computers donot? Well without taking
>up several pages i will guess that computerchess programming has been around
>long enough for someone to have tried to "Teach" the computer salient points
>about the game. I just think that with a higher level language this should be
>easier to program yet some work should still be done with Geometry and Storing
>positions i know there will be a Jerk out there that will say we already have
>that haven't you heard of Hash tables?
The problem of a higher level language is
a) that so far all attempts to create higher programming
languages failed.
For example functional programming languages might look cool for
a 2 line example, but when you have half a megabyte of functional code,
it looks like the biggest spaghetti code in the world.
Apart from that there is a PRACTICAL problem. Let's take the
example of a functional language again.
My draughtsprogram originally was created in the functional programming
language called GOFER. Developed at university of Amsterdam.
At my pentium100 in those days i searched initially a few nodes in
a load of minutes in gofer.
So i searched a few ply. Very few.
After some hard work i managed to speedup the code in Gofer. I then
got 1 node a second.
Then i translated the program from Gofer to C. Very rude code of course.
I directly got 10000 nodes a second. With some more improvements that
were 20000 nodes a second.
Guess what i was a factor 20000 faster as gofer!
Now suppose you make an even higher level language, what will the
speed of your program be?
1 node in a year?
Now the most surprising thing was that my imperative C code was way
more readable as the gofer code.
The gofer code was that huge, that all the short functions became
completely unusable.
Of course with the Haskell dialect i could have speeded it up, but
haskell isn't functional. Haskell is a hack already to the gofer
language (to use my own words) to add imperative programming to
gofer.
That SUCKS of course. The principle that the functional language
wasn't strong enough to express everything already says a lot about
how useful functional languages in real life are and will be in
the future.
One year later a clever guy, who used functional languages a lot,
managed to understand my program in gofer after quite some study.
A big thing which i had explained to him was that i was shocked
that alfabeta in C was easier and shorter formulated as in Gofer.
Of course he wasn't happy with that.
After some weeks of thoughts he managed to formulate in a very
cryptic way alfabeta. Also getting rid of some lazy evaluated
move lists which were not necessary.
Now the gofer draughts program speeded directly up a factor of 2.
So gofer no longer sucked in his eyes. I just had badly programmed it.
With hard work he had managed to speed it up a factor of TWO!!!
Well, for me it still was a factor of 10000 slower as my C program!
The object oriented c++ language is IMHO the best existing high level
language in the world. It's already hell slower as C if you use
the high level features of it. It's object oriented, that's way
nicer as functional languages.
Functional thinking is not closer to mankind.
If i plan something i first plan A, then i plan B then i plan C.
I don't plan things at the same time to be done, because then
things get a mess. Sequential thinking is way easier as functional
thinking.
Object oriented languages however add something which is high level
and missing clearly in C. Especially bad programmers are better off with
C++ as they can mess up their own object, but not that of other persons.
Clear advantages for companies.
But what you want is to define thoughts which no program has.
So that's very high language.
To do that let's skip the first (and IMHO the
most difficult) problems of defining how we think
as human.
Suppose you are able to create a compiler that eats english.
What speed will it have?
It will need like 10^50 calculations to say something meaningfull?
>for the more intellectually inclinded : We can make these better by reasearching
>what the computer should know explaining the position to the program and
>developing the storage to use less space this way it may be possible to fit in
>128MB what would now take 1GB
There is one part where i agree with you. I think that a very good
evaluation is better as search, as long as search isn't the weakest link
of course.
Look we all know that 6 plies always loses from 10 ply (if that 10 ply
not a too stupid eval like material only). But when you ask me what
wins: 12 ply or 16 ply. that 12 ply being my program version 2010
and that 16 ply being some other program with knowledge from 2005.
Then i would bet bigtime at my program!
Best regards,
Vincent
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.