Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Rook half-open and open files
1 2 3 4 Previous Next  
- - By bob (Gold) Date 2013-09-15 22:39
OK, let's take a moment to look.

1.  Crafty's open-file / half-open file code:

    if (!(file_mask[file] & Pawns(side))) {
      if (!(file_mask[file] & Pawns(enemy))) {
        score_mg += rook_open_file[mg];
        score_eg += rook_open_file[eg];
      } else {
        score_mg += rook_half_open_file[mg];
        score_eg += rook_half_open_file[eg];
      }
    }

Simple code.  If there are no friendly pawns on the file, continue, else skip.

If there are no enemy pawns on file add in open file bonus.  Else add in half-open file bonus.

Both checks done with two simple bitboard AND operations.

2. Next Rybka:

file_bb = mask_open_file_w[square];
if ((Board.pieces[WP] & file_bb) == 0) {
  opening += RookSemiOpenFileOpening;
  endgame += RookSemiOpenFileEndgame;
  if ((Board.pieces[BP] & file_bb) == 0) {
    opening += RookOpenFileOpening - RookSemiOpenFileOpening;
    endgame += RookOpenFileEndgame - RookSemiOpenFileEndgame;
  }
}

If there are no while pawns on file, add bonus for half-open file;

if there are no black pawns on file, add bonus for full-open-file and subtract bonus for half-open file.  A somewhat unusual method.  Or is it.

3. Fruit next:

rook_file = SQUARE_FILE(from);
if (board->pawn_file[me][rook_file] == 0) {
  op[me] += RookSemiOpenFileOpening;
  eg[me] += RookSemiOpenFileEndgame;
  if (board->pawn_file[opp][rook_file] == 0) {
    op[me] += RookOpenFileOpening - RookSemiOpenFileOpening;
    eg[me] += RookOpenFileEndgame - RookSemiOpenFileEndgame;
  }
}

Look familiar.  Yes we both check for the same things.  But only Fruit/Rybka do the same tests in the same order and do that add/subtract approach.

How is rybka "alone in the way it defines these and codes them"???

Rybka and Fruit match exactly with the unusual idea of adding the half-open bonus, then if the file is fully open, subtracting that bonus and adding the fully open file bonus. 

Please show me where that "original" thought is?

Crafty does NOT code it the same way so your question can't be answered because the underlying premise is simply wrong.

The problem here is that fruit/rybka match here.  They match in hashing.  they match over there.  They match in TOO many different places.  I've already compared my ttable stuff to fruits, so show how completely different it looks.
Parent - - By Ugh (*****) Date 2013-09-16 07:33
a master class in how to lie using disassembled source code
Parent - By Rebel (****) Date 2013-09-16 08:06
And mister N=C in denial.
Parent - - By bob (Gold) Date 2013-09-16 13:28 Edited 2013-09-16 13:41
Simple question: 

"Does the CODE (instructions given above) match or not?"

There is only ONE answer.

BTW, it would REALLY be nice if you would pick one side of this argument and stick with it.  The code is a perfect match.  The bitmask is a "table" which you guys have REPEATEDLY claimed is irrelevant since it can't be copyrighted.  So which is it?  Are the PST tables an issue or not?  If not, a bitmask to exclude pawns behind the rook is exactly the same.  We count 'em both or we exclude them both.  But the code does match precisely.
Parent - - By Banned for Life (Gold) Date 2013-09-16 15:23
PST tables are not an issue for the same reason that the piece values are not an issue. They represent pure chess knowledge and the less creative input from the developer, the better.

The bitmask is used to implement a different algorithm (i.e. exclude pawns behind the rook).

These are very different vis-a-vis copyright law...
Parent - - By bob (Gold) Date 2013-09-16 16:04
SO a table of 64 0's and 1's is different from a table of 64 values that are larger than 0 or 1, where the latter contains far more information, but is not copyrightable?

You are a total ass...
Parent - By Venator (Silver) Date 2013-09-16 16:17
So a copied table and 8 added to each number is subject to copyright?
Parent - By Banned for Life (Gold) Date 2013-09-16 16:56
You are one stupid redneck.

Try claiming copyright on a table containing the number of squares a knight can reach from any square on the chessboard. Won't work.
Try claiming copyright on the amount of daily rainfall over a three month period in 100 cities. The arrangement can be copyright, but not the data.

Copyright has a lot more to do with creativity than with information content.

You're the most arrogant idiot I've ever encountered.
Parent - - By Ugh (*****) Date 2013-09-16 20:45 Edited 2013-09-16 20:56 Upvotes 1
Simple question: 

