Chris Whittington wrote:My analysis is absolutely correct. I can't help it if you are so utterly confused. This is not an insult, this is the truth.hyatt wrote:Chris Whittington wrote:hahahahaha!! can you read ASM? find it yourself and work it out. Ridiculous question.There's a Rybka bonus (in the discussed code) for rook behind blocked enemy pawn chain, a common pattern. Fruit "parallel" code (your parallel) simply doesn't have this bonus. Ask Mark to explain it to you, at least he has seen it already.hyatt wrote:Chris Whittington wrote: You insist on calling this situation half open/open file, but it isn't is it? The chess definition half open or open simply does not apply to a own pawn ALSO on file. Why do you insist on the false definition? Because you are unconsciously biased to force Rybka code into parallels with Fruit structures, even when that steucture does NOT exist in Rybka.
OK, your example. you know perfectly well that chess board pattern recognition as implemented by programmers are general purpose. Sure you can disrupt the tendency for the algorithm to put its rook on a specific file behind the enemy pawn chain by inserting a friendly pawn on a very advanced position on that same file. But what you are really trying to disrupt with this quite fanciful positioning (remember, we are discussing heavily blocked pawn frontages, with an open file penetration) is the argument that Rybka has a creative and original algorithm/pattern recognition, which is strongly superior. I''m shocked, Mark, that you stoop to this.
Why don't you show the exact place where Rybka gives a bonus when its rook is BEHIND enemy pawns.
The only code I can find says this:
(1) if there is no friendly pawn in front of the rook, give a half-open file bonus.
(2) If there is no enemy pawn in front of the rook, give an open file bonus and remove the half-open file bonus.
If you want to say that "gives a bonus for being behind a pawn" that looks like pretty fanciful dreaming. Anyone can, with a little bit of reasoning, determine EXACTLY what his intent was. Because the concept of half-open/open is pretty obvious, and his intent was to slightly modify half-open to include the case where the friendly pawn is behind the rook. I ran this exact change a few years ago and it was a ZERO elo change, although the Elo did drop a couple of points but that was within the error bar and I did not feel like testing for +/- 1 accuracy. Guarantee you that his intent was NOT a rook behind enemy pawns there, that is serendipity and maybe not such good serendipity either.
I'm reading your second paragraph, excuse me whiel I pick myslef up off the floor. First mind-reading doesn't cut it. Second, you are applying Morton's fork now that you maybe finally understand the code. For you, it was the same (it wasn't of course) therefore he copied. Now, you realise it is very different, but, of course, now he copied and modified it. hahahahahahaha!!! Vas ls lost in all variations according to the brillient Hyatt logic. Same = copied. Different = copied and modified. So stupid, you expect anyone to believe your nonsense?
There is no code that even RECOGNIZES a "blocked pawn chain." Sorry. More made-up nonsense. And it is EASY to understand his intent. The code at hand is NOT intended to recognize a rook BEHIND enemy pawns. If it were, WHY would it care whether it had an own-pawn on the file at all or not? It does care, because it was designed to work EXACTLY as explained. Rook on half-open or open file. Vas changed one minor point, namely to call a file half-open if there are no friendly pawns in front of it. There are LOTS of things wrong with this idea. You have a pawn at e7, enemy pawn at e6, no other pawns on board. Is your rook useful on the e-file or not? Vas doesn't think so. It is simply obvious what his intent was, and it had nothing to do with your fertile imagination...
As far as this code, I have ALWAYS understood it. It is not exactly rocket science... Fruit has EXACTLY the same pair of bonuses, only it requires NO friendly pawns on the file for it to be considered half-open, while Rybka requires no friendly pawns in front of the rook. In 99% of the cases they are exactly the same, since for most of the game the rooks are generally found on the first or second rank.
And you talk about mind-reading in one sentence and come up with that "rook behind a blocked enemy pawn chain with a straight face?
Please show me THAT code.
If you fail to analyse, or even see, at an incredibly simple level what Rybka is actually doing with this code, then any and all conclusions you come to will be nonsense.
Your points 1 and 2 above do NOT describe the action of the Rybka code. I am not going to discuss more complex functionality arising, with you, when you are wrong at such a simple level. What has happened to you, man? You used to at least read code accurately, in the past.
So it seems "imagination" is the correct term. There is no code that recognizes your "blocked pawn chain" anywhere in the code. Which I already knew before looking. My points 1 and 2 describe EXACTLY what the code does. EXACTLY. C code is, by definition, non-ambiguous. Be pretty useless otherwise.