What do you folks make of this ?

[Rebel]

As the matter of fact it does. It is an extremely frequent word that I see, hear and type in countless number of times on daily basis. Not an English one though. This also underlines my point about common patterns. I saw nothing wrong with it, because it's common to me. You, on the other hand, spotted it right away, likely because it is uncommon to you. There is nothing common about > .0, that's why it's hard to believe you would overlook it.

This is a fun debate. One more time:

FRUIT's time control is fully FLOAT based with MANY floats;
RYBKA's time control is fully INT based.

The accusation is that Vasik "copied" the FRUIT time-control, converted FLOAT to INT to obfuscate the FRUIT origins. But in the process Vasik overlooked one instruction, the 0.0 and so a trace of copying was left.

So far so good?

While converting FLOAT to INT Vas came to the FRUIT instruction:

if (movetime >= 0.0)

The accusation states he overlooked that instruction but we now know that is not true any longer because the Rybka assembler code states otherwise. Not ">=" but ">" only. This is contrary to the accusation that Vas overlooked, he did not because the instruction has changed, removing the "=".

So while changing the instruction (removing the "=") following the logic of the accusation It then becomes extremely unlikely he overlooked "0.0" if your MAIN GOAL is to obfuscate the Fruit origins.

[hyatt]

As the matter of fact it does. It is an extremely frequent word that I see, hear and type in countless number of times on daily basis. Not an English one though. This also underlines my point about common patterns. I saw nothing wrong with it, because it's common to me. You, on the other hand, spotted it right away, likely because it is uncommon to you. There is nothing common about > .0, that's why it's hard to believe you would overlook it.

This is a fun debate. One more time:

FRUIT's time control is fully FLOAT based with MANY floats;
RYBKA's time control is fully INT based.

The accusation is that Vasik "copied" the FRUIT time-control, converted FLOAT to INT to obfuscate the FRUIT origins. But in the process Vasik overlooked one instruction, the 0.0 and so a trace of copying was left.

wrong. Not once has anyone suggested he converted from float to int to obfuscate the origin. It was almost certainly done because it is a rational choice. System clock has always been kept in an integer value. using a float requires an ugly conversion done by the hardware. I think it was converted because almost every program I have looked at used ints for timing. Even the xboard protocol gives the time in int values of 1/100th of a second...

So far so good?

While converting FLOAT to INT Vas came to the FRUIT instruction:

if (movetime >= 0.0)

The accusation states he overlooked that instruction but we now know that is not true any longer because the Rybka assembler code states otherwise. Not ">=" but ">" only. This is contrary to the accusation that Vas overlooked, he did not because the instruction has changed, removing the "=".

So while changing the instruction (removing the "=") following the logic of the accusation It then becomes extremely unlikely he overlooked "0.0" if your MAIN GOAL is to obfuscate the Fruit origins.

Code changes over time. Unnoticed bugs remain. I had several that remained in Crafty for several years, such as the incorrect initialization of pawn hash entries, one of the things that led to the discovery that Rybka 1.6.1 was really Crafty 19.x in disguise...

Why >= became > is unknown. And will likely remain so. the fact that 0.0 is in the code is a fact one can weigh as much or as little as he wants.

[syzygy]

But "med" does look normal to you? (And what about ">.0")

As the matter of fact it does. It is an extremely frequent word that I see, hear and type in countless number of times on daily basis. Not an English one though. This also underlines my point about common patterns. I saw nothing wrong with it, because it's common to me. You, on the other hand, spotted it right away, likely because it is uncommon to you. There is nothing common about > .0, that's why it's hard to believe you would overlook it.

Words from my native language occurring in an English text would certainly not look normal to me.

Anyway, if ">.0" or "> .0" or "> 0.0" or "> 0." is so hard to overlook, how come Vas did overlook it? For your information: even assuming he copy & pasted the line from Fruit, he did modify that line.

[syzygy]

The accusation is that Vasik "copied" the FRUIT time-control, converted FLOAT to INT to obfuscate the FRUIT origins. But in the process Vasik overlooked one instruction, the 0.0 and so a trace of copying was left.

wrong. Not once has anyone suggested he converted from float to int to obfuscate the origin. It was almost certainly done because it is a rational choice. System clock has always been kept in an integer value. using a float requires an ugly conversion done by the hardware. I think it was converted because almost every program I have looked at used ints for timing. Even the xboard protocol gives the time in int values of 1/100th of a second...

If it is really so rational to use ints and not floats, that only supports the theory that Vas himself either started from floats himself or at one point converted from ints to floats, and later converted (back) to ints.

There are lots of engines using floats for time allocation, Stockfish just being one example.

