[computer-go] Caching of local search in NeuroGo?

[Chrilly]

>
> Markus Enzenberger is right in saying that it's faster to recompute 
> ladders than trying to cache their results. For 3-liberty problems  it's a 
> little different. Still, I wouldn't try to solve this problem  by caching.
>
> Let me give you a hint: instead of approaching this from the tactical 
> search and try to decide whether it has become invalid, try seeing it 
> from the point of view when a move is played which tactical searches  in 
> may invalidate. Don't expect to find an easy solution though, it's  a lot 
> of work to get this even close to working satisfactorily.
>
> The other thing to do is trying to avoid doing 3-liberty search 
> altogether. You may find that the most expensive 3-liberty searches 
> actually don't give you any relevant information, so only do them  when 
> really necessary.
>
I think its necessary to extend ladders at least to Getas. See 
Tesuij-software :-). I have the intention to do a very shallow 3libs search. 
E.g. 3 plies 3 libs, if it does not result in a ladder, give up. This should 
handle some frequent tactical situations with a string already surrounded or 
near the edge. One could handle this by the eval. E.g. I use the PON-number 
concept (1,2,3th Dame points). This number gives usually the right answer 
that the enclosed string is weak/dead. But as I do the tactical search 
first, dead strings/groups are marked and they do not disturb anymore the 
group-classification process. In case of the PON-Number one has to iterate 
again, because the string has been marked dead after the group-formation 
process and it might change the groups structure. But even this iteration is 
probably faster than doing a local search. Its only logically simpler.
You are right, the main problem in 19x19 is the board size. Even simple 
calculations which are done on every intersection take very long. The 
100K/sec. was certainly too optimistic.

Chrilly