What do you folks make of this ?

[hyatt]

Well, if you want to call this "integer code" I am fine with that. The point is that it is completely natural to start with integers, end with integers, but use floating point for intermediate calculations. Indeed there are two reasons for this: avoid overflows and preserve precision.

(Of course all of that CAN be done using ints only. In fact, internally a CPU does all floating point calculations in binary only.)

Ok, that's all true. But maybe I'm losing the thread here, and if so I apologize, but isn't this all supposed to relate back to the code in Rybka that was comparing an int variable to a float const? That is not the same thing as what we are saying about using floats for intermediate steps in a computation. This is an example of an incorrect comparison. Or am I missing something?

Leaving out the fascinating topic of how many time control floats can you get on the head of a pin, the original purpose of this discussion was to debunk the Hyatt assertion that use of floats within time control was mad and/or bad and/or quirky and therefore a sign of copying. Since it is neither mad nor bad nor quirky and is used by several including Bob's own program, it would appear that it is no proof of anything.

There is NO floats in my time control code. Which is the code that sets the target time, and measures the elapsed time and compares the delta (time used) to the target. ALL done in pure ints... Displaying a number in a way that is user-friendly (fractions of a second rather than some programs that just display time in 1/100th of a second ints (15 secs = 1500, for example) has absolutely nothing to do with time allocation and time decisions. How about sticking to the topic... This doesn't debunk anything except that the person that wrote the bench.c code (or rewrote it, actually) chose a different way to display NPS for reasons only he could answer. It was certainly unnecessary as we never show fractions of a NPS.

[BB+]

Again, I don't care much about UCI and time control, but some might be interested in what the Rybka 1.6 time control (which is completely integer-based, even for intermediate computations) looked like. It first parsed the relevant UCI tokens, and put them into a "my/your" struct (dividing by 10 to get centiseconds, rather than use milliseconds) depending on whose move it was. Only the "my" half is used in the sequel. The default "movestogo" (if none is given) is 40.

The time control logic is then (with mat being 0 to 31, from Q=9, R=5, B=N=3 for own pieces):

mtg=movestogo;
if (mat>=23 && mtg==40) mtg=(mtg*4)/3; // start of game
if (mat<13 && mtg==40) mtg=(mtg*2)/3; // end of game
if (depth>0 && depth<=64 || nodes>0 && nodes<INT_MAX) goto search;
tm=time-1200; // 12s
X=max(4,(4*inc)/(tm/mtg));
if (movestogo==40) T=((tm*(X+4))/5)/mtg; // 40 is default
else T=(4*tm)/5/movestogo; // use movestogo here (not mtg)
Y=T+inc;
if (Y>movetime) Y=movetime; // user-specified "movetime"
if (Y<100) Y=100;

The above is the "target time", it seems. There is then some computation of "absolute time", and more bounds checking.

Here is a list of what you get in the starting position (where mat=31, so mtg becomes 53).

go wtime 60000 -> 100 [centiseconds]
go wtime 79000 -> 101 (6700*4/5/53)
go wtime 100000 -> 132 (8800*4/5/53)
go wtime 60000 winc 1000 -> 244 [100+144, and X=(4*100)/(4800/53)=4, so T=(4800*8)/5/53=144]
go wtime 100000 winc 1000 -> 299 [100+199, and X=(4*100)/(8800/53)=2, so T=(8800*6)/5/53=199]

The "absolute time" formula is typically time+(inc-100)*movestogo-1200, but if inc is less than 100, then time-(100-inc)*movestogo-1200 is used, I think. Again 100 is the minimum.

It is unclear why this time control was not retained in Rybka 1.0 Beta.

[syzygy]

BTW, what, exactly, is wrong with you here? You are pointing out something about MY CODE, then write "what the heck does it matter that I use 64 bit ints"??? If we are talking about my code, doesn't it matter what is IN my code???

There we go again....

You have been making a MAJOR point of the unnaturality of using floats in time allocation code.

I have pointed out that this is not at all unnatural. Many engines use floats in their time allocation code. Miguel's program, Marcel's program, Fabien's program. Then we have Sjeng, Stockfish, etc. It even turns out that crafty uses floats at various places. So it is NOT unnatural.

Now you are saying:

Floats provide a very clear benefit here: the programmer doesn't have to worry about integer overflow problems in intermediate calculations.

Neither do I worry about integer overflow. I can not search a number of nodes that threatens to overflow a 64 bit counter when doing any sort of calculation I can think of today. 4,000,000,000 x 4,000,000,000 is quite a large number.

What is wrong with you? My point is: it is NATURAL.
You say: I use 64 bit counters.

What the heck does that matter? It is STILL completely NATURAL to use floats. Maybe not for you but you ARE NOT the measure of all things. Try to let that sick in just once.

Is this clear now?

[hyatt]

BTW, what, exactly, is wrong with you here? You are pointing out something about MY CODE, then write "what the heck does it matter that I use 64 bit ints"??? If we are talking about my code, doesn't it matter what is IN my code???

There we go again....

You have been making a MAJOR point of the unnaturality of using floats in time allocation code.

I have pointed out that this is not at all unnatural. Many engines use floats in their time allocation code. Miguel's program, Marcel's program, Fabien's program. Then we have Sjeng, Stockfish, etc. It even turns out that crafty uses floats at various places. So it is NOT unnatural.

Now you are saying:

Floats provide a very clear benefit here: the programmer doesn't have to worry about integer overflow problems in intermediate calculations.

Neither do I worry about integer overflow. I can not search a number of nodes that threatens to overflow a 64 bit counter when doing any sort of calculation I can think of today. 4,000,000,000 x 4,000,000,000 is quite a large number.

What is wrong with you? My point is: it is NATURAL.
You say: I use 64 bit counters.

What the heck does that matter? It is STILL completely NATURAL to use floats. Maybe not for you but you ARE NOT the measure of all things. Try to let that sick in just once.

Is this clear now?

Please show me one LINE OF CODE (in Crafty) that uses floats in "TIME MANAGEMENT". Printing a number is NOT "time management" or "time allocation".

Seems pretty simple...

It is NOT "completely natural to use floats."

Otherwise everyone would be doing it. They are not.

[syzygy]

Please show me one LINE OF CODE (in Crafty) that uses floats in "TIME MANAGEMENT". Printing a number is NOT "time management" or "time allocation".

Seems pretty simple...

It is NOT "completely natural to use floats."

Otherwise everyone would be doing it. They are not.

So if ONE PERSON, which happens to be you, is not using it, then it is not natural?
Is this because this one person happens to be you?
Curious...

Maybe not for you but you ARE NOT the measure of all things. Try to let that sick in just once.

[User923005]

This is Pepito's time control (floating point calculation of the allocated time slot if there is an increment):

entero32 AllocTime(int mv_ctrl, int numjug, entero32 time_left, int inc)
{
entero32 allocated;
/* Old way falls off of a cliff...
if (inc) {
if (time_left > (inc + inc))
return inc + time_left / 35;
else
return time_left / 35;
*/
if (inc) {
allocated = (entero32) (inc * (time_left / ((float) time_left + inc)) + time_left / 35.0f + 0.5f);
} else if (mv_ctrl) {
allocated = (time_left / (mv_ctrl - ((numjug / 2) % mv_ctrl)) * 80 / 100);
if (time_left < 1000)
allocated = allocated * 80 / 100;
} else
allocated = time_left / 40;

CONTROL_INC = allocated > 300 ? 50000 : 20000;

Log("mv_ctrl: %d, time_left: %d, allocated: %d\n", mv_ctrl, time_left, allocated);

return allocated;
}

Yace used floating point even in the evaluation.

[syzygy]

This is Pepito's time control (floating point calculation of the allocated time slot if there is an increment):

As far as I can tell the majority of the engines use floats for intermediate time allocation calculations. So far I only know of Rybka, Crafty (mostly, but see the line "time_limit *= 1.0 + usage_level / 100.0" in TimeSet()) and my private engine that avoid them. Gaviota, Rookie, Fruit, (an old version of) Sjeng, Stockfish, Ivanhoe, Pepito (and Yace, as I understand), they all use floating point calculations.

But of course Bob himself, unlike the people that wrote parts of crafty for him, never uses floats for such calculations, so therefore anyone using them whose name starts with V is suspicious. The logic is just staggering.

I find the astonishing unwillingness to be reasonable regarding clear-cut stuff like this to be extremely telling of the whole case against Vas.

Oops:

Maybe not for you but you ARE NOT the measure of all things. Try to let that sink in just once.

Typo corrected. This was not an intentional typo.

[BB+]

Some of this discussion stems from a thread on talkchess.

Maybe I should stay out of it then...

I find the astonishing unwillingness to be reasonable regarding clear-cut stuff like this to be extremely telling of the whole case against Vas.

Hmm.. I thought the case against VR was based on actual evidence, not Bob's statements/opinions? [In particular, time management was never much considered]. I do admit that the media hitpieces following CB/Riis did a lot to conflate the issue though, and by now ad hominem is about the only thing one can expect.

However, it does make me wonder about how objective the investigation could have been if one of the lead investigator is simply blinded by his determination to prove guilt.

Since when was Bob a "lead investigator"? Again I agree that the misinformation industry has been energetic in promoting such directions, but it is simply untrue. Perhaps I should find the astonishing unwillingness to be factual regarding clear-cut stuff like this to be extremely telling...?

Incidentally, (FWIW) saying that IvanHoe uses floating-point calculations is debatable. They appear only in TImeManagerAlternative and TIME_IMITATE code, both of which are typically unused I think. Here is the core code:

Code: Select all

void TimeManager (sint64 TIME, sint64 OPP_TIME, sint64 INCREMENT, int mtg)
{  double rat; uint64 mult;
  if (mtg)
    {if (mtg > 25) mtg = 25;
      DESIRED_TIME = TIME / mtg + INCREMENT;
      ABSOLUTE_TIME = (TIME * mtg) / (4 * mtg - 3) - MIN (1000000, TIME / 10);
      if (mtg == 1) ABSOLUTE_TIME -= MIN (1000000, ABSOLUTE_TIME / 10);
      if (ABSOLUTE_TIME < 1000) ABSOLUTE_TIME = 1000; }
  else
    {ABSOLUTE_TIME = (TIME * ABSOLUTE_PERCENT) / 100 - 10000;
      if (ABSOLUTE_TIME < 1000) ABSOLUTE_TIME = 1000;
      DESIRED_TIME = (TIME * DESIRED_MILLIS) / 1000 + INCREMENT;}
  if (SINCE_NEW_GAME < BOOK_EXIT_MOVES)
    DESIRED_TIME += (DESIRED_TIME * (BOOK_EXIT_MOVES - SINCE_NEW_GAME)) / BOOK_EXIT_MOVES;
[...]
  if (DESIRED_TIME > ABSOLUTE_TIME) DESIRED_TIME = ABSOLUTE_TIME;
  if (DESIRED_TIME < 1000) DESIRED_TIME = 1000;
  EASY_TIME = (DESIRED_TIME * EASY_FACTOR) / 100;
  if (UCI_PONDER) EASY_TIME = (DESIRED_TIME * EASY_FACTOR_PONDER) / 100;
  BATTLE_TIME = (DESIRED_TIME * BATTLE_FACTOR) / 100;
  ORDINARY_TIME = (DESIRED_TIME * ORDINARY_FACTOR) / 100;

OTOH, I largely agree that using floats intermediately is fairly natural. The Faile source code even has a comment in this regard: calculate the ammount of time the program can use in its search, measured in centi-seconds (calculate everything in float for more accuracy as we go, and return the result as a long int). Another example of an engine for which time management (excepting I/O) is purely integer-based is Phalanx XXII. Another is Glaurung (see code below -- note SF1.9 is the first to have timeman.cpp, with floats), which I think Tord admits is Fruit-influenced. So I don't think Rybka is a large outlier in this.

Code: Select all

  if(!movesToGo) { // Sudden death time control
      if(increment) { MaxSearchTime = time / 30 + increment;
                      AbsoluteMaxSearchTime = Max(time / 4, increment - 100); }
      else { MaxSearchTime = time / 40; // Blitz game without increment
             AbsoluteMaxSearchTime = time / 8; } }
  else { // (x moves) / (y minutes)
           if(movesToGo == 1) { MaxSearchTime = time / 2;
                                AbsoluteMaxSearchTime = Min(time / 2, time - 500);}
           else { MaxSearchTime = time / Min(movesToGo, 20);
                  AbsoluteMaxSearchTime = Min((4 * time) / movesToGo, time / 3);}}
  if(PonderingEnabled) { MaxSearchTime += MaxSearchTime / 4;
                         MaxSearchTime = Min(MaxSearchTime, AbsoluteMaxSearchTime);}

[User923005]

Since when was Bob a "lead investigator"? Again I agree that the misinformation industry has been energetic in promoting such directions, but it is simply untrue. Perhaps I should find the astonishing unwillingness to be factual regarding clear-cut stuff like this to be extremely telling...?

I agree that the lead investigators were Mark (you) and Zach.

I also think that both were trying to be honest and forthright.

However, I think that the entire investigative process was very badly designed. I also do not think that you have shown what you think you have shown, but that is neither here nor there and my opinion is no better than anyone else's.

[syzygy]

Since when was Bob a "lead investigator"? Again I agree that the misinformation industry has been energetic in promoting such directions, but it is simply untrue. Perhaps I should find the astonishing unwillingness to be factual regarding clear-cut stuff like this to be extremely telling...?

Ok, then I stand corrected. Where is my unwillingness now?