OpenChess

andreio wrote: 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.

Rebel wrote:

andreio wrote: 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.

andreio wrote:

syzygy wrote: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.

hyatt wrote:

Rebel wrote: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...

hyatt wrote: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 wrote:

hyatt wrote:

Rebel wrote: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.

hyatt wrote: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 wrote: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.

    time_limit *= 1.0 + usage_level / 100.0;

hyatt wrote: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...

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

BB+ wrote: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.

BB+ wrote:Not that I care about UCI parsing, but...

Rebel wrote: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.

BB+ wrote: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().

BB+ wrote: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.

wgarvin wrote:0x7FFFFFFF is INT_MAX, its hardly a special value.