Linux port of newer versions of TogaII

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

User avatar
Eelco de Groot
Posts: 4561
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Linux port of newer versions of TogaII

Post by Eelco de Groot »

Harald Johnsen wrote:
EdG: value >= alpha seems a correct bugfix here?
No, the correct code is value > alpha.

Also, testing value > alpha and value >= beta is the same as long as you do not reduce the search in PV nodes (in non PV nodes we have beta == alpha + 1).
Only some versions of Toga are reducing in pv nodes. It is in those reduced pv nodes that there can be a problem.

HJ.
Hello Harald, yes I think you are right. For default settings it will work as is. The problem is that in all the Checkov settings Toga Extended History pruning that Thomas Gaksch invented is swithched on, but reduced can only be set once. I don't do History pruning in PV nodes but with EHP I can reduce two plies, now the re-search only takes that back by one ply. I do set the 'reduced' flag but there is not yet a different flag for Extended History Pruning.

Also I think it is fair to say that if the reduced seach is already close to but not larger than alpha, you should still do a re-search because it can easily cross over. Because I often reduce two plies the condition >= alpha is often better I think, when real value may exceed alpha, and additional reason is I recently did even a third ply reduction if more than five moves were not reduced by a third ply and an approximate search for this node exceeded beta (alpha + 1 as you say so not so rare). I did not have a separate flag for this third reduction so that will make it likely I should see more differences now with >= alpha than regular Toga that only reduces one ply.

I probably should make the reduced flag into a counter!


My History Reductions are, with some left-over codes:

Code: Select all


	if (UseHistory && depth >= HistoryDepth && node_type != NodePV) {
		if (!in_check && played_nb >= HistoryMoveNb && new_depth < depth ) &#123;
			ASSERT&#40;best_value!=ValueNone&#41;;
			ASSERT&#40;played_nb>0&#41;;
			ASSERT&#40;sort->pos>0&&move==LIST_MOVE&#40;sort->list,sort->pos-1&#41;);
			value = sort->value; // history score
			if &#40;value < HistoryValue&#41; &#123;
				ASSERT&#40;value>=0&&value<16384&#41;;
				ASSERT&#40;move!=trans_move&#41;;
				ASSERT&#40;!move_is_tactical&#40;move,board&#41;);
				ASSERT&#40;!move_is_check&#40;move,board&#41;);
				new_depth--;
				reduced = true;
				   if &#40;UseExtendedHistory && &#40;value < &#40;HistoryValue * 3 / &#40;depth + depth % 2&#41;) && depth >= 5&#41;)&#123;
					   new_depth--;
				   &#125;
				   
					   /*
if &#40;value < &#40;HistoryValue * 4 / &#40;depth + depth % 2&#41;) && depth >= 14&#41; new_depth--;

					   &#91;EdG 20-01-2008&#58; Experimental extra &#40;third!) reduction, too much&#93;

				  */
			&#125;
			if (&#40;not_history_reduced > 5&#41; && approximate_beta_cutoff&#41; &#123; // The approximate search was > beta but not enough for 'brute pruning' directly, also there was no nullmove cutoff.   
				new_depth--;
				reduced = true;
			&#125; else not_history_reduced++;
		&#125;

Thanks!

Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Linux port of newer versions of TogaII

Post by bob »

Michel wrote:You are right that this is an illegal access.

However as Zack pointed out it seems that the argument colour=-2 in the function
invocation

Code: Select all

see_rec &#40;alists=0xb0080a88, board=0x38b48, colour=-2, to=153, piece_value=0&#41;
can only come from board corruption (colour is the colour of a piece which is supposed
to be 0 or 1, the relevant macros are in colour.h).

I fear that the only solution is to put in printf's with board_is_ok at the places which occur in the stacktrace to see when and where the board corruption occurs precisely.
WARNING: the default board_is_ok does nothing. You have to set UseSlowDebug = true
in board.cpp

Regards,
Michel
Let me add another point. I am not sure why, but it seems that gcc/gdb and icc/idb have problems for unknown reasons with 64 bit programs. I often see impossible values displayed when using the above debuggers, yet when I use printf's, the values are not mangled as they are shown to be from debugger output. It seems to work OK on my 32 bit machines however so there is some sort of issue hidden in the 64-bit debuggers...
glorfindel

Toga Multi PV?

Post by glorfindel »

I cannot get Toga to display more that one variation when analyzing. I think Toga is supposed to support this feature. I am using it in the Shredder Classic java interface and in Scid.

Here is an example of output in the Shredder interface with 3 variations

Code: Select all

Toga II 1.4.1SE .

+&#831; (-0.52&#41;	16	35...Qb4 &#40;2/36&#41;	1744 kn/s

35...Qc2 36.Kg1 a4 37.a3 Qc1+ 38.Kg2 Qxa3 39.Rxc6 Qb4 40.Rxc5 Qe4+ 41.Kf1 Rd8 42.Ke2 Qb4 43.Kf3 a3 44.Ra5 Rd3 45.Qa8+ Qf8 46.Qxf8+ Kxf8 
+&#831; (-0.52&#41;	0&#58;08	17/42	
35...
= &#40;0.00&#41;	0&#58;00	0/0	
35...
= &#40;0.00&#41;	0&#58;00	0/0
In search.h there is the declaration
const int MultiPVMax = 10;

Any ideas?
Michel
Posts: 2272
Joined: Mon Sep 29, 2008 1:50 am

Re: Toga Multi PV?

Post by Michel »

I cannot get Toga to display more that one variation when analyzing. I think Toga is supposed to support this feature. I am using it in the Shredder Classic java interface and in Scid.
MultiPV is broken in Toga. It is supposed to have been fixed in Cyclone and Deep Learning Toga.
glorfindel

Re: Toga Multi PV?

Post by glorfindel »

Yes, it is working in The Mad Prune, thx.