Not logged inRybka Chess Community Forum
Forum RybkaChess Help Search Register Login
Up Topic Rybka Support & Discussion / Rybka Discussion / With permission of Cock de Gorter (locked)
1 2 3 4 5 6 Previous Next  
Parent - By bob (Bronze) [us] Date 2011-09-30 22:35
Is that supposed to make any sort of sense?  We already KNOW what happened.  Seeing the source would convince the "devout believers that nothing was copied" that it was, exactly as we have said.
Parent - - By Rebel (****) Date 2011-09-30 19:51
Scaled and different, you know that.
Parent - - By bob (Bronze) [us] Date 2011-09-30 21:16
scaled == different.  You know that...
Parent - - By Rebel (****) Date 2011-09-30 21:55
Binary 3200 is a nice base value for a pawn.

Shift 5 bits and you have the conversion to decimal in just 1 instruction.

Very clever and original of Vas.

But of course it's a deliberate obfuscation to hide the Fruit origin.

Gimme a break :razz:
Parent - - By bob (Bronze) [us] Date 2011-09-30 22:16
He doesn't ALWAYS use 3200.  He also uses 3399.  Not so nice for a shift?  And yes, I'd be willing to bet that this figures into his obfuscation ideas somewhere, because what sense does it make to start with values that are 32x larger than normal, then shift right 5 bits at the last second???  Why not just use 100 all the way???

We'll likely never know why?  Only that he did it.  Just like he whacked up the node counter, the depth display, and cut the PVs short...
Parent - - By Rebel (****) Date 2011-09-30 22:25 Edited 2011-09-30 22:29

>  He also uses 3399


Yeah, a nice tuning parameter.

I have one myself,

[Attractiveness = 101]

A comparable value (3399 vs 3200) would be 106
Parent - - By bob (Bronze) [us] Date 2011-09-30 22:33
Maybe 106.21875 rather than 105?  Not a very common number in an integer program.  In any case, numbers can easily be changed, while code remains the same more frequently than not...

Which is what appears to have happened here...
Parent - - By Rebel (****) Date 2011-09-30 22:55
You don't seem to like a common practiced tuning idea in chess programming.

You prefer VIG that states: obfuscation.
Parent - - By bob (Bronze) [us] Date 2011-09-30 23:07
You REALLY want to say that a tuning process would multiply EVERYTHING by 3200?   Which doesn't change a thing except the displayed scores, of course.  So pawn=3200 is not a "common practiced tuning idea in chess programming."
Parent - - By Rebel (****) Date 2011-10-01 12:37
VIG states:

Fruit pawn value = 100
Rybka pawn value = 3200 -> OBFUSCATION hiding Fruit origins.

VIG further states:

Rybka 3200 vs 3399 -> ADVANCED OBFUSCATION further hiding Fruit origins

Common sense states:

All of this provided that brilliant Vas realized in 2005 (when none had heard about him) he would become so famous that he foresaw the scenario that his program would be disassembled, reverse engineered by Osipov (Strelka) and yet Vas was stupid enough to call Strelka his own.

I definitely prefer common sense 3399 being just an EVAL tuning parameter.
Parent - - By Trotsky (****) [fr] Date 2011-10-01 12:57
They assumed guilt from the start. That means anything and everything they find has to be explained in terms of guilt (as you just showed).

Likewise the openfile code CONSTANT split into two constants. They then explain how the resulting cheated listing (with looks similar to Fruit) proves the guilt that they assumed in the first place to allow them to create the cheated listing.

If that is not the use of a circular argument I do not know what is.
Parent - - By Rebel (****) Date 2011-10-01 16:38
Yep..... and also that (although in retrospect) there hardly was any opposition during that 2006-2011 period allowing the minds get ready for deception because of that same lack of opposition, then when the documents were finalizing and looked convincing Vas' faith was sealed. As such I understand the Panel talks, just 214 postings by 34 people. A formality.

