What do you folks make of this ?

[hyatt]

Some have already pointed out that stockfish might have "fruity" origins. however, since they have not competed in CC events, and since they release their code as GPL, they have followed the letter/spirit of the law quite carefully.

It is complete nonsense to suggest that the time allocation code of stockfish is derived from fruit's. But OK, apparently you also have a problem with stockfish.

But if you look around at original engines, MOST use ints. Because of this:

in unix, best choice is "gettimeofday" to get the elapsed (wall-clock time).

Call looks like this:

int gettimeofday(struct timeval *tv, struct timezone *tz);

Guess what you find when you look inside the timeval struct definition?



Hint: NOT a float.

Not a reason at all not to use floats for time allocation calculations. In fact a complete non-reason.

Do you actually understand why stockfish uses float? Hint: same reason as why crafty uses them for the calculation of nps. If you understand why, can you give any reason why NOT to use floats?

Nodes per second? You mean this line of code:

nodes_per_second =
tree->nodes_searched * 100 / (uint64_t) (end_time - start_time);

Not a single float in the bunch. All done using 64 bit integers. I am not sure what, exactly, you are talking about. I use a float to print time values, since my internal integer time is in 1/100ths of a second units exactly as provided by xboard. Much easier to print fractions of a second using a simple float(t) / 100.0 and then outputting on a %f format. Not to do anything other than display fractions of a second for test positions that take < 1 minute to search...

So can you be more specific about what you are suggesting here?

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.

(Actually I can give a reason why not to use them: using one floating-point operation in an otherwise int-based program could theoretically increase context switch overhead. I don't know if this is still relevant with modern sse instruction sets, and in any case it will not be noticeable in practice. Still, this is the (only) reason why my engine doesn't use floats anywhere.)

Btw, what do you think of the following line:

Code: Select all

    time_limit *= 1.0 + usage_level / 100.0;

The variable time_limit is an int, but this line is clearly using floating point operations. It converts ints to floats, does some computation, and converts back to int. Guess what engine this comes from.

Here's the key. 0.0 is in the line of code. Fruit has >=, Rybka has > which is different. If Vas copied Fruit and changed the >= to > then why didn't he notice the 0.0??? If he wrote the line himself, why didn't he fix the 0.0? The bottom line is, in spite of all the arguments, 0.0 is not something that happens naturally, there is no real keyboard/typo explanation that holds water, so why is it there? The most likely explanation is that it was copied and not noticed. Just another piece of a pretty large puzzle...

Is this supposed to be logically coherent? The 0.0 makes no sense whatever its explanation. But it is there.

Maybe you accidentally left out the precondition for all your reasoning: VIG.

Nothing to do with Vas whatsoever, in this case.

[syzygy]

Do you actually understand why stockfish uses float? Hint: same reason as why crafty uses them for the calculation of nps. If you understand why, can you give any reason why NOT to use floats?

Nodes per second? You mean this line of code:

nodes_per_second =
tree->nodes_searched * 100 / (uint64_t) (end_time - start_time);

No, this line:

Code: Select all

  Print(4095, "Raw nodes per second: %d\n",
      (int) ((double) nodes / ((double) total_time_used / (double) 100.0)));

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 the heck does it matter that YOU tend to use 64-bit ints for this?
Does that in any way make it unbelievable that OTHERS do use floats?

[lmader]

No, this line:

Code: Select all

  Print(4095, "Raw nodes per second: %d\n",
      (int) ((double) nodes / ((double) total_time_used / (double) 100.0)));

...

Does that in any way make it unbelievable that OTHERS do use floats?

That code looks like integer code to me - every single variable is being cast as a double during the calculation, and the result is cast back to an int. This technique is used to avoid losing precision when doing division with integers.

[syzygy]

No, this line:

Code: Select all

  Print(4095, "Raw nodes per second: %d\n",
      (int) ((double) nodes / ((double) total_time_used / (double) 100.0)));