"Does the CODE (instructions given above) match or not?"

There is only ONE answer.


Wrong question, but we'll come to that in a minute.

You showed some Crafty code, some Fruit code and some disassembled Rybka code.

The answer is it depends who is looking and how deeply you look.

For a non-programmer, or for a programmer who is just skim reading, the graphical match between the Rybka Fruit code is high. That's how you then lead them to the conclusion that the code is copied.

But, if we look a little deeper at the meaning of the code, we see that actually the identical semantic match is between Fruit and Crafty. Rybka is uniquely different. Fruit and Crafty do exactly the same. Should we then assume Fruit is a copy of Crafty?

If we look deeper still, we see that Rybka has a unique table. A table only Vas could have programmed, and a table that is used only by this open file function, and a table that doesn't exist in Fruit. That's the square forward bitmap. To make that table you need code embedded in two loops, one looping on squares, the other looping down the rank until off board. Fifteen, twenty lines? Storage set aside. Tested, bugs dealt with. Non-trivial. Not exactly complicated, but certainly more complex than the code you claim Vas needed to copy. if A=0 B=2 else B=5; Who are you trying to fool here?

And where is the extra necessary code for this function shown in your documents? The code that is in Rybka but not in Fruit and is essential for the Rybka open file code and without which it will not work? Seems you like to show snippets that graphically match but don't actually match, simultaneously claiming they EXACTLY match and conveniently forgetting sizeable necessary chunks for the same function that don't match at all because they don't even exist in Fruit and which show self-writing?

And then if we look deeper still, we see that this forward rank bitmap is colour dependent. Rybka needs one for black and one for white. So Rybka has to account for that in it's code. You mentioned this to us, did you? or is this just another inconvenient difference between the Rybka Fruit codings that you like  to forget while simultaneously claiming they EXACTLY match?

And, then we look deeper still, we see Crafty and Rybka use 64bit masks, unsurprisingly, but Fruit has yet another data structure, a sort of pseudo byte accessed ninety degree rotated pawn bitboard. So, our poor cut and paste copier Vas, now, instead of writing this simple if then else code himself in two minutes, now has to erase this byte access line and rewrite it, go and hunt in Fruit for where this table is defined and erase it, go find the initialisation code and erase that, go through all the header files and erase the references, presumably go hunting in MOVE and UNMOVE for the update and downdates code and erase them, go look for anything else in Fruit that possibly uses this pseudo bitboard and modify that. And then test for and deal with all the unknown side effects of these changes, and then, finally, he can return and finish off the three lines of if then else code he so laboriously "copied" from Fruit?

Who exactly are you trying to kid?

And, to return to your question. Does it match? Well, I think I answered that. The right question is actually "does it show or prove copying?". I think, as you say, "there is only ONE answer".

Your move .....
Parent - - By bob (Gold) Date 2013-09-16 22:41
How do you figure that fruit and Crafty do exactly the same thing?  Code is different.  At a meta-level, all 3 are equal since they credit a rook for being on an open or half-open file.  I have MORE half-open file code a little further down, however.

Namely:

[code]

   if (tree->dangerous[side]) {
      moves = king_attacks[KingSQ(enemy)];
      t = ((rook_attacks[square] & moves)
          && AttacksRook(square,
              OccupiedSquares & ~(Queens(side) | (Rooks(side)))) & moves) ? 1
          : Distance(square, KingSQ(enemy));
      tree->tropism[side] += king_tropism_r[t];
    }
[/code]

I look to see if the rook attacks a square that the enemy king attacks.  For example, enemy king at f8/g8/h8, black pawns at f7/g7/h7, white rook attacking any one of those pawns.  If a pawn is behind the rook, doesn't change a thing because I want to see if the rook attacks a square next to the opponent king.  If there is a knight or bishop (friendly) in front of the rook, it doesn't count.  If there is a rook or queen (a battery) it does count.  But the score is not a constant.  It gets fed into a bit more complex formula later that gives larger scores for more pieces attacking that king.

For open and half-open files, they are all similar.

You now want to take the bitmap approach and again, claim it is different, because you have to do things differently.  Bogus argument and you know it.  I have that same code in Crafty, the code that initializes each useful bitmap pattern.  And it ends up doing (not using 2 loops as you claim, however) some calculations at startup that can then be avoided at execution time.  This "table" doesn't exist in fruit because Fruit has to scan the squares sequentially thanks to being a mailbox program.  You guys are trying any and all distorted definitions to make this go away.  It is not going to happen.  BFL wants to claim that this "bitmap" you describe above is copyrightable.  A single 64 bit integer number.  What a crock.  He then claims it is ok for Vas to copy's PST formulas or values, because they are NOT copyrightable.  You claim that fruit and rybka are completely different because one is bitmap, one is mailbox.  Unfortunately, I have an old mailbox program, and a bitmap program that was derived from it.  I know that's nonsense.  Anyone else that has converted from mailbox to bitboard knows that is nonsense.

why should anyone point out there are details dealing with color?  That is true of BOTH programs, you realize?  The "pawn mask" can even be found in older versions of Crafty, and most certainly in Cray Blitz.  That's one of the many ways one can do equivalent operations in each different representation.  Using a different board representation does NOT make a program unique.  Already discussed that with regard to Cray Blitz (fortran mailbox) and the early versions of Crafty (C bit board).  That argument does not hold water.

You'd think you had never seen a chess program before.  I know that to be false, so I simply believe you are trying to be disingenuous.

I'll remind you again, this is OVER, unless Vas approaches the ICGA.  Based on the last almost 2 years, that is not going to happen.  Continuing to argue about the process or verdict is going to have absolutely no effect on the ICGA.
Parent - - By Banned for Life (Gold) Date 2013-09-16 23:10
BFL wants to claim that this "bitmap" you describe above is copyrightable.  A single 64 bit integer number.  What a crock.

You are one stupid redneck. You are the imbecile that said this. Your senility has progressed to a very advanced stage where you can't even remember the idiotic things you wrote a few minutes ago...
Parent - - By bob (Gold) Date 2013-09-17 05:48
I've never said a bitmap mask could be copyrighted.  Not once.
Parent - By Banned for Life (Gold) Date 2013-09-17 07:13
Yes, you did make this claim. You have claimed that PSTs are subject to copyright and that bitmasks are equivalent to PST tables.

I have never claimed that either a PST or a bitmask is subject to copyright, with the standard exception that the arrangement of a large number of either is eligible for copyright, in the same manner as a phone book.
Parent - - By Ugh (*****) Date 2013-09-17 11:36
Thanks for your rambling, incoherent non-answer.

What Crafty does elsewhere is not revelant. In the code example you introduced and that we are discussing, the Rybka code is quite unique. For that and the other six reasons you failed to address it cannot have been copied.

Crafty and Fruit do the same thing exactly in the code you showed. I can't help you if you want to deny a demonstrable truth.

Fruit and Rybka do not do the same thing, Rybka's algorithm is uniquely different and plays different chess. If you want to deny that truth, I can't help you.

Your insultative argument with BFL is not relevant to this discussion.

What Crafty and Cray Blitz do elsewhere is not relevant.

You claim unique code is IDENTICAL when it has six or seven differences in seven lines! You use this untruth about this code to destroy the business and reputation of another human being. Not good.
Parent - - By bob (Gold) Date 2013-09-17 18:38
Please answer this.  I will take a piece of Code from Cray Blitz, which was fortran/mailbox, and post it side-by-side with the corresponding piece of code in crafty, which is C/bitboards.  It would seem they can not POSSIBLY match exactly in functionality, is that correct?  And if there is just one line, or one bit different between the two then one can not be a copy of the other?  Final conclusion from that is that one can not copy code, and then modify it.  Some immutable law in the universe prevents copied code from being modified?  How did Fabien gain +400 Elo over 18 months with fruit?  He copied version 1.0 to make version 1.5, which would mean he could not make ANY changes?  Or would it mean that 1.5 is now COMPLETELY ORIGINAL?

That is a nonsensical argument.  Nobody has claimed Vas did not make changes after he copied Fruit (or Crafty for that matter).  In fact it is generally accepted that the exact opposite happened.
Parent - By Venator (Silver) Date 2013-09-17 18:41
Nobody has claimed Vas did not make changes after he copied Fruit (or Crafty for that matter).  In fact it is generally accepted that the exact opposite happened.

You have said on several occasions that 'Rybka is just a copied Fruit with a few hacks'.

Once again: today we use this argument, tomorrow it's next, just as it suits Bob.
Parent - - By Ugh (*****) Date 2013-09-17 19:11
You're rambling incoherently again. Let's reset to clear and simple, shall we?

This thread is about the rook open and semi open file code in Rybka Fruit and Crafty which you set out above. Rybka in Fruitifed form of course. Weightings have been abstracted and are being ignored as is your way.

Your code, Crafty code, does EXACTLY the same as Fruit. Same chess position, same output always.

The Rybka code is unique. You have been unable to provide any program that behaves in the same way. Same chess position, different output when the particular condition uniquely tested for is met.