With the knowledge and opposition of today I wonder if things would have made a difference.
Parent - By bob (Bronze) [us] Date 2011-10-01 17:12
214 postings.  HUNDREDS of emails between individual people working on specific things.  For example, the "crafty evidence" was not made public until after it had been carefully checked by several of us.  You only THINK you know what went on.

Today's very limited opposition would not have changed a thing, the evidence still stands, and that is a major problem...
Parent - - By bob (Bronze) [us] Date 2011-10-01 16:31
The well-known pawn values, used by almost everyone are (a) 100, (b) 128 (deep thought, etc, making it a power of 2 to allow divisions to be replaced by shifts;  (c) 256, which makes it again a perfect power of 2.    Why he chose 3200 is unknown, and I won't speculate very much.  But we do KNOW that he obfuscated the depth and node counts (is that a VIG statement or a pure statement of FACT, BTW?).  So it is not unreasonable to assume that obfuscation played a part.

This is not about your nonsensical VII/VIG stuff, it is simply about common sense.
Parent - - By Rebel (****) Date 2011-10-01 16:48

> Why he chose 3200 is unknown, and I won't speculate very much.


You (once?) used 1000 if I remember well.

> But we do KNOW that he obfuscated the depth and node counts (is that a VIG statement or a pure statement of FACT, BTW?).


Fact.

And in fact Vas obfuscation of the depth made R1 more look like Fruit, similar depths while in reality R1 searched 2-3 plies deeper than Fruit.

So then what is the meaning of the depth obfuscation?
Parent - - By bob (Bronze) [us] Date 2011-10-01 17:10
I did use 1000.  I found the extra precision worthless.  And, in fact, coarser resolution leads to a faster search since we prune on <= and >=, rather than just < or >.  Fewer "intervals" means more "equals".
Parent - - By Trotsky (****) [fr] Date 2011-10-01 17:17
I did use 1000.  I found the extra precision worthless.

What a 1900 patzer programmer with very low chess knowledge (Hyatt) can and can't do with his evaluation cannot be used as basis for what an IM superprogrammer with very high chess knowledge can or can't do.

The patzer experience is valueless here, so spare us from your dumbing down please.

And, in fact, coarser resolution leads to a faster search since we prune on <= and >=, rather than just < or >.  Fewer "intervals" means more "equals".

Yup, patzer with hammer only in toolbox is unable to fine tune. What's new?
Parent - - By bob (Bronze) [us] Date 2011-10-01 17:34
I seem to have done MUCH more "fine tuning" than you?  Should we compare head-to-head record on ICC for reference?

My search for cstalx vs crafty produced this:

Crafty won 32, drew 11, and lost 6.  Or +37.5 -11.5 which is a 200 Elo "gap" between patzer and prodigy.  How'd the patzer manage to win, exactly?  Luck?  Or maybe "better program"??? 

Not bad for a "patzer's tuning" wouldn't you say?  I find it funny that you could never beat me, not even close, yet "I" am the "patzer" and "you" are the "prodigy".

Something wrong with your terminology, IMHO...  BTW this patzer seemed to be MUCH more capable of fine tuning that you were...  Makes your comments appear to be just a bit worthless?  BTW, I suppose I am now, once again, a "bean counter" for counting those damned wins and losses and using that to draw conclusions, rather than just "guessing"???
Parent - - By Trotsky (****) [fr] Date 2011-10-01 19:16
I am not "my" ancient old program and "you" are not Crafty. Do you desire to be a robotic thing? Shouldn't be too much of a leap ;-)
Parent - By bob (Bronze) [us] Date 2011-10-02 03:59
I wrote Crafty.  You have made more than one comment on MY programming ability.  Since mine was clearly better, what does that say about YOUR programming ability, assuming mine is so poor???
Parent - By Watchman (***) Date 2011-10-02 07:37
"I seem to have done MUCH more "fine tuning" than you?"

Yo, I told you
you can't touch this
Why you standin' there man?
you can't touch this

"Should we compare head-to-head record on ICC for reference?"

Yo sound the bell... school's in sucka
you can't touch this

"The patzer experience is valueless here, so spare us from your dumbing down please"

You gotta get hype boy
Because you know Chris you know...
you can't touch this

"Since mine was clearly better, what does that say about YOUR programming ability, assuming mine is so poor???"

Ring the bell...  school's back in

Break it down

Stop
Crafty time

you can't touch this
you can't touch this
you can't touch this
Parent - - By Rebel (****) Date 2011-10-01 17:30

> I did use 1000.  I found the extra precision worthless.  And, in fact, coarser resolution leads to a faster search since we prune on <= and >=, rather than just < or >.  Fewer "intervals" means more "equals".


Precisely my thoughts as well, the goal of 3200/32 -> more equals (but better rounded) -> more beta-cutoffs -> (somewhat) faster search.

Never tested the idea, I could be wrong.
Parent - - By bob (Bronze) [us] Date 2011-10-01 17:36
Wouldn't it be more efficient to simply use the correct 1/100ths units and avoid the divide, not to mention the messy 3399 used elsewhere???
Parent - - By michiguel (**) Date 2011-10-01 17:51

> Wouldn't it be more efficient to simply use the correct 1/100ths units and avoid the divide, not to mention the messy 3399 used elsewhere???


There is no such thing as "correct" unit, and the answer is no, it is not more efficient.

Miguel
Parent - - By bob (Bronze) [us] Date 2011-10-02 04:12
It is ABSOLUTELY more efficient because there is no shift right 5 bits (divide by 32) needed at the end of each evaluate.  That was the only "efficiency issue" I can see, performance.
Parent - - By michiguel (**) Date 2011-10-02 17:55

> It is ABSOLUTELY more efficient because there is no shift right 5 bits (divide by 32) needed at the end of each evaluate.  That was the only "efficiency issue" I can see, performance.


I was referring to the automatic tuning efficiency, which is of course more important than one shift in the program.

Miguel
Parent - - By bob (Bronze) [us] Date 2011-10-02 21:32
I don't believe anyone is seriously doing THAT kind of tuning.  I've seen one example written up (Cozzie) that did not work very well...  Mine is a more manual approach where I can vary any values I want, one at a time or more...
Parent - - By michiguel (**) Date 2011-10-02 22:04

> I don't believe anyone is seriously doing THAT kind of tuning.  I've seen one example written up (Cozzie) that did not work very well...  Mine is a more manual approach where I can vary any values I want, one at a time or more...


I do, and I am not the only one. I open a thread about it ~2-3 years ago at Talkchess, when I started to have some success with it since my first attempts by 2006. Why do you think I was telling you all this? Having more resolution would have made task easier.

Marcel McKervinck reported something at CCC recently, and Remi Coulom wrote a tool for tuning. Stockfish did some sort of (secret) automatic tuning too and AFAIK, Hannibal team was attempting something. Whether this is the way to go it is irrelevant. It is very obvious that VR tried something of this kind.

Miguel
Parent - By bob (Bronze) [us] Date 2011-10-03 12:28
So again we are into mind-reading?  (it is very obvious that ...)
Parent - By Rebel (****) Date 2011-10-01 18:36
As said already, using a large base value such as 3200 gives a better rounding result after 3200/32.
Parent - - By michiguel (**) Date 2011-10-01 17:49

>> I did use 1000.  I found the extra precision worthless.  And, in fact, coarser resolution leads to a faster search since we prune on <= and >=, rather than just < or >.  Fewer "intervals" means more "equals".
> Precisely my thoughts as well, the goal of 3200/32 -> more equals (but better rounded) -> more beta-cutoffs -> (somewhat) faster search.
>
> Never tested the idea, I could be wrong.


Of course, you do all calculations with maximum precision and round at the end. Error handling 101, if you took any course in an experimental science (chemistry, physics etc). I have been using 256th of a pawn since the beginning, because it looks an appealing number for a programmer, but if I have to rewrite my engine, I would seriously consider using a much higher resolution. There are many ideas you can try.

For instance, (I am digressing now), If you use 1/4096 of a pawn, you can have all a zone between -31 and +32 that are all virtual draws. However, you can assign "different" type of draws. i.e. some draws are more appealing than others (stylistically speaking) and the alpha-beta will pick them up. Sort of a micro contempt that could be used always, even if you set contempt = 0. A typical case could be KRPKR TB cases, in which many of the draws could be scored differently and "squeezed" in that "draw zone" safely.

Miguel
Parent - - By Rebel (****) Date 2011-10-01 18:47
Which means we have a perfect reasonable explanation for the 3200 and 3399 use in Rybka.
Parent - - By pepa (*) [cz] Date 2011-10-01 19:11
Hmm, and where does this shifting by 5 take the place? If inside the evaluation, then it could not be used for the mentioned purpose in the search.
Parent - - By bob (Bronze) [us] Date 2011-10-02 04:13
It is done at the end of the evaluation...
Parent - - By pepa (*) [cz] Date 2011-10-02 11:21 Edited 2011-10-02 11:24
Hope Ed will not be disappointed. Of course, in any case he can say that evaluation has been just prepared for future development.
Parent - By Rebel (****) Date 2011-10-02 22:27

> Hope Ed will not be disappointed. Of course, in any case he can say that evaluation has been just prepared for future development.


That's not what I said.

3200 gives faster search due to better rounding (3200/32).
Parent - - By Rebel (****) Date 2011-10-01 19:22

> For instance, (I am digressing now), If you use 1/4096 of a pawn, you can have all a zone between -31 and +32 that are all virtual draws.


I believe it was Dappet that used this technique for draw scores.

Very original I must say.
Parent - - By bob (Bronze) [us] Date 2011-10-02 16:05
Cray Blitz used this in the 80's.  You can find a paper in the JICCA "The Cray Blitz Draw Heuristic," Hyatt, Nelson.  Not only did we come up with draw scores that indicate "degree of drawishness" (Current crafty uses scores like -0.01 (draw, black is ahead in material), 0.00 (draw, material is equal), and 0.01 (draw, white is ahead in material)) we also used a "distance to draw score" where if we were ahead or behind, we used a + or - (respectively) draw score that reflected the number of plies to the draw, so that if we were ahead, we gave the opponent the greatest number of moves possible to make a mistake.  We won more than one game using this.  John Stanbeck can tell you about one in particular.  :)

We just carved out the window between +0.100 and -0.100 to represent these values...
Parent - By michiguel (**) Date 2011-10-02 16:50

> Cray Blitz used this in the 80's.  You can find a paper in the JICCA "The Cray Blitz Draw Heuristic," Hyatt, Nelson.  Not only did we come up with draw scores that indicate "degree of drawishness" (Current crafty uses scores like -0.01 (draw, black is ahead in material), 0.00 (draw, material is equal), and 0.01 (draw, white is ahead in material)) we also used a "distance to draw score" where if we were ahead or behind, we used a + or - (respectively) draw score that reflected the number of plies to the draw, so that if we were ahead, we gave the opponent the greatest number of moves possible to make a mistake.  We won more than one game using this.  John Stanbeck can tell you about one in particular.  :)
>
> We just carved out the window between +0.100 and -0.100 to represent these values...


With a higher resolution you can implement this more safely. Particularly, at the current depths we are seeing. I believe that window is too big because you end up comparing it to true +0.100 advantages in very distant parts of the tree.

Miguel
Parent - By bob (Bronze) [us] Date 2011-10-02 04:07
You can do the same draw trick with 1/100th.  Or 1/1000th.  I've done it in both and found no significant difference.  I, as a human chess player, remain unconvinced that the concept of 1/1000th of a pawn is a meaningful value anyway.  Which is why I went to 1/100th a long while back.  Although that has little relevance to the current discussion...
Parent - - By michiguel (**) Date 2011-10-01 03:12

> He doesn't ALWAYS use 3200.  He also uses 3399.  Not so nice for a shift?  And yes, I'd be willing to bet that this figures into his obfuscation ideas somewhere, because what sense does it make to start with values that are 32x larger than normal, then shift right 5 bits at the last second???  Why not just use 100 all the way???
>
> We'll likely never know why?  Only that he did it.  Just like he whacked up the node counter, the depth display, and cut the PVs short...


I am almost sure I know why. Because you can tune the parameters that way. To do many tuning techniques you need enough resolution to obtain derivatives or a similar concept. You generally obtain that using floating point, but if you use bigger integers, it may be good enough. If you look at the numbers, it is clear that they were tuned.

Miguel
Parent - - By bob (Bronze) [us] Date 2011-10-01 16:33
So "millipawns" is not enough resolution?  Units of 1/1000th of a pawn is not accurate enough, but units of 1/3200th of a pawn are "just right?"  Then why does he then divide everything by 32 after computing that big number?
Parent - - By Rebel (****) Date 2011-10-01 16:56

> So "millipawns" is not enough resolution?  Units of 1/1000th of a pawn is not accurate enough, but units of 1/3200th of a pawn are "just right?"


I have been happy with 256 all my life.

> Then why does he then divide everything by 32 after computing that big number?


Binary to decimal in 1 instruction: score=score>>5;
Parent - - By bob (Bronze) [us] Date 2011-10-01 17:08
3200 is not a binary number.  BTW 1600 would have that same characteristic, as would 800, 400 and 200. 

I've yet to see a valid justification for millipawns, in the first place.  Why would you want to have scores that are 32x larger than normal, then convert 'em back to normal by dividing by 32?  Why not just use the final score and avoid even that shift?
Parent - - By Trotsky (****) [fr] Date 2011-10-01 17:22
Doh! In a final release version maybe, but in betas, tests and development versions where weights are extracted, modified, balanced by some automated process, then having the precision of large numbers and floating point is kind of useful, wouldn't you agree? When done, the weights can be scrunched smaller until the point is reached where performance is lost. That's the point that would freeze the base value of a pawn. Not too difficult for you, hopefully.
Parent - - By bob (Bronze) [us] Date 2011-10-01 17:25
This WAS in a final release, you understand?

You can imagine all you want.  I prefer Occam's razor.
Parent - - By Trotsky (****) [fr] Date 2011-10-01 18:40
Final = Vas decision, not yours. Release does not equal final. Version Crafty 23.45x = final?
Parent - By bob (Bronze) [us] Date 2011-10-02 04:03
So more semantic juggling?   Normally one uses the term alpha release, beta release, final release.    Or "test releases followed by a final release."

Every version I release I consider a "final release of that version" where we might have a hundred internal sub-versions before we release the final version and then move on to the next one...
Parent - By michiguel (**) Date 2011-10-01 17:53

> So "millipawns" is not enough resolution?  Units of 1/1000th of a pawn is not accurate enough, but units of 1/3200th of a pawn are "just right?"  Then why does he then divide everything by 32 after computing that big number?


No, depending what fitting technique you use, it won't be enough.

Miguel
Parent - - By Trotsky (****) [fr] Date 2011-09-30 19:06
Why don't you pick a small section of code you believe was falsely inserted, and maybe someone could show how that small piece of code can be obtained from the Rybka binary?

Done already several days ago. Ed found the Rybka executable section and posted it. I've posted an unbiased reverse engineered source from it. And shown the section of source that was inserted into the Rybka source by cut and paste from Fruit (the two allegedly constant integers).
Up Topic Rybka Support & Discussion / Rybka Discussion / With permission of Cock de Gorter (locked)
1 2 3 4 5 6 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill