mcostalba/Stockfish — comment on commit 5c8af7ccb8f59f901740d5a8f4a9270f69487583
File:  line 0
By mcostalba:

Hi Eelco,

nice to know the casting to uniform type works for you. I agree with
you, it is not a clear advantage over using old macro, but sometime a
function can catch some bugs where a macro can't and anyway the main
reason I committed the change is because I wanted to encourage other
people to on this project, so I' prefer to commit patches more than
discard them.

The new async I/O should not give any advantage in ELO terms, it is
just a more elegant solution than polling in main thread and allows to
remove a lot of old and platform dependent code and this was enough
for me.

Your king threat bonus is interesting, please tell me how it goes for
you, maybe I will also test myself, but no promise here ;-)

Marco

On Sat, Nov 12, 2011 at 05:11, Kingdefender

wrote:
> Thanks for your reply Marco!
>
> I think your suggestion to use casting to uniform type is best for my MSVC
> 2005 builds, it seems to silence the compiler error warnings. I had to use
> it again yesterday in some new case where I wanted to compare different
> valuetypes and the compiler gave an error. There are also still some cases
> left in Rainbow Serpent where I introduced the std::min type of
> comparing but there I think your method would be preferable. I can't say
> the new code is much more readable than the old macro's from Tord though
> ;) But if this is how most C code looks like it is probably best to follow
> the standard.
>
> Your new way of communicating with a separate thread looks very interesting
> Marco! I hope you get the remaining issues solved. Maybe it gives some
> speed up in SMP? Vas wrote about something similar for Rybka 3 I believe.
> For single threaded Stockfish it probably does not matter?
>
> I'm trying lots of different little things in evaluate.cpp. But it will be
> a nightmare if I really want to test everything. The latest idea is maybe
> not too risky. I thought about allowing attacks by the king in the threat
> evaluation, just by the king, not attacks on the king. It may be of some
> importance in endgames, and in the middlegame I think attacks by the king
> maybe should be discouraged slightly by negative values. As long as you can
> be sure that evaluate is never called when the king is in check I think it
> is fairly safe to do this. Attacks on queens are not possible for instance,
> you could write an assert checking that, and attacks on rooks where the
> rook is not on a diagonally bordering square are also not possible because
> it would be check. Nevertheless for the middlegame I think attacking a rook
> should not get a high bonus (negative at the moment and zero in the
> endgame, just a guess) and for queens I keep a negative bonus in the
> ThreatBonus array. I hope I have not forgotten something, but I thought it
> could be very little code:
>
>
> // ThreatBonus[attacking][attacked] contains threat bonuses according to
>
> // which piece type attacks which one.
>
> const Score ThreatBonus[][8] = {
>
> {}, {},
>
> { S(0, 0), S( 7, 39), S( 0, 0), S(24, 49), S(41,100), S( 41,100) }, //
> KNIGHT
>
> { S(0, 0), S( 7, 39), S(24, 49), S( 0, 0), S(41,100), S( 41,100) }, //
> BISHOP
>
> { S(0, 0), S(-1, 29), S(15, 49), S(15, 49), S( 0, 0), S( 24, 49) }, // ROOK
>
> { S(0, 0), S(15, 39), S(15, 39), S(15, 39), S(15, 39), S( 0, 0) }, // QUEEN
>
> { S(0, 0), S(-2, 30), S(-2, 30), S(-2, 30), S(-2, 0), S(-20,-40) } // KING
>
> };
>
>
>
> and
>
>
>
> // Add bonus according to type of attacked enemy piece [pt2] and to the
>
> // type of attacking piece [pt1], from knights to queens. Kings are not
>
> // considered because are already handled in king evaluation.
>
> for (PieceType pt1 = KNIGHT; pt1 <= KING; pt1++)
>
> {
>
> instead of pt1 < KING. The comments should still be adapted to the new code
> of course. Well, it is just an example Marco but because it is very little
> code maybe you would like to try something like this. But I can't guarantee
> it will not be worse :) Alternatively you can always wait and first see if
> I throw it out again if I don't trust the change. I leave it up to you.
>
> Regards, Eelco
>
>
>
> 2011/11/3 mcostalba <
> reply@reply.github.com>
>
>> On Thu, Nov 3, 2011 at 18:25, Kingdefender
>>
>> wrote:
>> > Hello Marco,
>> >
>> > I wonder if any Windows compilers reported any problems with this commit.
>>
>> No, I compile with MSVC on both 32 and 64 bits and got no errors with
>> current master.
>>
>> I think the errors are due to the fact that you are comparing with
>> std::min / std::max variables of different types. if you cannot change
>> the variable type I'd suggest to cast to a uniform type, something
>> like this:
>>
>> int i;
>> long l;
>>
>> std::min(l, (long) i);
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>>
>> https://github.com/mcostalba/Stockfish/commit/5c8af7ccb8f59f901740d5a8f4a9270f69487583#commitcomment-693974
>>
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/mcostalba/Stockfish/commit/5c8af7ccb8f59f901740d5a8f4a9270f69487583#commitcomment-712704
>