The rybka algorithm is different. Rybka uses a side to move colour dependent mask. Not Fruit and not Crafty. Rybka code subsequently has a black and a white version, it appears twice, differently. Not Fruit and not Crafty.

Therefore, answering your matching question again.

Fruit==Crafty!=Rybka

And answering the real question, do these code snippets show or prove copying? In the case Fruit Rybka, no. In the case Fruit Crafty, you can claim they were copied if you want, I won't argue with you, but I suspect not, despite the similarities.

Cray Blitz written in Fortran or Klingon, all the same to me, whether converted to Crafty or not, is just a rambling diversion I have no interest in.
Parent - - By bob (Gold) Date 2013-09-17 21:09
Sorry you can't follow my crafty example.  I gave you ALL the half-open/open-file code from crafty.  There are three parts.  1.  is the rook on an open file?  2.  Is it on a half-open file.  3.  Is it on a file where it directly attacks the opponent king.  ALL of those are right together.  Fruit also has a slightly different rook attacking king bonus, namely that there be no friendly pawns on the file, while Crafty doesn't care about friendly pawns, it wants a direct path to the opponent's king not blocked by pawns, knights or bishops.

I'll try to wade through all the crafty old versions, as several did do the "rook in front of pawns" idea.  And I have some test data on this idea (among others).  I'll dig it up and post it as well...

Once I get home later...

Of course you have no interest in anything remotely related to this idea of copying / modifying.  It is real.  It has happened in the past.  It happened in this case.  And it will almost certainly happen again...
Parent - - By Ugh (*****) Date 2013-09-17 21:31
This is getting silly. I don't care what your Crafty example does. In the code of Rybka, Fruit and Crafty that you showed, I have one point and one point only to make, here it is repeated for you:

This thread is about the rook open and semi open file code in Rybka Fruit and Crafty which you set out above. Rybka in Fruitifed form of course. Weightings have been abstracted and are being ignored as is your way.

Your code, Crafty code, does EXACTLY the same as Fruit. Same chess position, same output always.

The Rybka code is unique. You have been unable to provide any program that behaves in the same way. Same chess position, different output when the particular condition uniquely tested for is met.

The rybka algorithm is different. Rybka uses a side to move colour dependent mask. Not Fruit and not Crafty. Rybka code subsequently has a black and a white version, it appears twice, differently. Not Fruit and not Crafty.

Therefore, answering your matching question again.

Fruit==Crafty!=Rybka
Parent - - By Ugh (*****) Date 2013-09-17 21:54
One small addition if it helps you. I'm interested in the fact that this code shows that Rybka is not copied from Fruit. Nothing else. The Crafty code was introduced by you, I can agree that the way you constructed the IF THEN ELSE is not identical to Fruit, even though it is equivalent as Miguel points out. If all you are bothered about is Fruit-Crafty and my interest is Fruit-Rybka, then we can maybe agree to shut up? I don't have any need to drive the Crafty-Fruit point onwards, nor am I interested in having a stratospheric posting count to match yours.
Parent - By Rebel (****) Date 2013-09-17 22:42
Introducing Crafty serves as a distracting maneuver.
Parent - - By bob (Gold) Date 2013-09-17 23:05
OK, let's take JUST rybka and fruit.

A pseudo-code comparison goes like this.  Now after looking at the pseudo-code, what is different?  one thing.  Fruit looks for no friendly pawns on the file, rybka looks for no friendly pawns in front of the rook on this file.  The odd add if-then subtract-then-add approach is used in both.

Crafty checks the same thngs as fruit, but the code is different..

if there are no friendly pawns then
  if there are no enemy pawns
     add open-file bonus
  else
     add half-open-file bonus

You want to claim fruit and rybka are different in EVERY line.  I claim that for the CODE they are IDENTICAL in what they do and how.  For the DATA, fruit uses no friendly pawns on file, rybka uses no friendly pawns in front of rook on file. 

Do we agree so far???
Fruit                                                     Rybka

1.  If there are no friendly pawns on the file            1.  If there are no friendly pawns in front of the rook, on this file
2      then add rook on half-open bonus                   2.      then add rook on half-open bonus
3.     if there are no enemy pawns on the file            3.      if there are no enemy pawns on the file
4.        then subtract half-open bonus and add open      4.         then subtract half-open bonus and add open
             file bonus                                                 file bonus

Parent - - By michiguel (***) Date 2013-09-18 00:11

> A pseudo-code comparison goes like this.  Now after looking at the pseudo-code, what is different?  one thing.  Fruit looks for no friendly pawns on the file, rybka looks for no friendly pawns in front of the rook on this file.  The odd add if-then subtract-then-add approach is used in both.