Why >= became > is unknown. And will likely remain so. the fact that 0.0 is in the code is a fact one can weigh as much or as little as he wants.

You are once more showing that you did not study the code in any detail (but yet felt competent to give a judgement on what happened).

The reason for the ">" is that Rybka initialises the variable being tested to 0 (whereas Fruit initialises it to -1.0), and sets it to a (positive) value if a particular argument is present when parsing the UCI "go" command. Having a ">=" in that line would completely break Rybka.

Why Vas would convert the various -1.0 values to 0.0 I do not know (and certainly not if, as you say, this has nothing to do with obfuscation). Maybe he simply wrote the code himself? Explains why he parses the various arguments in a different order...

[hyatt]

The accusation is that Vasik "copied" the FRUIT time-control, converted FLOAT to INT to obfuscate the FRUIT origins. But in the process Vasik overlooked one instruction, the 0.0 and so a trace of copying was left.

wrong. Not once has anyone suggested he converted from float to int to obfuscate the origin. It was almost certainly done because it is a rational choice. System clock has always been kept in an integer value. using a float requires an ugly conversion done by the hardware. I think it was converted because almost every program I have looked at used ints for timing. Even the xboard protocol gives the time in int values of 1/100th of a second...

If it is really so rational to use ints and not floats, that only supports the theory that Vas himself either started from floats himself or at one point converted from ints to floats, and later converted (back) to ints.

There are lots of engines using floats for time allocation, Stockfish just being one example.

Why >= became > is unknown. And will likely remain so. the fact that 0.0 is in the code is a fact one can weigh as much or as little as he wants.

You are once more showing that you did not study the code in any detail (but yet felt competent to give a judgement on what happened).

The reason for the ">" is that Rybka initialises the variable being tested to 0 (whereas Fruit initialises it to -1.0), and sets it to a (positive) value if a particular argument is present when parsing the UCI "go" command. Having a ">=" in that line would completely break Rybka.

Why Vas would convert the various -1.0 values to 0.0 I do not know (and certainly not if, as you say, this has nothing to do with obfuscation). Maybe he simply wrote the code himself? Explains why he parses the various arguments in a different order...

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

Hence, int times are not only just a choice, they are THE rational choice since that's what the system gives you when you ask.

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

[syzygy]

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?

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

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

[BB+]

Not that I care about UCI parsing, but...

If you are a programmer check out the analysis on: http://www.top-5000.nl/fadden.htm and notice the nonsense of that.

As I had indicated to Mr. Schröder in email a couple of months ago, there are a few errors in his page.

When you say "Furthermore we like to stress out the differences between the Fruit and Rybka time control", some of your points (4,7,8 in particular) are more properly about "go" parsing in general, not just the intermixed time control. You should be specific about which you are talking about at which point. This is also true with your lists of variables at the end (bad_1, bad_2, change, easy...) -- Fruit resets these in search_clear(), which is called by parse_go().

As I think I mentioned on OpenChess (and maybe Zach did on TalkChess), your point #7 is false. The 0x7fffffff sentinels in Rybka 1.6 are for different things, not depth.

[Rebel]

Not that I care about UCI parsing, but...

If you are a programmer check out the analysis on: http://www.top-5000.nl/fadden.htm and notice the nonsense of that.

As I had indicated to Mr. Schröder in email a couple of months ago, there are a few errors in his page.

Well thank you Mr. Watkins

When you say "Furthermore we like to stress out the differences between the Fruit and Rybka time control", some of your points (4,7,8 in particular) are more properly about "go" parsing in general, not just the intermixed time control. You should be specific about which you are talking about at which point. This is also true with your lists of variables at the end (bad_1, bad_2, change, easy...) -- Fruit resets these in search_clear(), which is called by parse_go().

The only specific point that counts here is that once upon a time people believed Vasik verbatim copied Fruit's time control based on a decompile with major errors. What immediately springs in mind are the differences, not the similarities and Introducing 2 bugs into 10 lines of c-code hardly is an accusation.

As I think I mentioned on OpenChess (and maybe Zach did on TalkChess), your point #7 is false. The 0x7fffffff sentinels in Rybka 1.6 are for different things, not depth.

The one who made the mistake is again Fadden. I did not make up "depthLimit", that was Rick Fadden. The 0x7ffffffff value is a trademark of Vas and serves as another piece of evidence Vas wrote his own time control.

[wgarvin]

0x7FFFFFFF is INT_MAX, its hardly a special value.

[Rebel]

0x7FFFFFFF is INT_MAX, its hardly a special value.

It's usage:

Rybka 1.61 (18 times)'
Rybka 1.0 (2 times)
Fruit (0 times)
Crafty (0 times)

So I would say it's a trademark of Vasik.