Saving killer moves...

[PK]

If I remember correctly, at some relatively early stage of Rodent developement, I have tested switching off entire history update (history counters, which have been calculated differently at that time, plus killer moves). Never tried to apply different approach to history and killers. Back then it gained a little, with different history mechanism it can already be another way round.

Also, there is an inconsistency in Rodent's code. Even though the engine updates history and killers also upon beta cutoff from hash table, applying in check test there produced a small loss.

[MOBMAT]

In most schemes, good captures are processed before killers, so there isn't a reason to store captures as killers since the move would already have been tried.

hum, now it makes me think that if for some odd reason a 'bad' capture happened to raise beta (would it ever?), then the rule should be refined to really exclude only those category of capture moves that have been tried.

Don't you just love the fuzzy logic that goes into each implementation?

[PK]

Bad capture raising beta is a special case of a sacrifice Perhaps it would be worthwhile to use some kind of "bad capture killer" in a separate slot, but then such situations might be highly tactical and therefore transient. Might as well test it

[xr_a_y]

Bad capture raising beta is a special case of a sacrifice Perhaps it would be worthwhile to use some kind of "bad capture killer" in a separate slot, but then such situations might be highly tactical and therefore transient. Might as well test it

I'm trying to tune this right now. Any recent advice on the subject?

Minic was already using the "bad cap can be killer" paradigm but now I'm trying to use a dedicated killer table for such killer cap ...