You keep saying subtract like it is a real thing.

BTW, what is "odd" with this code?

A = 2
if (x) {
  A +=3
}

I do that all the time.

Miguel
Parent - - By bob (Gold) Date 2013-09-18 02:14
Not when it is REALLY

a=2
if (x)
a = a - 2 + 5

That is what the fruit code does.  It is pretty certain that is what the Rybka search does.  Due to constant folding, we can't see for sure of course.  But based on the other rybka/fruit similarities, the probability is "up there"...
Parent - - By michiguel (***) Date 2013-09-18 03:25

> Not when it is REALLY
>
> a=2
> if (x)
>  a = a - 2 + 5
>
> That is what the fruit code does.  It is pretty certain that is what the Rybka search does.  Due to constant folding, we can't see for sure of course.  But based on the other rybka/fruit similarities, the probability is "up there"...


That is your assumption, because it is not what it is there. So, "it could be" then "it is" for you.

Miguel
Parent - - By bob (Gold) Date 2013-09-18 13:35
No, not "is".  "is the most likely explanation."

A question:  Have you EVER seen a program that had the following scores:

rook_open_file = 35;
rook_half_open_file = 10;

I have.  Mine.  And EVERY other program I looked at does it the same way, two values, one for open, one for half-open.  I have a dozen source programs on my cluster testing list.

Next question.  Have you EVER seen a program that has the following scores instead of the ones above?

rook_half_open_file = 10;
delta_for_rook_open_file = 25;

I have not.  Not one that I have does that.  And yet you think it unreasonable to assume Rybka was written the same way every other program has been written in that specific regard?
Parent - - By Ugh (*****) Date 2013-09-18 15:02 Edited 2013-09-18 15:04
depends how the programmer thinks about it, you might expect an IM to think differently to a 1900 player about chessic things? After all, it is your use of the term half-open and open file to fix your thoughts on just the existence of pawns and, by existing, they get in the way. Perhaps he thinks of pawns as pawns that get in the way and pawns that don't get in the way. He thinks further and deeper than  you about it, and uses different words inside his head to describe his thoughts. Look it up in Language and Thought Psychology book.

how about:

if (my rook is not blocked from attacking forwards by my pawns) gimme some bonus and if (it is not blocked by enemy pawns) gimme some more bonus?

that would account for the first test being different, and junks your idea of a delta. Your delta is just a function of your world view. And there is no reason to suppose your world view has to be imposed on Vas, or be the only one.

And he is not actually testing for "open file" or "half open file" in your sense, is he? Because his test doesn't meet the normal definition of those terms. If he is not testing for them, the idea of a delta between them makes no sense anymore.

And, come to think of it, since Vas has not tested for half open and open, he has tested for another concept, why is it you think you can describe in the disassembly, the bonuses as HALFOPENFILE or OPENFILE. I know those make it match to look of Fruit, but the names are misleading, are they not?
Parent - - By bob (Gold) Date 2013-09-18 15:55
Here's a clue for you, JUST for reference.  I made this simple change to Crafty last night.  Ran two 30,000 game gauntlet matches on my cluster.  Version 23.7 is current version, version 23.7R02 is the same code, but with the Rybka-like open file definition instead.  23.7R01 was a separate change that seemed to hurt just a bit.  Here's the results:

   2 Crafty-23.7-2        2674    4    4 30080   66%  2547   24%
   3 Crafty-23.7R02-1     2674    4    4 30080   66%  2547   24%
   4 Crafty-23.7-1        2671    4    4 30080   65%  2547   24%
   5 Crafty-23.7R02-2     2671    4    4 30080   65%  2547   24%
   6 Crafty-23.6-2        2668    4    4 30080   65%  2547   24%
   7 Crafty-23.7R01-2     2668    4    4 30080   65%  2547   24%
   8 Crafty-23.7R01-1     2667    4    4 30080   65%  2547   24%
   9 Crafty-23.6-1        2667    4    4 30080   65%  2547   25%

So, this "wonderful and original idea" does NOTHING.  Big surprise.  If you recall, I had ALREADY done exactly that idea.  You commented on it years ago in r.g.c.c.  Because I added one refinement Vas did not have, the idea that if the rook is not on a truly open file, and there actually IS an actual open file, the rook must directly attack this file so that it can get there quickly rather than being trapped in front of its own pawns.  Remember that discussion?  This is not "new".  And in fact, it doesn't "work".

So get off the IM vs non-IM stuff.  I have played chess for a LONG time and while I am not a GM, I am also not a fish.  And I have had LONG discussions with GMs about such terms, if you recall...

