I'm pretty happy that my program has no serious bugs in it now: it doesn't crash and it's managed a few draws against gnuchess. I also think I have all the logic of interfacing with a gui sorted in my head -- I have set it going online through xboard a few times. So I've been thinking about tuning ...

Hi,

I did have a go at hashing the PV today, before I read your reply.

To do my new PV thing, I wrote a c++ class that is basically just a c++ vector as a private member (which can just be arbitrarily extended) but I have overloaded the [] and + operators so that if I do something like pvline ...

I've spent the last few days experimenting with this; I don't think what I have done is exactly a triangular PV table, but I have passed pointers (I'm using C++, so I used a reference to a std::vector) to each call of my search function, and subtended that vector to the best move if a node falls ...

.... That's why the so-called triangular array approach is so much better.

I have been in half a mind to do that, but my understanding was that developers had abandoned that approach in favour of storing the PV in the transposition table (or a separate PV hashtable). But to my mind, the problems ...

Hi,

Sorry to resurrect an old thread, but my problem relates to my original post; seems silly to start a new thread.

I am, happy with how my engine is working now, having solved most of the obvious bugs. Except one, which continues to defeat me....(I'm not even certain it's a bug, or an expected ...

Ok, thanks for your reply. I think I am being a bit blinded by my ambition for my engine to get to a similar nominal search depth to the engine I am testing against, which is probably akin to comparing chalk and cheese.

So, I think I will probably just forget about that obsession, tie up a few ...

I'm not certain if I am implementing search extensions properly. Although my argument may sound very confused.

Admittedly, the testing for my changes is less than scientific at the moment, as it plays so badly, spending weeks waiting for it to play thousands of games seems a little pointless when ...

Thanks for your reply.

Lower depth than what?

Lower depth than the current PV.

It looks like I probably have some big misunderstandings about what is happening during the search, so this evening I have stripped off most of the bells and whistles. I have commented out all move reductions ...

PV nodes have an exact score, which can be used with any window. So the only reason to search a PV node that was already in the table is that depth in the table is lower than the depth that you need now. So the situation you sketch simply cannot occur. You either take a hash cutoff before searching ...

if (TT[g%Nh].stale()) TT[g%Nh]=x;

if this is from an old search, just replace it on the spot. What, precisely, does stale() test? Does stale mean it came from the last full search from the root, or just from a previous iteration, possibly in this search??


Stale means it came from the last full ...