I notice that stockfish will happily grab a pawn when it already has 5 in hand, which isn't usually productive.
I wonder if it might be worth assigning a lower in hand value for pawns above a certain threshold.
I once tried introducing quadratic bonuses (in material.cpp) based on having a variety of bonuses in hand or based on the total piece count in hand, and my implementation didn't seem to have any effect.
@ddugovic I believe that your idea should work, but last time you started the tuning session from non-zero values with small ranges, so they did not change much. I think that starting tuning from a version that is functionally equivalent to master (quadratic in-hand bonuses equal to zero) and using wide ranges (sth. like [-1000, 1000], since they are divided by 16) should help to find parameter values that outperform master.
@ianfab I have created a new tuning session. Please let me know if I have overlooked anything else...
@ddugovic The default parameter range is [0, 2 * v] if the starting value is v, so you have to explicitly set the range if you start from zero using SetRange, i.e. TUNE(SetRange(-1000, 1000), QuadraticOursInHand, QuadraticTheirsInHand);, otherwise the parameters can not be tuned as far as I know.
Thanks, that makes sense & points out a flaw in my parameter values (using c=23.6 rather than c=236). I have created a new tuning session.
The patch with tuned quadratic bonuses passed STC: http://35.161.250.236:6543/tests/view/58bbe2c06e23db7956a14291
Your patch has names like QuadraticInHand, but that seems more for covariant terms of piece synergy.
That's definitely a great concept and potentially useful, but my original idea was about the decreasing usefulness of tons of pieces in hand, especially tons of pawns.
@isaacl The diagonal elements in QuadraticOursInHand take account of that. E.g. the element [1][1] of the array corresponds to the evaluation term -27 * number_of_pawns^2 / 16, which means that the piece value of the nth pawn in hand is decreased by -27 * (2n - 1) / 16. So I think that his patch is a generalization of your idea.
The names are borrowed from the imbalance parameters for pieces on the board.
Glad to see it passed STC! I have created an LTC test.
Oops, can @isaacl or @ianfab confirm if my comment is incorrect?
https://github.com/ddugovic/Stockfish/commit/ef67f94c5cd7350daa4aac5509b4772e47778159#diff-c74eb33120f9e932f7cfc0be07fa91d2R297
@ddugovic If you refer to the "our pieces" comment, I do not see anything wrong with it since it refers to https://github.com/ddugovic/Stockfish/commit/ef67f94c5cd7350daa4aac5509b4772e47778159#diff-c74eb33120f9e932f7cfc0be07fa91d2R385.
pieceCount[Us][pt1] * v; is the wrong extra factor for pieces in hand. Instead, you need a loop where the new factors are added wtih bonus += pieceCountInHand[Us][pt1] * v
You are right, I have not read the code carefully enough. I thought that the code was intended to do what I tried to explain. Since it does not, we might want to introduce and tune new arrays for that idea.
Maybe so... in any event, "covariant" is more accurate than quadratic.
Either way given this condition it seems likely to me that Isaac's suggestion (and a retune of the constants) could outperform this code although I'm unsure what sort of test parameters we'd want to use...
Well, if it's possible to tune a covariant table I think that could be valuable. It just has to allow true quadratic terms for pieces in hand, which requires a separate loop.
For example, 2 * knight + 1 pawn is often much more valuable than either ones on their own. (in general, knight + diag is better than either only diags or only knights).
Note also that you should really have a 3rd zh matrix, terms between our pieces in hand and our pieces on board.
I'd suggest adding that, but then we might be able to separately to reduce the number of terms since material on board basically doesn't change (besides promotion).
Actually, how about adding an our drop x our board matrix and removing our drop x their drop matrix.
4 cross terms is usually enough except when there's a promotion. In that case it's probably more better to keep personal synergy accurate. Otherwise dropping a piece on board will count as losing synergy.
These different kinds of cross terms definitely contain some information, but I think we should try to have as few terms as possible, since there is much correlation between many terms, and it might be difficult to tune them.
What do you think about using the total piece count (on board+in hand) for QuadraticOurs and QuadraticTheirs, since this helps to evaluate general imbalances like queen for two minor pieces regardless of whether they are in hand or on the board. Then we could add QuadraticOursInHand as defined in #273 to take account of what you said about having tons of pawns in hand, etc. I think that this would be the most stable setup of higher-order terms, and we would only need one additional array (or two if we include QuadraticTheirsInHand).
@ianfab I think that is an excellent design with minimal added complexity and likely would defeat #273 in tests. If we are all agreed upon this approach I suppose this tuning and subsequent STC/LTC don't need to complete?
The tuning results look reasonable to me, so I am not opposed to testing them, but if you are confident that my idea will perform well, I am also fine with trying it first. Either way, I won't be able to write any code before Sunday, so if you want to submit tuning sessions or tests for any of the approaches, please go ahead. (The regression tests in the queue have negative priority, so they will only be executed if the queue is otherwise empty.)
I think having #273 in place first might help us tune your idea (or test that it's well-tuned) so I'll submit an STC test.
@ianfab's idea sounds good to me too. I'd skip the QuadraticTheirsInHand array for now, just QuadOurs, QuadTheirs with total piece counts, and a QuadOursInHand for drop synergy.
Shoot, I thought I had fixed this code before submitting it for testing. Apologies for my confusion; may I resubmit it with the corrected code?
@isaacl My attempt to rewrite the bonus formula (to include in-hand pieces with on-board pieces) failed.
:-( OK I'll send you a code patch adding the in hand pieces to board pieces. was waiting to see if your rewrite would work
Simply amazing, after re-tuning (atop latest master which has no ceiling for king danger) adding the pieces together passes STC in just 2480 games! Onward to LTC!
http://35.161.250.236:6543/tests/view/58ef70a26e23db2fa8081051
http://35.161.250.236:6543/tests/view/58efeeb56e23db2fa8081054
!!!!馃槉
Most helpful comment
pieceCount[Us][pt1] * v;is the wrong extra factor for pieces in hand. Instead, you need a loop where the new factors are added wtihbonus += pieceCountInHand[Us][pt1] * v