As far as names go, one can not tell what the names are if the programmer intentionally strips the executable.  For the record, if you can find one of the old versions of Crafty where I was doing the same thing, I did use the same names for the eval terms.  Right or wrong...
Parent - By Venator (Silver) Date 2013-09-18 16:29 Edited 2013-09-18 16:47
Using Crafty as a benchmark to evaluate Rybka ideas is very dubious, of course. If a 2400 player would use a Carlsen opening novelty and fails to make proper use of it, it is because the player is too weak. I still remember your 'trivial' two lines of LMR code that brought you nothing after 4 weeks of testing :-).

It is 100% certain you took 'dozens' of ideas from Fruit, Toga, Glaurung, Ippo and Robbo and failed to make them work. This doesn't say anything about the ideas though, it says everything about the guy who is implementing them....
Parent - - By Ugh (*****) Date 2013-09-18 17:03
Introducing you to different ways of thinking about things is really hard work. So again, your response is an incoherent non-answer.

Crafty does not interest me, nor do ancient rgcc posts. Neither address the thread in hand. IM/GM/non-IM is very relevent to understanding the underlying chess concepts, or not.

Why do you find it acceptable to name Rybka's evaluation constants with terms that describe what another program is doing, but NOT what Rybka is doing? Rybka does not test for open files and semi open files, it tests for something else. Because you don't understand what Rybka is testing for, and you have no name for his concepts, doesn't give you the right to name them with BONUS CONSTANTS from Fruit.
Parent - - By bob (Gold) Date 2013-09-18 17:16
Because they match up so well?  Do you object to Richard naming the values in Rybka's hash structure to match fruit?  For all we know, he could have used a,b,c,d,e,f, etc for the names, correct? 

Do you know how hard it was to make the above change in Crafty to test it (rook in front of pawns rather than no friendly pawns anywhere on file)?  Hint:  beyond trivial.  You have the asm.  Let's just go with that to get off this "fruitified" nonsense, how about that?  I'll be happy to post the same code from Fruit to show how it too has folded constants, for example, so that we can get past this bit of nonsense...

BTW, of COURSE crafty nor ancient r.g.c.c posts interest you, because they tend to dispel much of this "great original new idea" that was actually known and used in the early 90's...
Parent - - By Ugh (*****) Date 2013-09-18 18:18
Has Richard finished? I assumed he would announce that as and when in some way.

They don't match up at all well. Rybka uses a different algorithm to both Crafty and Fruit. It does not test for "open files" by any definition of "open file" known. Since when does an open file have a pawn in it?

So what gives you the right to use the same BONUS CONSTANT names as Fruit? In Fruit the constants are named perfectly reasonably, the name says what they do. In the Fruitified Rybka ASM the names do not describe what Rybka does, they describe what Fruit does. Why are they not described for what they do? A different name so as not to mislead the readers?
Parent - - By bob (Gold) Date 2013-09-18 20:16
Why don't you look at the fruit asm as I suggested.  The match will be quite obvious then.  The two constants get folded into one, and you get just one add.
Parent - - By Ugh (*****) Date 2013-09-19 13:00
You skipped over the question. Rybka uses a different algorithm to Fruit and is not testing the same contructs as Fruit. So how come you find it acceptable to copy Fruit names from Fruit's different algorithm that apply to Fruits constructs and apply them to Rybka's code when Rybka is not doing the same thing and is testing different contructs?

Your Fruitified code snippet is deliberately designed to mislead and it is false in the terms that it is using. It is deliberately faked without any logical justification for the faking.
Parent - - By bob (Gold) Date 2013-09-19 15:40
There is a 1 AND operation difference between fruit and rybka.  Both are checking for the presence of pawns on a specific file, scoring for rooks only.  Seems perfectly natural to use the same names when checking the file status of a rook.  It is not "faked".  It is not "false".  There is nothing different except for that one point, ignore friendly pawns behind the rook.
Parent - - By Ugh (*****) Date 2013-09-19 17:10
Rybka is NOT checking for an open file. An open file does not have one pawn on it, let alone two pawns on it.

According to you a white pawn A4, black pawn A5 and a white rook on A7 is an open file? Because if Rybka finds that it gives the rook a bonus, which you call "open file bonus". It looks more like "attack enemy pawn structure from behind bonus". And that is how it acts, chessicly, compared to both your Crafty and to Fruit, both of which do not pick up that situation and thus have a rook pawn ending blind spot. Worse than that, Fruit and Crafty PENALISE the rook for getting into the optimal situation, according to chess theory. How dumb is that?

