Comments by rescharn

Hi Mats, let me explain, that my understanding of AI is NOT simulating
anything but developing solutions genuine to machine. Intelligent behavior
is not merely imitating. Now, how to support the SMIRF project:

a) intellectually: by showing interest, writing comments, testing, giving
constructive critic, mentioning the SMIRF project where it would make
sense. There is no need to exceed intellectual limits, we all mostly are
specialists, thus don't worry when there will be gaps, I don't either.

b) financially: where fans like to use the SMIRF program, they should be
aware, that there are costs for organizing and maintaining hard and
software, e.g. actual development environments, and that it needs a lot of
time, wherein no money could be earned. Thus it makes sense to those people
to place some donations via paypal.

Hi, Mats, beside of the fact, that the Windows distribution of SMIRF still
is the only one and just has been updated (in the bonus version), it does
not matter to me, how many people are using Smirf, but in contrast it
does, how many are really supporting it. And, because of this number is
nearly vanishing, I simply decided do migrate to Mac OS X because of
software political reasons.

Yesterday I have published on my web site my new model for calculating the
average piece exchange values for various gaits, both: simplified and
improved, at http://www.chessbox.de/Compu/schachansatz1_e.html. Reinhard.

Hi Mats, one of my first goals is to make SMIRF play self-containedly
especially through the opening stage. I am happy, that this works even for
randomized starting positions half-way sufficiently. To manipulate the
opening behaviour to gain more success simply by adding some quirks
instead of modifying the global model concept will destroy the chance of
finding an abstract and consistent base model. Still I am e.g. not fully
satisfied with my average piece value model, and the evaluation function
is three times as slow as necessary.

Nevertheless I have thoughts to distribute a predefined amount of
evaluation to be randomizedly disposed in chosing second class moves
during the beginning to gain a less determinated play at fixed opening
arrays. Actually I still recommend to play Chess960 or 10x8 CRC to have
more diversified game experiences.

The future of SMIRF: well, in the meantime there have been some questions
from different sides, what will be with SMIRF. 

First, I am about to migrate it to the Mac OS X. That is, because I am
angry about MS Vista and its unsufficient driver set (especially 64 Bit),
its bad behaviour against programmers and its several backdoors for
government, police or secret service investigations targeting every file
on a Vista system (as I prosume). In contrast Mac OS X is again going to
create a homegeneous 64 Bit user landscape starting with coming OS X
Leopard version.

SMIRF will become 64 Bit then. There will be no big speed step by that,
because SMIRF is no a bitboard based program. But it will use the grown
register set, and it will then benefit from any compiler optimization
improvement. I remember days, where I investigated to have an ARM RISC
processor based solution, but there are currently no fast desktop systems
or sponsors, which would provide me with such a development environment.
Thus I stay on Intel/AMD64 based hardware (unfortunately also without any
sponsor yet).

SMIRF will not be merely migrated to Mac OS X. I intend to have a lot of
new design elements:

a) redesign the internal data structure and caching logic
b) rewrite the position detail evaluation function (which is still the
first slow draft, may be a 200% speed up then)
c) support additionally also an additional piece (General = N+B+R)
d) support blocked squares (to customize the playable square zone)
e) build in prompting (instead of badly working permanent brain)
f) attempt to implement multithreaded multiprocessor usage 
g) create a separated unit for to contain move logic and pgn file
maintenance beside of the GUI
h) attempt to have a UCI protocol based GUI

That is a huge project and will need a remarkable amount of my free time.
So do not wait for a finished Mac OS X version in the near future. May be
some of then made progresses will be reimplemented into the working
Windows 32 Bit solution, but from now on possible updates would only be
published for the donators' bonus version.

Reinhard.

Hi Mats, please have a look on that, what you have said. You are using such
names like 'central squares' or 'established chess laws'. But that kind
of arguing is just the problem. Why are central squares that important?
Where is the center in different chess960 games, where the king himself
might be decentralized? By that you learn, that such categories are
derived from more essential but abstract things. 

Another more transparent example are the average piece exchange values:
where do those traditional values come from? What is with that at
different variants? At my webpage you will find a simple theory to derive
such values even for unusual piece types or board sizes. As I tried to
tell you, I am not interested in that kind of chess knowledge, where it at
least leads to a simple implementing of a copycat behaviour. 

If you want to create an effective and INTELLIGENT chess program, you
first have to UNDERSTAND the basics of chess, not to imitate the so called
chess knowledge, which is moreover differing enormously depending on which
chess master you will ask. Then you will have to TRANSLATE it into the
world and language of a CPU.

Today there are a lot of effective but mostly huge chess programs. So
there is no urgent need for to write another one. But on the other side
there are very few intelligently working approaches using instead very
restricted means. I am arguing for to have computer chess program
tournaments with LIMITED means, especially targeting the persistant storage
size including the program executeable. They should be bound to a special
upper bound. And it should be measured in a packed form e.g. as RAR for to
skip inner redundancies as generated depending of the selected computer
language and to avoid the temptation to undergo any limits by including
packed knowledge.

Hi Mats! I do not know to wich variant you are referring. SMIRF actually
does not use any opening library even for established starting arrays, to
not hide possible weaknesses during opening, which should be covered by an
improved evaluation function, which in SMIRF is not stage depending but
constant during the whole game. Regarding that aspect SMIRF already is
handling openings not badly, so in your case it would be recommended to
post me such a critizised example privately.

To your prior suggestion to include some special variant in SMIRF: I am
about to rewrite the whole SMIRF project and to migrate it to Mac OS X. I
will remember such proposals and see then, what could be done. At the
first sight your variant is matching the FullChess criteria to be
included. Regards, Reinhard.

SMIRF pages at http://www.chessbox.de are online again. Nevertheless SMIRF
is migrating to Mac OS X.

Because of a vanishing feed back and an increasing rate of being insulted,
I decided to leave the scene for a while. I will work for a new version of
SMIRF for Mac OS X during the next time and may return then.

Regards, Reinhard.

Hi Mats, yes, I handled the Mammoth as a fully jumping piece. Your
arguments whether the piece is not save towards distant threats is a
TACTICAL argument, which has nothing to do in average piece value
considerations. Be aware, that a Mammoth also has the chance to escape
such threats by his numerous move possibilities. And - as already earlier
stated - real exchanges would have to consider the actual positional
implications of all pieces within the actual board situation.

P.S.: I should mention again, that my scheme is calculating AVERAGE piece
values, which have to be completed by positional detail evaluations when
evaluating real board positions.

P.P.S.: See also at http://www.chessbox.de/Compu/schachveri1_e.html