Rybka 1.0 source code

[mar]

How do you explain that R1.0B cheats on fixed time per move? go movetime nnn actually uses 3xnnnn time. Someone forgot to cleanup?
EDIT: there are two groups: VIG and VII. But there is third group: IDC (I don't care)

[bob]

nonsense...you ought to be ashamed.

You are missing a couple points.

1. Strelka is non-relevant to the discussion. It's a mixture of Fruit and Rybka 1. And I don't trust Osipov statements for one penny as he has his own agenda.

2. Rick Fadden - he missed things. He missed that Fruit's time control could not have been copied from Fruit, yet he claimed it. Wrong. Here:

http://www.top-5000.nl/evidence.htm#C6

at the end of chapter 6.

You are forgetting I in meantime spend 7 months of my time in this issue and the longer I look the more I am convinced that Rybka 1 is way too original to be derived from anything.

So you have a new angle of defense. If he copies a block of code (with the 0.0 in it) you come up with two incredibly weak arguments that prove Fadden wrong:

(1) rather than really copying 0.0 from fruit. he MIGHT have somehow typed 0. or .0 by himself. No programmers use the numeric keypad, but he might have used a European version without numbers on the top row.

The explanation might be far fetched, but your arguments are not better. I told you that it could be

if (0.<=movetime)

where '.' and '<' are neighbor keys.

the fact is that 0.0 when the surrounding code is different does not mean much. You can have a lapsus thinking you were doing floats, a typo, who knows.

Miguel

1. Nobody, and I do mean nobody, types "if ( 0.0 < movetime) instead of "if (movetime >= 0.0)

Not true!

First of all, ( 0.0 <= movetime) if equivalent of (movetime >= 0.0)

Second, some people, including myself, write many times I place the constant on the left and there are very good reasons to do that. In fact, many recommend it!

For instance, when you want to type
if (x == 0) and you made a mistake and type (x = 0), that is valid but unwanted code. But if you type (0 == x) you cannot make the mistake w/o the compiler screaming. So, you get accustomed to do it. Now I do it both ways.

The problem is you think that everybody does things the way you do.

I have been unable to find a single person that types inverted comparisons. Current C compilers produce a warning if you type "if (x=0)" so that is not an issue. To me, and to students I asked, if you want to make sure a value is not negative, they would do if (x >= 0), NOT if (0 < x). It doesn't read right, even though it means the same thing.

So I do not believe this is a plausible explanation. It has some probability > 0 of being true, but VERY low, IMHO...

And if you want to hop on that band wagon, how does the "." character get introduced since is is not on the "<" key? So it is not even a very good excuse, regardless of how unlikely it is that someone actually uses it...

BTW, you have to invert the comparison if you invert the two things being compared. That blows this out of the water immediately, because you need that (> / .) key (both on same key) for this explanation to work, but we now need the < key instead, which doesn't work. And what about that "=" character? How did he get the > key, then the = key, and then go back to the > key to get the period by accident? None of this is the least bit plausible.

2. The obvious explanation is the simple one. The rest are highly improbable explanations that require all sorts of unlikely conditions to be true. Occam's razor...

The obvious explanation is that it was a mistake thinking float when it was integer. Assuming that VR copy the whole code, modified it and left 0.0 is more complicated and required less parsimony. Still, I do not want to claim Occam Razor because it has nothing to do with this and it cannot be used to prove anything.

Miguel

How is copying and ignoring the 0.0 less plausible than the far-fetched explanations dealing with a "." that just happens to be in the right place (where there are several wrong places on the same line that would cause compiler complaints)??

There is no "obvious mistake thinking float when it is integer. That is simply not common. Have you seen some of the chess program authors that have searched for 0.0 / 0. / .0 in their code and found zero? It doesn't pass the basic "rational test"...

[Rebel]

The most likely scenario is that the code was copied,

And there we go again.

1. When you point out that Rybka evaluates different than Fruit, the most likely scenario is that it is just a speed-up.

2. When you point out it would be flat-out proof if Fruit's QUAD function would have been in Rybka but it is not, then again, a speed-up!

3. When you point out that 4 expensive loops in Fruit that calculate mobility is actually one instruction in Rybka then the explanation is bit-boards.

There is ALWAYS a most likely scenario (to use your own words) why things are different in Fruit and Rybka.

The premise is, whatever differences are found Vas copied Fruit because we will find a most likely scenario.

That's not objective.

I could go on with more than 20 of such points.

How many are needed for a different look ?

40.. 60.. ?

[kranium]

The explanation might be far fetched, but your arguments are not better. I told you that it could be
if (0.<=movetime)
where '.' and '<' are neighbor keys.
the fact is that 0.0 when the surrounding code is different does not mean much. You can have a lapsus thinking you were doing floats, a typo, who knows.
Miguel

I have it from reliable sources that around the time of Rybka 1.0 beta, he was abducted by aliens and abused with probes,
but it's too traumatic for him to talk about...
this might very well explain his confusion, and all the absurd explanations, hypnotized fanboys, etc.

Poor Vas!

(Joke aside, how would you moderate Norman's a bit offensive but very funny post?)

Julien-

i did not mean to offend Cartman (or any of the Southpark characters) in any way, shape or form,
and i certainly don't mean disprespect to anybody who has been abducted and subjected to these terrible probes...!
(some/many of whom seem to congregate in this forum)

it just seems like a plausible explanation to me, especially considering what Vas has said, and some of the other prevalent 'theories'
being presented in this thread.

my sincere apologies!
(i'll try to chose my words more carefully)

PS-
(In the future, I suggest you refrain from posting questionable links to South Park highlights!)

[michiguel]

nonsense...you ought to be ashamed.

You are missing a couple points.

1. Strelka is non-relevant to the discussion. It's a mixture of Fruit and Rybka 1. And I don't trust Osipov statements for one penny as he has his own agenda.

2. Rick Fadden - he missed things. He missed that Fruit's time control could not have been copied from Fruit, yet he claimed it. Wrong. Here:

http://www.top-5000.nl/evidence.htm#C6

at the end of chapter 6.

You are forgetting I in meantime spend 7 months of my time in this issue and the longer I look the more I am convinced that Rybka 1 is way too original to be derived from anything.

So you have a new angle of defense. If he copies a block of code (with the 0.0 in it) you come up with two incredibly weak arguments that prove Fadden wrong:

(1) rather than really copying 0.0 from fruit. he MIGHT have somehow typed 0. or .0 by himself. No programmers use the numeric keypad, but he might have used a European version without numbers on the top row.

The explanation might be far fetched, but your arguments are not better. I told you that it could be

if (0.<=movetime)

where '.' and '<' are neighbor keys.

the fact is that 0.0 when the surrounding code is different does not mean much. You can have a lapsus thinking you were doing floats, a typo, who knows.

Miguel

1. Nobody, and I do mean nobody, types "if ( 0.0 < movetime) instead of "if (movetime >= 0.0)

Not true!

First of all, ( 0.0 <= movetime) if equivalent of (movetime >= 0.0)

Second, some people, including myself, write many times I place the constant on the left and there are very good reasons to do that. In fact, many recommend it!

For instance, when you want to type
if (x == 0) and you made a mistake and type (x = 0), that is valid but unwanted code. But if you type (0 == x) you cannot make the mistake w/o the compiler screaming. So, you get accustomed to do it. Now I do it both ways.

The problem is you think that everybody does things the way you do.

I have been unable to find a single person that types inverted comparisons.

It is even in the FAQ!
http://c-faq.com/style/revtest.html

Current C compilers produce a warning if you type "if (x=0)" so that is not an issue. To me, and to students I asked, if you want to make sure a value is not negative, they would do if (x >= 0), NOT if (0 < x). It doesn't read right, even though it means the same thing.

No, it does not mean the same thing. It is like the third of fourth time you are telling me this.

So I do not believe this is a plausible explanation. It has some probability > 0 of being true, but VERY low, IMHO...

And if you want to hop on that band wagon, how does the "." character get introduced since is is not on the "<" key? So it is not even a very good excuse, regardless of how unlikely it is that someone actually uses it...

BTW, you have to invert the comparison if you invert the two things being compared. That blows this out of the water immediately, because you need that (> / .) key (both on same key) for this explanation to work, but we now need the < key instead, which doesn't work. And what about that "=" character? How did he get the > key, then the = key, and then go back to the > key to get the period by accident? None of this is the least bit plausible.

2. The obvious explanation is the simple one. The rest are highly improbable explanations that require all sorts of unlikely conditions to be true. Occam's razor...

The obvious explanation is that it was a mistake thinking float when it was integer. Assuming that VR copy the whole code, modified it and left 0.0 is more complicated and required less parsimony. Still, I do not want to claim Occam Razor because it has nothing to do with this and it cannot be used to prove anything.

Miguel

How is copying and ignoring the 0.0 less plausible than the far-fetched explanations dealing with a "." that just happens to be in the right place (where there are several wrong places on the same line that would cause compiler complaints)??

There is no "obvious mistake thinking float when it is integer. That is simply not common.

If you have code in which you have floats and intergers, it is not unlikely to get a mental lapsus.

Miguel

Have you seen some of the chess program authors that have searched for 0.0 / 0. / .0 in their code and found zero? It doesn't pass the basic "rational test"...

[bob]

The most likely scenario is that the code was copied,

And there we go again.

1. When you point out that Rybka evaluates different than Fruit, the most likely scenario is that it is just a speed-up.

2. When you point out it would be flat-out proof if Fruit's QUAD function would have been in Rybka but it is not, then again, a speed-up!

3. When you point out that 4 expensive loops in Fruit that calculate mobility is actually one instruction in Rybka then the explanation is bit-boards.

There is ALWAYS a most likely scenario (to use your own words) why things are different in Fruit and Rybka.

The premise is, whatever differences are found Vas copied Fruit because we will find a most likely scenario.

That's not objective.

I could go on with more than 20 of such points.

How many are needed for a different look ?

40.. 60.. ?

First, how about some correctness. On mobility, it is NOT "one instruction in Rybka." Done pointed this out a half-dozen times. Where does "attacks" come from? A pair of complex table lookups that involve taking two different 64 bit values, shifting, then anding, then indexing into two separate (and large) arrays. That is not "one instruction." Now you have the "attacks" variable that has the set of attacked squares. So how about keeping things technically accurate as opposed to distorted to make Rybka look far different than Fruit. The mobility is quite simple. Agreed. It is less simple if the multipliers are proportional. It is less simple if it is done for all pieces (where some programs do it just for one or two pieces). It is less simple if there are other ways to do mobility that are different. We are talking about the "entire picture" here. Not the 4 loops in Fruit, or the pair of rotated bitboard move generations in Rybka + a popcnt instruction. The whole picture. And they both look like a Mona Lisa.

Second, your goal appears to be to dream up wildly implausible explanations (0.0 is an example) as opposed to "Occam's Razor" and realizing that the simplest and most believable explanation is likely the correct one. The chance of so many implausible explanations being true is essentially zero, as you multiply all the probabilities, and the more there are, the smaller the resulting probability since all are less than .5 in reality.

[geots]

nonsense...you ought to be ashamed.

You are missing a couple points.

1. Strelka is non-relevant to the discussion. It's a mixture of Fruit and Rybka 1. And I don't trust Osipov statements for one penny as he has his own agenda.

2. Rick Fadden - he missed things. He missed that Fruit's time control could not have been copied from Fruit, yet he claimed it. Wrong. Here:

http://www.top-5000.nl/evidence.htm#C6

at the end of chapter 6.

You are forgetting I in meantime spend 7 months of my time in this issue and the longer I look the more I am convinced that Rybka 1 is way too original to be derived from anything.

So you have a new angle of defense. If he copies a block of code (with the 0.0 in it) you come up with two incredibly weak arguments that prove Fadden wrong:

(1) rather than really copying 0.0 from fruit. he MIGHT have somehow typed 0. or .0 by himself. No programmers use the numeric keypad, but he might have used a European version without numbers on the top row.

The explanation might be far fetched, but your arguments are not better. I told you that it could be

if (0.<=movetime)

where '.' and '<' are neighbor keys.

the fact is that 0.0 when the surrounding code is different does not mean much. You can have a lapsus thinking you were doing floats, a typo, who knows.

Miguel

1. Nobody, and I do mean nobody, types "if ( 0.0 < movetime) instead of "if (movetime >= 0.0)

Not true!

First of all, ( 0.0 <= movetime) if equivalent of (movetime >= 0.0)

Second, some people, including myself, write many times I place the constant on the left and there are very good reasons to do that. In fact, many recommend it!

For instance, when you want to type
if (x == 0) and you made a mistake and type (x = 0), that is valid but unwanted code. But if you type (0 == x) you cannot make the mistake w/o the compiler screaming. So, you get accustomed to do it. Now I do it both ways.

The problem is you think that everybody does things the way you do.

I have been unable to find a single person that types inverted comparisons.

It is even in the FAQ!
http://c-faq.com/style/revtest.html

Current C compilers produce a warning if you type "if (x=0)" so that is not an issue. To me, and to students I asked, if you want to make sure a value is not negative, they would do if (x >= 0), NOT if (0 < x). It doesn't read right, even though it means the same thing.

No, it does not mean the same thing. It is like the third of fourth time you are telling me this.

So I do not believe this is a plausible explanation. It has some probability > 0 of being true, but VERY low, IMHO...

And if you want to hop on that band wagon, how does the "." character get introduced since is is not on the "<" key? So it is not even a very good excuse, regardless of how unlikely it is that someone actually uses it...

BTW, you have to invert the comparison if you invert the two things being compared. That blows this out of the water immediately, because you need that (> / .) key (both on same key) for this explanation to work, but we now need the < key instead, which doesn't work. And what about that "=" character? How did he get the > key, then the = key, and then go back to the > key to get the period by accident? None of this is the least bit plausible.

2. The obvious explanation is the simple one. The rest are highly improbable explanations that require all sorts of unlikely conditions to be true. Occam's razor...

The obvious explanation is that it was a mistake thinking float when it was integer. Assuming that VR copy the whole code, modified it and left 0.0 is more complicated and required less parsimony. Still, I do not want to claim Occam Razor because it has nothing to do with this and it cannot be used to prove anything.

Miguel

How is copying and ignoring the 0.0 less plausible than the far-fetched explanations dealing with a "." that just happens to be in the right place (where there are several wrong places on the same line that would cause compiler complaints)??

There is no "obvious mistake thinking float when it is integer. That is simply not common.

If you have code in which you have floats and intergers, it is not unlikely to get a mental lapsus.

Miguel

Have you seen some of the chess program authors that have searched for 0.0 / 0. / .0 in their code and found zero? It doesn't pass the basic "rational test"...

Miguel, one thing that is a good idea to keep in mind. Any and all talk about Rybka source codes and Fruit is moot- academic, if you will. Vas has promised Rybka 5 for 2012- and the promise hinges on its strength. He said when it comes out- it will be able to handle Houdini.No "ifs", "ands" or "buts". When it is- and does- you can count the people on one hand who will give a shit about the "past witch hunt". When it clobbers Houdini- there will be a mad rush to get it.

As for Fabien- I got an even deal. Vas got to the top because of Fruit. I will give Fabien 365 days to work on his engine, then he shows me 2 world championships in 3 years. He does- I apologize. He doesn't- he tells the anti Rybka crowd to shut up for good. Plus I got 5000 bucks says he can't do it, and another thousand that says he won't even try.


gts

[Rebel]

The most likely scenario is that the code was copied,

And there we go again.

1. When you point out that Rybka evaluates different than Fruit, the most likely scenario is that it is just a speed-up.

2. When you point out it would be flat-out proof if Fruit's QUAD function would have been in Rybka but it is not, then again, a speed-up!

3. When you point out that 4 expensive loops in Fruit that calculate mobility is actually one instruction in Rybka then the explanation is bit-boards.

There is ALWAYS a most likely scenario (to use your own words) why things are different in Fruit and Rybka.

The premise is, whatever differences are found Vas copied Fruit because we will find a most likely scenario.

That's not objective.

I could go on with more than 20 of such points.

How many are needed for a different look ?

40.. 60.. ?

First, how about some correctness. On mobility, it is NOT "one instruction in Rybka." Done pointed this out a half-dozen times. Where does "attacks" come from? A pair of complex table lookups that involve taking two different 64 bit values, shifting, then anding, then indexing into two separate (and large) arrays. That is not "one instruction." Now you have the "attacks" variable that has the set of attacked squares. So how about keeping things technically accurate as opposed to distorted to make Rybka look far different than Fruit. The mobility is quite simple. Agreed. It is less simple if the multipliers are proportional. It is less simple if it is done for all pieces (where some programs do it just for one or two pieces). It is less simple if there are other ways to do mobility that are different. We are talking about the "entire picture" here. Not the 4 loops in Fruit, or the pair of rotated bitboard move generations in Rybka + a popcnt instruction. The whole picture. And they both look like a Mona Lisa.

First, how about some common sense ?

FRUIT:

Code: Select all

         case Bishop64:

            // mobility

            mob = -BishopUnit;

            for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;
            mob += unit[capture];

            for (to = from-15; capture=board->square[to], THROUGH(capture); to -= 15) mob += MobMove;
            mob += unit[capture];

            for (to = from+15; capture=board->square[to], THROUGH(capture); to += 15) mob += MobMove;
            mob += unit[capture];

            for (to = from+17; capture=board->square[to], THROUGH(capture); to += 17) mob += MobMove;
            mob += unit[capture];

RYBKA: (taken from Zach's document)

Code: Select all

            mob = popcnt(attacks & ~own_pieces); 

Common sense states that when you write code 10-20 times faster, pack 4 expensive loops into 1 instruction you are the better engineer. Furthermore there is no copyright on chess knowledge, no copyright on commonly used concepts such as mobility especially not when it's explained in detail on the Wiki chess pages.

http://chessprogramming.wikispaces.com/Mobility

Second, your goal appears to be to dream up wildly implausible explanations (0.0 is an example) as opposed to "Occam's Razor" and realizing that the simplest and most believable explanation is likely the correct one. The chance of so many implausible explanations being true is essentially zero, as you multiply all the probabilities, and the more there are, the smaller the resulting probability since all are less than .5 in reality.

OK, your version of "Occam's Razor" vs mine.

http://www.top-5000.nl/evidence.htm#C6

Chapter 6 - The notorious 0.0 case.

It's about time-control and the accusation that Vasik "copied" that from FRUIT.

In a nutshell:

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

And yet in RYBKA's time-control a FLOAT value is found -> 0.0 which is odd indeed.

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

Its rebuttal:

From the open sources I studied, some even before Rybka appeared, have a Fruit alike floating point driven time control that can deal with 1/10 or 1/100 of a second, an integer driven time control certainly can not. It's only logical to program your time control with decimals unless you want to lose long blitz games on time or make strange concessions during the very last seconds on the clock.

If Vas copied Fruit then why did he move from a superior (float) time control to an inferior (integer) time control with known issues? This makes absolutely no sense.

But far more important

Compile the following code with any of the MS compilers.

static int T=1;
void main() { if (T >= 0. ) T=5; }

It will produce the same code as 0.0

or compile

static int T=1;
void main() { if (T >= .0 ) T=5; }

It will produce the same code as 0.0

Meaning the 0.0 accusation falls apart, what was strong evidence for 4-5 years is now minimized to overlooking a dot typo.

Missing 1 pixel on a 1920 - 1080 screen.

That's no good reason to strip someone of 4 world titles and brand him as a fraud in the worldwide media.

By own experience I know the impact 0.0 had on me, an atomic bomb and from talks with other chess programmers I know they took the same road as me, after the 0.0 revelation suddenly programmers started to take the accusations more seriously.

But only a dot can be proven.

No FRUIT copying.

I recently had a discussion with Vas and on this issue and he said:

There isn't much I can help with here. I don't know where the 0.0 came from. It's definitely weird/wrong.

Rybka was UCI from the beginning, even back when everybody was using WinBoard. I would say that every two to three years I do a big cleanup of this code. This might take a few hours, and then I won't touch it until the next time. My first UCI parser actually used inheritance, I was extending UCI to do some testing, but that was gone even before Rybka 1.

Best regards,
Vas

I have checked Vas' words. Indeed the pre-Rybka version 1.6.1 which Vas entered in a tournament without permission of Crafty author Robert Hyatt is UCI. Crafty since day one is Winboard only. Meaning Vas wrote his own time control long before Fruit 2.1 appeared. Furthermore the pre-Rybka 1.16.1 contains on 18 occasions an odd kind of flag with the value "0x7fffffff" also one in the UCI time control.

As "999999" is a signature of Crafty "0x7fffffff" is a signature of Rybka. Checking Rybka 1.0 beta for "0x7fffffff" the value only appears 2 times, one again in the UCI time control. The evidence is presented here, a more detailed explanation here.

As "0x7fffffff" is not found in Crafty or Fruit it's safe to conclude Vas wrote his own time control and the accusation Vas copied Fruit's time control, converted float to int to hide the Fruit origin is pretty much debunked.

[towforce]

1. Nobody, and I do mean nobody, types "if ( 0.0 < movetime) instead of "if (movetime >= 0.0)

Not true!

First of all, ( 0.0 <= movetime) if equivalent of (movetime >= 0.0)

Second, some people, including myself, write many times I place the constant on the left and there are very good reasons to do that. In fact, many recommend it!

O.T.: I am currently working with some Japanese Java code, and these coders often put the constant on the left. However - I cannot say that they are using good coding practice, because of the number of times I have seen:

if (true = variable) instead of if (variable)

[Jose Carlos]

I have been unable to find a single person that types inverted comparisons.

Just for the record, I do type those inverted comparisons in some cases. It makes life easier.