And the only reason you falsely give the bonus the fake name, lifted out of the Fruit code, is to have the words and letters in two columns, one for Fruit and one for Rybka, to give the false impression to skim readers and non programmers that they are the same. They are not the same. You faked the Rybka column with false words.
Parent - By bob (Gold) Date 2013-09-19 17:52
You can define "open file" however you want as a programmer.  I've done it several different ways over the years.  Including "rook in front of friendly pawns".  And I have also further qualified it with enemy pieces.  Is that open file very good if your opponent has a bishop or knight stuck at e3, with pawns at d4/f4?  If you try to remove the piece, the file gets closed with a protected passed pawn.  If you don't, your rook has two squares, e1 and e2.  So is that file REALLY open?  Or would the rook be better placed on the c file which is open and unblocked?  There's lots of choices.  Each is a compromise in terms of accuracy and speed.  I use what tests as better, not what I think is better.

When I used that idea way back, I still kept the same score names.  I COULD have renamed them "pseudo-open-file" and "pseudo-half-open-file" but I didn't.  I knew what they meant.  If you want, change rybka's variable names to X and Y.  Similarity does NOT "go away" at all.  Unless you only look at characters and not semantics...
Parent - - By Rebel (****) Date 2013-09-19 16:49
From your VIG brother Watkins.

Rybka-Fruit overlap open rook files 0.7
Crafty-Fruit overlap open rook files 0.6

Rybka-Fruit overlap semi-open rook files 0.6
Crafty-Fruit overlap semi-open rook files 0.6

As you know 1.0 means equal.

Shall we stop discussing this one?
Parent - - By bob (Gold) Date 2013-09-19 17:09
Whatever you want.  That IS just one term.  Shall we re-visit hashing since it is a large block of code?  Much larger than these 10 line things we have been discussing...
Parent - - By Ugh (*****) Date 2013-09-19 17:32
It is one MORE term in which you have been quite unable to demonstrate copied code. Can you tell us how it is possible to write that sort of open semi open file code without you saying it is copied?

You can write the suitable code yourself if you want. Your start materials are bitmaps and filemasks .....

Oh, sorry, I forgot, you already wrote it in Crafty. Your suitable code is fully equivalent to Fruit's. So please tell us, how is it that your code, fully equivalent to Fruit, is "ok", but the Rybka code which is algorithmically different and does something else is "not ok"?

It is abundently clear that any code Vas could write to perform this function, differently or not, you would say was "copied". Same with mobility. Whatever he did there, algorithmically different even as it was, you say "copied". Again, there is nothing he could have done to stop you. PST's likewise.

Ok, we understand, he copied A, not because you can show he copied A but because he copied B,C,D,E and F. A was just "interesting"

And he copied B, not because you can show he copied B, but because he copied A,C,D,E and F. B was just "interesting".

And he copied C, not because you can show he copied C, but because he copied A,B,D,E and F. C was just "interesting".

I should have just made an incrementing do-while loop, should I not?
Parent - - By bob (Gold) Date 2013-09-19 17:46
First, my code is not "fully equivalent to fruit".  I have already posted mine.  The if statements are organized differently.  To me they more closely reflect how I evaluate a rook with regard to open/half-open files.

You can take fruit's code, convert it DIRECTLY to bitboards, and you get exactly what is present in Rybka, excepting that pawns-behind-rook test.  To change that requires changing the mask only, none of the other code.  Something that is either done at initialization time or which is hard-coded.  (I have been pretty inconsistent doing this, some of my masks are simply hand-coded and initialized at compile time, some are initialized at run-time in the usual way).  But it doesn't change the code in the evaluation one scintilla, which is a key.
Parent - - By Ugh (*****) Date 2013-09-19 19:55
BS. The key to show NOT copied is that the Rybka code is unique, uses a different algorithm, evaluates differently, works sensibly in the endgame, and shows original thought. Meanwhile, your code could be copied from TSCP for all the originality you showed, and, compounding the tragedy, is actually telling your rook to play badly in endgames.

The truth of course is very simple, this evaluation concept has been around for ages, everybody uses it, even to the extent of your famous semantic equivalence, in fact it would not surprise me if this code were the widely equivalent across more programs than any other; except for one person. Rajlich, who thought before he wrote his code, and came up with something new and original.

Enough. You can say black is white, 0 is 1, true is false, whatever silly nonsense you want. Destroy a few more virtual forests with your BS, BS is still BS.
Parent - - By bob (Gold) Date 2013-09-19 20:24
If you copy something, and change ONE constant, that does NOT make that copied code original.  No matter how many times you repeat it, it simply does not work that way.

