about hash tables and illogical behaviour of chess programs

[mcostalba]

in razoring we have (among others) this condition:
refinedValue < beta - razor_margin(depth)

In static null move pruning we have this condition:
refinedValue >= beta + futility_margin(depth, 0))

Both conditions depend on refinedValue, the estimated value for the current position. But this estimate sometimes is rather accurate, and othertimes it's rather unaccurate. The above conditions nonetheless rely on this value with the same condition.
That's what's eye-catching to me.

Of course an immediate patch could be something along the line of:

Code: Select all

bool accurate = tte && (depth - tte->depth() < 3 * OnePly);

refinedValue < beta - razor_margin(depth) + (accurate ? extraRazorMargin : 0);

refinedValue >= beta + futility_margin(depth, 0)) - (accurate ? extraFutilityMargin : 0);

...but this needs test and is not very nice, at least to my eyes

[Ralph Stoesser]

Ugly.

Apropos, what on earth does this constant "45" mean?

Code: Select all

futilityValueScaled =  ss[ply].eval + futility_margin(predictedDepth, moveCount)
                               + H.gain(pos.piece_on(move_from(move)), move_to(move)) + 45;

I only know "42", the real answer to life, universe and everything.

BTW, I'm still tempted to try out your ugly code ...

[zamar]

Ugly.

Apropos, what on earth does this constant "45" mean?

Code: Select all

futilityValueScaled =  ss[ply].eval + futility_margin(predictedDepth, moveCount)
                               + H.gain(pos.piece_on(move_from(move)), move_to(move)) + 45;

H.gain() returns estimate based on statistical data, we form a sort of upper bound of it by adding 45.

[mcostalba]

Ugly.

Apropos, what on earth does this constant "45" mean?

Code: Select all

futilityValueScaled =  ss[ply].eval + futility_margin(predictedDepth, moveCount)
                               + H.gain(pos.piece_on(move_from(move)), move_to(move)) + 45;

H.gain() returns estimate based on statistical data, we form a sort of upper bound of it by adding 45.

Perhaps we could add the 45 inside the futility_margin() term ?

Should be a "no functional change" and we make Ralph happy

[Sven]

Ugly.

Apropos, what on earth does this constant "45" mean?

Code: Select all

futilityValueScaled =  ss[ply].eval + futility_margin(predictedDepth, moveCount)
                               + H.gain(pos.piece_on(move_from(move)), move_to(move)) + 45;

H.gain() returns estimate based on statistical data, we form a sort of upper bound of it by adding 45.

Perhaps we could add the 45 inside the futility_margin() term ?

Should be a "no functional change" and we make Ralph happy

Since the 45 seems to be related more to the H.gain() than to the futility_margin() term according to Joona, both Ralph (I guess) and myself would be happy if you'd add the 45 to the H.gain() internally

Sven

[mcostalba]

Since the 45 seems to be related more to the H.gain() than to the futility_margin() term according to Joona, both Ralph (I guess) and myself would be happy if you'd add the 45 to the H.gain() internally

Hi Sven,

I am very glad to speak about code changes with you, Ralph or everybody else interested. I only ask one thing if possible: before to ask a code modification please do read the code.

You are not a casual troll asking no-sense on main forum, I think you are very serious and prepared, that's the reason I am asking you to read the source before to post.

If you do this you see that gain has a clear and obvious definition that is the difference in static evaluation between two consecutive nodes. So I am sure you agree with me that adding a constant dropped from nowhere in such context makes no sense, instead futilitty pruning are just values of a table, so it's there where adding a 45 makes no harm in code readibility.

The bottom line is: if you just want to suggest new features, report bug, express opinions, then it is ok everything you write. But if you are pointing at specific code changes then please do read the actual code _before_ to post.

[Sven]

Since the 45 seems to be related more to the H.gain() than to the futility_margin() term according to Joona, both Ralph (I guess) and myself would be happy if you'd add the 45 to the H.gain() internally

Hi Sven,

I am very glad to speak about code changes with you, Ralph or everybody else interested. I only ask one thing if possible: before to ask a code modification please do read the code.

You are not a casual troll asking no-sense on main forum, I think you are very serious and prepared, that's the reason I am asking you to read the source before to post.

If you do this you see that gain has a clear and obvious definition that is the difference in static evaluation between two consecutive nodes. So I am sure you agree with me that adding a constant dropped from nowhere in such context makes no sense, instead futilitty pruning are just values of a table, so it's there where adding a 45 makes no harm in code readibility.

The bottom line is: if you just want to suggest new features, report bug, express opinions, then it is ok everything you write. But if you are pointing at specific code changes then please do read the actual code _before_ to post.

I have read the code actually, and I did it long before that post above. It is possible, though, that I did not do it carefully enough at the moment I wrote the above. The point is, as I wrote, I based my comment on the statement of Joona who has probably read the code, too His statement was that "H.gain() returned an estimate based on statistical data". Therefore I did not think even for a tiny moment about putting in question what he wrote, which may be my only fault according to your opinion ...

In fact, after looking into the code a second time, I still believe that Joona is right. The H.gain() function does *not* return just the difference between two consecutive evals, it is based on the gains table which collects some kind of maximum eval delta over time. You may be right in stating that putting that "45" constant into the code that manages the gains table could reduce its readabilty, so I accept that argument against it, of course.

Sven

[jwes]

Ugly.

Apropos, what on earth does this constant "45" mean?

Code: Select all

futilityValueScaled =  ss[ply].eval + futility_margin(predictedDepth, moveCount)
                               + H.gain(pos.piece_on(move_from(move)), move_to(move)) + 45;

I only know "42", the real answer to life, universe and everything.

BTW, I'm still tempted to try out your ugly code ...

It seems that this at least should be a named constant. It would be easier to experiment with if it had a name that indicated its purpose. Who knows, maybe 42 would be stronger than 45.

[Ralph Stoesser]

Or just add Joona's comment to the source code.
Btw. @Joona: Thank you for the clarification.


I have another question about the new search code.

Have you tried to use qsearch() instead of evaluate() as the basic node value estimate

[zamar]

Or just add Joona's comment to the source code.
Btw. @Joona: Thank you for the clarification.


I have another question about the new search code.

Have you tried to use qsearch() instead of evaluate() as the basic node value estimate

I've thought a lot about it, but never tried. In fact I've spend a lot of time to planning "depth-R" scout search for pruning decisions in higher depths (which is just a generalization of what you are proposing).

The problem is of course that it's very expensive, but another great problem is those scout searches (also pure qsearch!) can have nasty side effects to transposition table, so it's again one of those things which (I believe) has a lot of potential, but which are irritatingly hard to get right.