Linux port of newer versions of TogaII

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Eelco de Groot
Posts: 4279
Joined: Sun Mar 12, 2006 1:40 am
Location: Groningen

Re: Linux port of newer versions of TogaII

Post by Eelco de Groot » Tue Nov 25, 2008 7:50 pm

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.

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;
			value = sort->value; // history score
			if &#40;value < HistoryValue&#41; &#123;
				reduced = true;
				   if &#40;UseExtendedHistory && &#40;value < &#40;HistoryValue * 3 / &#40;depth + depth % 2&#41;) && depth >= 5&#41;)&#123;
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;

			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.   
				reduced = true;
			&#125; else not_history_reduced++;


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

Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Linux port of newer versions of TogaII

Post by bob » Thu Nov 27, 2008 4:47 pm

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

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

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...


Toga Multi PV?

Post by glorfindel » Wed Dec 17, 2008 12:25 am

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	
= &#40;0.00&#41;	0&#58;00	0/0	
= &#40;0.00&#41;	0&#58;00	0/0
In search.h there is the declaration
const int MultiPVMax = 10;

Any ideas?

Posts: 2210
Joined: Sun Sep 28, 2008 11:50 pm

Re: Toga Multi PV?

Post by Michel » Wed Dec 17, 2008 7:10 am

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.


Re: Toga Multi PV?

Post by glorfindel » Thu Dec 18, 2008 8:22 pm

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

Post Reply