The question is not about a SPECIFIC evaluation term.  One is meaningless.  The question is about a BUNCH of evaluation terms that all show marked similarity, particularly when compared to other programs where things are done significantly differently.  Every time I show you how I do something differently, or every time I show you how another program (other than fruit/fruit-derivatives and Rybka) does something differently from Fruit/Rybka, your answer is always the same.  "Don't try to change the subject or confuse the discussion with unrelated data."  That's disingenuous, to be kind.  The fact that other programs are so different from each other in their procedures, structures, organization, is perfectly relevant.
Parent - - By Ugh (*****) Date 2013-09-19 21:18
If you copy something, and change ONE constant, that does NOT make that copied code original.

Thanks, I see it now.

If he copied then he copied.

Doesn't make any difference what he does or how he does it, different algorithm, different code, different chess, new lookup table, new initialisation code for the new table, destruction of the Fruit pseudo-bitboard byte lookup table, destruction of the initialisation, destruction of header file references, destruction of makemove and unmakemove updater and downdater, hunting for other references, hunting, testing and fixing bugs caused by knock on effects, all just to write six lines of IF THEN ELSE, the simplest construct known to a programmer. And with a unique new idea which tells us he really UNDERSTOOD chessicly what he was doing, understood way better than you.

Yeah, very convincing Bob. Absolutely how one of the top five chess programmers (your words) with an IM rating against your somewhat pathetic 1900 ELO, a chess program way stronger than any other by hundreds of ELO, yeah, absolutely how he would need to code one of the most common ideas in computer chess.

If he copied ..... hahaha.

Suggestion. Consider the painful thought that he didn't copy if you can bear it. And consider how he might have self written this simple, but unique code in a couple of minutes, having chewed over the rook-pawn interactions chessicly in his head, or his notes, beforehand.
Parent - - By bob (Gold) Date 2013-09-19 21:44
If he copied, and made minor changes, it is still a copy.  He MIGHT have written that small snippet originally, no argument.  But the probability that he wrote all the snippets just like fabien stretches probability too far.  Ed's already punted on the hashing code.  Dead ringer.  There's simply too much.  You want to use an extremely short attention span, focus on one snippet, say "this is pretty simple..."  and then move on.  There are too many of those matches however.  And a short attention span is not a method of dismissing each one individually.  I can remember longer than that...
Parent - - By Rebel (****) Date 2013-09-19 22:06
Ed's already punted on the hashing code.  Dead ringer.

Please don't twist my words.

Honesty is a bit of a problem for you, I give you one finger (TT is controversial) and you take the whole hand implying more than what I have stated.

Do you think people don't see through that?
Parent - By bob (Gold) Date 2013-09-19 23:39
I posted the code side by side.  It was not "controversial".  It was convincing.  VERY convincing.  Do you think people didn't see that?
Parent - - By Ugh (*****) Date 2013-09-19 22:38
Has Richard Vida finished his stuff yet?

In the Zach evaluation function document there is no identical code and no code you can prove was copied, there are too many differences everywhere, and the deeper we look, the more we see the lack of matches and the more differences. We see no unique code in Fruit, there's nothing in the  Fruit eval that isn't somewhere else or described elsewhere or generally known, usually all three at once.

As you said, you are unable to find anything directly copied, so you were forced back on "indirectly copied", which, as you also said, is very hard to prove. You simply haven't proved it. Casting suspicion is not enough. You need PROOF.

"He MIGHT have written that small snippet originally, no argument"

Indeed, you don't know either way. You can't prove either way. We can't prove he didn't copy it either, but the onus is on YOU to make the proof, and you haven't done it, as you just admitted.

He might also have written the entire program originally, no argument either. You don't know, nor can you weight the possibilities other than with wild and subjective guesses that have no meaning or basis in logic. Case not proven should have been the verdict. Your "investigation" should have been inclusive and cooperative and positive and looked at how to adjust given the changes in the process of how chess programs were developed in the wake of increasing publication of increasingly strong open source programs.
Parent - By oudheusa (*****) Date 2013-09-20 15:46

> Has Richard Vida finished his stuff yet?


I fear Richard has walked away from this.
Parent - - By Rebel (****) Date 2013-09-19 19:37 Upvotes 1
Whatever you want.  That IS just one term.

Fine, case solved, you were wrong.
 

Shall we re-visit hashing since it is a large block of code?  Much larger than these 10 line things we have been discussing...

No need to re-hash the hash, I already admitted its status is controversial.
Up Topic Rybka Support & Discussion / Rybka Discussion / Rook half-open and open files
1 2 3 4 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill