I just had a brief chat in Slack about this, I'll paste the chat, then more
details
about what I have in mind.
hal9000 I am thinking of working on a little project as an experiment and a
learning exercise -- a distributed chess player that farms out its work to
multiple nodes
if anyone is interested in collaborating on that, let me know
ssijak @hal9000distributed min-max?
hal9000 not necessarily - thinking i might impose restrictions on the
algorithm to make it interesting - i'm not knowledgeable about "real" chess
algorithms anyway
tfarla @hal9000: that does sound interesting
ankhers I think that would be fun.
hal9000 i'll post on the google group to avoid cluttering here
------
So... my basic idea.
- The goal is *not* to create a wonderful, competitive robot chess player.
- That *might* be a later goal.
- The goal is to distribute the work in a reasonable way and make it nice
and modular.
- It doesn't have to play "super-well"; it has to obey the rules, respond
in
reasonable time, and play *acceptably* well, whatever that means.
- I am leaning *away* from the traditional chess engine techniques.
Aside: I have often felt that chess playing algorithms are in a sense
"cheaters" --
a human player does not consciously look ahead millions of moves. Humans
are smart and slow; our algorithms are very fast and very dumb. (We never
have "contests" between an autistic savant and a hand calculator, do we? As
I
see it, the machine-human chess matches are not much different.)
This, by the way, is one reason Arimaa is notoriously difficult for machines
to play. The game is inherently more amenable to human intuition that to any
kind of optimized brute-force search. An algorithm to play Arimaa is
something I
have often thought of working on (but never will).
Therefore, I am leaning toward the idea of some kind of "handicap" or
limitation
on the algorithm. Something like: You can analyze the board statically all
you want,
but you can only look at N total "what-if" scenarios. (The search tree may
be as
deep or shallow as you like, but can only have N nodes.)
So there could be *two* possible scenarios for this project, and they are
not
mutually exclusive:
1. Write a distributed bot that plays acceptably well against a human.
2. More interestingly: Let two versions of the bot play against each other.
Let
each team tweak the algorithms and heuristics within certain boundaries.
Then
we can have a tournament between the two sets of heuristics (essentially a
competition of programmers).
If anyone is interested in working on this, let's talk.... :)
Thanks,
Hal Fulton
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-talk/af81655c-8757-41ef-8e63-855964307cf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
