"Good ideas" that may not work

[JVMerlino]

In my chess program I tried out several "good ideas" that did not improve performance:

1) Mate distance pruning
2) Futility pruning in Quiescence search
3) LMR
4) Hash table ( This I have to try out again)
5) History heuristic (not killer moves)
6) lazy evaluation when normal evaluation is fast enough
7) alfa beta instead of pvs
8) MTD(f)
9) Aspiration windows

My understanding is that #2, 3, 4 and 9 should give noticeable improvement if implemented correctly, even with the most basic implementation.

By your own definition, #6 isn't helpful when the normal (full) eval "is fast enough". Where you have a large and complex evaluation, you can save time via a well-designed lazy eval. An excellent introduction to the topic with an implementation example can be found here:
http://www.top-5000.nl/authors/rebel/chess840.htm

I'm a bit confused by your #7, as PVS is an enhancement to the basic AlphaBeta implementation.

#1 and 5 are debatable as to their merits and are probably rather engine-dependent on their benefit.

I am unable to comment on #8, as I've never tried it.

However, they are definitely all "good ideas", despite your assertion that they are not simply because you tried them without success.

jm

[Steve Maughan]

(...)
Are there more good ideas that may not work ?
(...)

There are hundreds.

I find alpha-beta is hopeless if you get alpha and beta mixed up. Even mini-max you can have problems if you forget to alternate between "min" and the "max".

Seriously, it's all about the implementation

Steve

[Henk]

(...)
Are there more good ideas that may not work ?
(...)

There are hundreds.

I find alpha-beta is hopeless if you get alpha and beta mixed up. Even mini-max you can have problems if you forget to alternate between "min" and the "max".

Seriously, it's all about the implementation

Steve

I miss detailed descriptions or algorithms of ideas. Also some combinations won't work. Futility pruning in mtd(f) ?? mtd(f) and fine grained evaluation ?? Aspiration windows and pvs ? Also the order of application might be important.

I also wonder if I can use hash table with multiple threading.

[Volker Annuss]

I miss detailed descriptions or algorithms of ideas.

Me too. Please show us that you made serious attempts to write a chess engine.

[Henk]

I miss detailed descriptions or algorithms of ideas.

Me too. Please show us that you made serious attempts to write a chess engine.

Why ? I'm a troll you know. Don't feed me I'm not hungry.

[lucasart]

I miss detailed descriptions or algorithms of ideas.

Me too. Please show us that you made serious attempts to write a chess engine.

Why ? I'm a troll you know. Don't feed me I'm not hungry.

Could you be, by any chance, the reincarnation of Matthew Bardes, under a new fake name ?

I don't see any other explanation.

[velmarin]

Could you be, by any chance, the reincarnation of Matthew Bardes, under a new fake name ?

I don't see any other explanation.

You are a troll, and a bad person.

Matthew is a thousand times better than you, you should withdraw that accusation and respect member Matew .


If you do not like the subject, ignore,
but stop feeling so superior.
Other members like.

Sure maybe you search this member Henk went out,
as it did with Matew, it harassment.

[Don]

In my chess program I tried out several "good ideas" that did not improve performance:

1) Mate distance pruning
2) Futility pruning in Quiescence search
3) LMR
4) Hash table ( This I have to try out again)


Are there more good ideas that may not work ?

I like to have warnings in advance.

5) History heuristic (not killer moves)
6) lazy evaluation when normal evaluation is fast enough
7) alfa beta instead of pvs

8) MTD(f)
9) Aspiration windows

Wow, if none of these improved performance your program really must have some serious bugs.

You should throw it all out and carefully start from scratch - there are certain things that should work without question and focus on them.

Here is what you should focus on:
1. Hash table
2. PVS
3. LMR
4. Null move pruning.

Start with those and get them right - then call us in the morning.

[JuLieN]

Also, many of those ideas rely on a decent move ordering to produce good results. But the single most important item in this list is definitely the hash table. This one always gives something.

So :
1- be sure to have a 100% debugged alpha-beta, with a not too simple evaluation function (if it's too simple you'll have problem getting a good move ordering).
2- start to improve your move ordering and see how efficient your alpha-beta now is.
3- now add hash-tables and see how your engine now flies !
4- now is time to add null-move and get 2/3 extra plies.
5- then add LMR (be careful : this one really needs a good move ordering!)

Edit:
Ah, Don and I disagree on LMR and Null-move ordering... My tip: look at our engines' ratings and follow the list of the author of the highest rated engine...

[Don]

Also, many of those ideas rely on a decent move ordering to produce good results. But the single most important item in this list is definitely the hash table. This one always gives something.

So :
1- be sure to have a 100% debugged alpha-beta, with a not too simple evaluation function (if it's too simple you'll have problem getting a good move ordering).
2- start to improve your move ordering and see how efficient your alpha-beta now is.
3- now add hash-tables and see how your engine now flies !
4- now is time to add null-move and get 2/3 extra plies.
5- then add LMR (be careful : this one really needs a good move ordering!)

Edit:
Ah, Don and I disagree on LMR and Null-move ordering... My tip: look at our engines' ratings and follow the list of the author of the highest rated engine...

Yes, LMR belongs last on that list. Even before the list he should make sure the search is correct - nothing fancy. I suspect that he also doesn't have quies search correct.

One thing to note - one you have a reference version that you trust and checks out, then EVERY new change should be thoroughly tested against it. Don't make several changes at once but work very incrementally because otherwise you will get bugs that will live for months or years and perhaps never discovered. Komodo development is a very carefully process of incremental change and then reverting back if we are not sure. If we think something should work we will put a lot of time into it before giving up.