[Entertainment] When tuning goes wrong...

[Ron Murawski]

I made a lot of subtle design mistakes myself, ... a poor choice of square numbering (I have bit 0 = A8 and bit 63 = H1).
The latter is problematic in that I have to number ranks in reverse order, i.e. rank1 is 7 and rank8 is 0 (to keep things simple).
No problem except that I can't compare ranks directly like if (a<b) ...
Martin

Hi Martin,

I have the same square numbering and I do not consider it a mistake. I wrote a simple macro
#define CHESS_RANK(rank) (7 - (rank))
using the macro, I can compare CHESS_RANKs directly.

If you write:
if ( CHESS_RANK(a) < CHESS_RANK(b) )
the macro expands to:
if ( (7 - (a)) < (7 - (b)) )
and now, when you compile, a good optimizer will eliminate the useless subtraction transforming it to:
if ( -a < -b )
and now the optimizer is smart enough to realize that this can be transformed (ie: optimized again) into:
if ( a > b )
which means that the macro will execute with no delay. Best of all, your original source code is now clear and agrees with normal chess convention.

Ron

[lucasart]

I made a lot of subtle design mistakes myself, ... a poor choice of square numbering (I have bit 0 = A8 and bit 63 = H1).
The latter is problematic in that I have to number ranks in reverse order, i.e. rank1 is 7 and rank8 is 0 (to keep things simple).
No problem except that I can't compare ranks directly like if (a<b) ...
Martin

Hi Martin,

I have the same square numbering and I do not consider it a mistake. I wrote a simple macro
#define CHESS_RANK(rank) (7 - (rank))
using the macro, I can compare CHESS_RANKs directly.

If you write:
if ( CHESS_RANK(a) < CHESS_RANK(b) )
the macro expands to:
if ( (7 - (a)) < (7 - (b)) )
and now, when you compile, a good optimizer will eliminate the useless subtraction transforming it to:
if ( -a < -b )
and now the optimizer is smart enough to realize that this can be transformed (ie: optimized again) into:
if ( a > b )
which means that the macro will execute with no delay. Best of all, your original source code is now clear and agrees with normal chess convention.

Ron

Or, even better, you can do like Glaurung/Stockfish, and enforce strong typing. If Rank is a specific type (enum Rank), then you can define all the operators you need. And if you only use the Rank operators, you can implement the representation as you want, it won't make any difference.

That being said, I tried it, and I got really annoyed with all the stupid C++ error messages, forcing you to use a lot of brute force type-casting, or defining a ton of obvious operators. So I got rid of all that and use int for everything now (file, rank, square, color, piece, castling rights, you name it...)

[ZirconiumX]

Ok - I was lazy originally. I had 4 values, mat1, mat2, mat3, mat4. Each of these was implemented as a multiplier of line. mat1 did line [0] and line [1], mat2 did line [2] and line [3], etc. I CLOPped using 161,000 games at 40/1+0.05, no quick stop algorithms here.

So I was given mat1 43, mat2 519, mat3 578 and mat4 320. As I had implemented it as the mat values were multiplied by the old line values to get the new values, I arrived at that.

Matthew:out

[ZirconiumX]

As for what happened to Durandal - https://github.com/ZirconiumX/Durandal is what happened to it. I have a commit to implement the infrastructure for boards and moves that I am working on.

Matthew:out

[Richard Allbert]

Yes, yes yes.... He's posted that over and over again, and there are countless 'go easy he's young' posts also. It's his choice to post private matters on a public forum.

13yrs is not an excuse to post non constructive criticisms of OS engines. It's high school age, four years from being able to drive.

[zullil]

13yrs is not an excuse to post non constructive criticisms of OS engines.

I agree. But perhaps his age should be considered in how we respond to his posts.

It's high school age, four years from being able to drive.

Four years is a long time when you're 13. (My daughters are 13 and 15.) I hope Matthew remains a part of this community, and continues to pursue his interests in chess programming.

[PK]

Having worked on a derivative of Sungorus for a year, I think I may say the following: Matthew, treat Sungorus as a framework, and a good one too. Search is clear and concise yet contains all the basic elements, the way staged generator is separated from search is just perfect, code is short. Whatever You do in Durandal, please don't spoil these features.

But every framework needs filling - this is how to use it. One of the first things I have done was to change all the stuff relating to piece/square tables. In original Sungorus they have a four-fold symmetry and the same table is used for White and for Black. You just cannot tune something like that in a meaningful way.

[mcostalba]

Matthew:out

Matthew, don't let people to intimidate you or make you resign from the forum. It would be a loss for everybody.

If there is a thing, here in the forum, that was never prevented to the people is to write cheap comments, so you are 100% allowed to do the same (it doesn't mean that you should aim at it). We have ton of it ! Almost daily, both in the form of silly comments (main forum) both in the form of technical idiocy (here in programming subforum). But among the pile of nonsense there is always also some illuminating and bright example/post, sometime even from the same people that wrote a nonsense in a previous post. This is how forum (and life) goes: it is not black and white. It is mostly gray, often black and very seldom same rare white pearl that makes us to forget all and be happy to be here.

I know you were criticizing the engine, looked as a simple bunch of code, not the author and even less the fact that the author released the sources.

Happy new 2013 to you and to everybody, Matthew:in !

Marco

[lucasart]

As for what happened to Durandal - https://github.com/ZirconiumX/Durandal is what happened to it. I have a commit to implement the infrastructure for boards and moves that I am working on.

Matthew:out

That's far more constructive and interesting! So you're really starting your own engine? A bit of advice (I looked at your git repo):
- I don't know what you're trying to do with hardware prefetch(), but that's not the starting point of writing an engine. Forget about all this hardware BSFQ, popcount, prefetch, and all that hype. Really not what you should focus on at step one of developpement,
- Your struct board is looking promising. You are absolutely right to begin with something simple, rather than bitboards. You will one day rewrite it to use magic bitboards, so make sure that your interface code is constant and stable. Make sure that you properly separate what is in the board and what manipulates a board. So that you can rewrite the whole board stuff without touching the rest.
- defs.h: use #include <inttypes.h> for portability, and only use these integer types
* char (1 byte)
* int (sizeof is plateform dependant) unsigned (is the same as unsigned int, an old "assume int" C legacy)
* uint64_t for unsigned long long (unsigned 64 bit)
* uint32_t if you need 32 bits (and not int, since sizeof(int) is plateform dependant)
* etc.
- guard your headers against recursive inclusion. Either with an ifdef mechanism, or simply a #pragma once. pragma once is not strictly portable, but I've never heard of a compiler that doesn't support it.

[ZirconiumX]

As for what happened to Durandal - https://github.com/ZirconiumX/Durandal is what happened to it. I have a commit to implement the infrastructure for boards and moves that I am working on.

Matthew:out

That's far more constructive and interesting! So you're really starting your own engine? A bit of advice (I looked at your git repo):
- I don't know what you're trying to do with hardware prefetch(), but that's not the starting point of writing an engine. Forget about all this hardware BSFQ, popcount, prefetch, and all that hype. Really not what you should focus on at step one of developpement,
- Your struct board is looking promising. You are absolutely right to begin with something simple, rather than bitboards. You will one day rewrite it to use magic bitboards, so make sure that your interface code is constant and stable. Make sure that you properly separate what is in the board and what manipulates a board. So that you can rewrite the whole board stuff without touching the rest.
- defs.h: use #include <inttypes.h> for portability, and only use these integer types
* char (1 byte)
* int (sizeof is plateform dependant) unsigned (is the same as unsigned int, an old "assume int" C legacy)
* uint64_t for unsigned long long (unsigned 64 bit)
* uint32_t if you need 32 bits (and not int, since sizeof(int) is plateform dependant)
* etc.
- guard your headers against recursive inclusion. Either with an ifdef mechanism, or simply a #pragma once. pragma once is not strictly portable, but I've never heard of a compiler that doesn't support it.

I will be honest - I don't intend to use bitboards, Lucas.

I plan to use an implementation of Vincent Diepeveen's Table-based move generator and/or a vector attacks array to generate moves, because it is something that has stood the test of time. It is relatively simple to implement, and once implemented I can just leave it until there is a major breakthrough in Vector Attack move generation.

The prefetch is intentionally pointless, and is mostly a joke. I might remove it later on.

I will convert to inttypes.h.

I already use include guards IIRC.

There will be a slight pause in development as computer partitioning is messed up. Keep calm, reach for the Debian install disk and watch the blinkenlights.

Matthew:out