pinned pieces in eval

[jacobbl]

I think this is a typical way of thinking that an idea isn't good because the cost of speed is bigger than the gain of the idea (either eval, sorting, pruning and so forth).

But I'm thinking if you have a lot of ideas were you nearly get enough benifit from the Idea, but not quite enough to compensate for the speed loss, the speed loss will decline for each idea, but the gain will remain. Consider the following example:
We have an engine which calculates 1Mn/s. We have 10 independent not corelated ideas which will each cost 0.25s per million nodes. Each idea individually results in a loss of 1 ELO point because of the speed loss. So when testing each idea, every idea is discarded. But if we would implement all ideas at once the speed loss would be much smaller.

Idea Time for 1Mn N/s Speed loss
0 1,00 1 000 000
1 1,25 800 000 20 %
2 1,50 666 667 17 %
3 1,75 571 429 14 %
4 2,00 500 000 13 %
5 2,25 444 444 11 %
6 2,50 400 000 10 %
7 2,75 363 636 9 %
8 3,00 333 333 8 %
9 3,25 307 692 8 %
10 3,50 285 714 7 %

On the first idea we would lose 1 ELO, but on the second idea we would probably gain some points, and the last ideas would be highly profatable.

I believe this would be particulary true on very fast engines where every idea will have a great cost because of the speed loss.

But for the moment the only thing I can contibute with is a slow engine , but still it's far more fun to program an engine when a lot more of the ideas yield a positive result

[mcostalba]

My 2 cents on this is that if an idea is even not able to overcome the 1-2 ELO loss due to speed than is better to keep it out.

I'd prefer to keep the sources as simple and easy as possible, so I am not comfortable to add tens of small gain ideas to have at the end, say, 5-10 ELO increase. I have the feeling that this is not the way to go in the long term: after some years of developing you find yourself with tons of dubious code and engine starts to feature creep at the point that long time authors decide to trash the baby and start from scratch with a new engine, typically much more streamlined and simple...and it happens it is also stronger

So the bottom line is that IMHO keeping an engine simple and straightforward _is_ a value, a value I am glad to spend 10, 20 or even 30 ELO points on.

[Joost Buijs]

I am about to include a pinned and attacked piece term in my evaluation function. I have a question about this feature because i doubt if it is usefull.
Pierre

Some time ago I added a pinned and attacked piece term to my evaluation function and this certainly has a positive effect on playing strength.
I have to calculate the pinned pieces for my move generator anyway, since I'm calling the evaluation function at every node I can combine this so it doesn't cost much time.
I'm even thinking about adding a term for pieces pinned to the queen.

[Joost Buijs]

My 2 cents on this is that if an idea is even not able to overcome the 1-2 ELO loss due to speed than is better to keep it out.

This is the whole problem with bullet testing, things that will cost you time can give you an Elo loss at very short time controls while on the other hand it can have a positive effect at much longer time controls.

[Mincho Georgiev]

My question is why pin-detection to get applied to the evaluation function.
I did this for see() 2 weeks ago or so, but the only benefit is that some of the "bad" captures are getting isolated from pruning or reduction. There is a trade off however, because pin and discovery slows down the execution a lot.
So my question is, why pin-detection in the evaluation, why not in quiescence search instead. I am extending the qsearch in check, could be good idea not to terminate qsearch when piece is pinned (or hanging) under certain conditions to eliminate blow-up (which requires a lot of tuning and testing). Besides, lets not forget that the actual leaf in our programs is the static evaluation. Why make it more "dynamic". The Qsearch idea however do sound at least to me.

[jacobbl]

I'm not sure if I managed to make my point. I was not talking about an idea of 1-2 elo points, but of an idea of maybe 25 elo points with speed loss costs of 26 points. This might be some costly evaluation term such as better king saftey/attack, passed pawn evaluation or some advanced mobility. I don't believe this messes up the code.

My point was that even if any of these ideas is bad individually, they might be good combined because the speed loss will decrease as the engine gets slower (as I tried to explain with my table in my last post) , but the gain will remain.

[micron]

I'm not sure if I managed to make my point. I was not talking about an idea of 1-2 elo points, but of an idea of maybe 25 elo points with speed loss costs of 26 points.
My point was that even if any of these ideas is bad individually, they might be good combined because the speed loss will decrease as the engine gets slower (as I tried to explain with my table in my last post) , but the gain will remain.

Ah, that's clear now.

My engine may be an example of your principle. It evolved for speed (5.5 Mnps), partly by discarding anything attack-based in eval(). When I attempt to add mobility or proper king safety or pin detection, the slowdown negates any Elo gain. Perhaps I should try introducing them all at the same time.

Robert P.

[mcostalba]

I'm not sure if I managed to make my point. I was not talking about an idea of 1-2 elo points, but of an idea of maybe 25 elo points with speed loss costs of 26 points. This might be some costly evaluation term such as better king saftey/attack, passed pawn evaluation or some advanced mobility. I don't believe this messes up the code.

My point was that even if any of these ideas is bad individually, they might be good combined because the speed loss will decrease as the engine gets slower (as I tried to explain with my table in my last post) , but the gain will remain.

An idea worth 25 ELO points, say at fixed depth search, is a good idea, no matter what. The problem is to find ideas worthing 25 ELO points I don't think is so easy. Do you have some examples ?

If instead you have written those numbers just as examples to better express your point, then yes, I agree that testing at blitz times could filter out some good stuff that could be instead detected at longer time controls. The point is that or you have an university behind you that grants you for free usage of a cluster or this seems to me just theoretical discussions.

[Uri Blass]

So the bottom line is that IMHO keeping an engine simple and straightforward _is_ a value, a value I am glad to spend 10, 20 or even 30 ELO points on.

In this case it may be better not to allow promotions in the search except queen promotions(it is going to make the code more simple and you are not going to lose a lot of elo points)

Note that it is not my opinion and I think that it is better if engine considers all the promotions even for the price of 1 or 2 elo points.

Note that I decided that I do not plan to use stockfish because it seems that the developers try to make the engine simple at the cost of not making it user friendly.

For example in analysis it seems that stockfish does not show all the fail high and fail low and it is important information that I would like to know if I give the computer to analyze for many hours in order to decide if to stop the analysis or to continue it.

Of course people are free to change the code but I do not plan to do it so if people do not plan to change the engine to show more information then I probably plan not to use it.

[jacobbl]

I'm not saying I have a lot of potensial 25 points gains lying around, but for my engine Sjakk which is about 800 points behind Stockfish there should be some...

My whole point was that an idea that doesn't work for a fast engine might work for a slow engine. So if two engines are equally strong it will be easier to improve the slowest one. So adding evaluation which slows down the engine and is elo neutral is positive. (But I do agree on having a clean code.)

Maybe this is just wishful thinking since my engine is really slow (160 Kn/s on a i7 3.4 GHz)