...

Does that in any way make it unbelievable that OTHERS do use floats?

That code looks like integer code to me - every single variable is being cast as a double during the calculation, and the result is cast back to an int. This technique is used to avoid losing precision when doing division with integers.

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

[lmader]

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?

[Chris Whittington]

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.

[lmader]

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.

Ok, so using floats in time control is not quirky, in the abstract sense.

Except that Rybka's time control is not float based - it's integer based right? Given that, doing a comparison between an int and a float const _is_ quirky, and borderlines on being a benign coding error. Are you really arguing that the presence of that comparison is an example of floating based time control? Really?

[Chris Whittington]

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.

Ok, so using floats in time control is not quirky, in the abstract sense.

Except that Rybka's time control is not float based - it's integer based right? Given that, doing a comparison between an int and a float const _is_ quirky, and borderlines on being a benign coding error. Are you really arguing that the presence of that comparison is an example of floating based time control? Really?

Personally speaking, I've not paid too much attention to that chunk of code. I seem to recollect that when I did look at it it was clear that the variable move time was not a move time but a flag dictating the type of time control. It did not appear to be accessed anywhere else, and the surrounding code was a mess and seemed to be buggy. I find it just about impossible to assert anything at all from the code, the float or int usage or anything else associated with it. I suspect that most feel the same way, since this code has been discussed since at least 2007 and was not enough then to draw any conclusions from, hence the subsequent major reinvestigation of everything else. We appear to keep returning to it as a form of backstop whenever the going gets too tough on another topic, mobility for example. It's a red herring and diversion from the only code that actually matters, namely the evaluation function.

[syzygy]

Ok, so using floats in time control is not quirky, in the abstract sense.

Except that Rybka's time control is not float based - it's integer based right? Given that, doing a comparison between an int and a float const _is_ quirky, and borderlines on being a benign coding error. Are you really arguing that the presence of that comparison is an example of floating based time control? Really?

Some of this discussion stems from a thread on talkchess.

The 0.0 in the Rybka1.0beta is of course quirky. The question is how it got there.

One scenario is that he copied from Fruit, converted to float, but overlooked one line.
Another scenario is that he wrote it himself, but made a typo.
A third scenario is that Vas at some point used floating point for intermediate calculations, then converted (back?) to integer, but overlooked one line.

Bob has dismissed this third scenario inter alia with the argument that nobody would use floating point in time allocation code in the first place, because that is "unnatural". He goes so far as to suggest that even the time allocation code of Stockfish was taken from Fruit when I point out that Stockfish uses floats too.

This argument against the third scenario is of course extremely weak. It is not at all unnatural to use floating point for intermediate computations in time allocation code.

That this argument is weak does not mean that the third scenario is the correct one. 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.

There are other alleged quirks in this part of the code that, if you actually study the code, turn out to be no more than direct consequences of the UCI protocol. Why did the investigators not study the code? Even in this thread Bob has stated that we will likely never know why Rybka has a ">=" where Fruit has a ">". If he had studied the code, he would have known.

[hyatt]

Do you actually understand why stockfish uses float? Hint: same reason as why crafty uses them for the calculation of nps. If you understand why, can you give any reason why NOT to use floats?

Nodes per second? You mean this line of code:

nodes_per_second =
tree->nodes_searched * 100 / (uint64_t) (end_time - start_time);

No, this line:

Code: Select all

  Print(4095, "Raw nodes per second: %d\n",
      (int) ((double) nodes / ((double) total_time_used / (double) 100.0)));

That was done by Jason Deines a few years back. Why do we care about the benchmark command output in this discussion?

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 the heck does it matter that YOU tend to use 64-bit ints for this?
Does that in any way make it unbelievable that OTHERS do use floats?

Know anyone that is NOT using 64 bit ints for their node counters? I used 'em, even on 32 bit hardware, and have for at least 10 years now, probably much longer.

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