Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Milos
Posts: 3389
Joined: Wed Nov 25, 2009 12:47 am

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by Milos » Thu May 12, 2011 1:48 am

bob wrote:Since you keep jumping in, you can't use ignorance as an excuse for making these kinds of mistakes. You do know the difference between "variable names" and "language". In any language, the variable name "pawn_score_1" would be considered odd because it is a long name with no implied semantic as to what it represents. This has been discussed at length. Vas commented on this very issue a couple of years back. There are lots of examples in the code.
There is no pawn_score_1 in Ippo code, you just made that up, probably intentionally citing something wrongly so that it can't be checked in the code.
What is missing in the code are names for the constants. But this is for the obvious preprocessing reason. But again this has absolutely nothing to do with "unreasonable variable names".
So, I am still waiting for you to show some of the verifiable (and not invented by you) "unreasonable variable names".
IP* was _not_ 50 elo stronger than Rybka. In fact, it crashed often enough that it was weaker. As the bugs were fixed, it gained. But it had more bugs than Carter has little pills. I quickly gave up trying to use it on the cluster because it was crashing and losing enough games on time that it skewed the results... and left hundreds of core files lying around on top of that...
Ippo was (and still is) 50 Elo stronger than Rybka 3. I am very well aware of all the code changes from original Ippo version all the way to early Ivanhoe versions. As a matter of fact I know the Ippo code way better than you and probably 90% of the programmers on this forum.
The number of show-stopper bugs in Ippo was really small. Less than 5, to be precise. Having such a strong code with so few show-stopper bugs is simply impossible by only decompilation.
However, you are as always free to believe what you want even though you have no support at all in facts.

User avatar
slobo
Posts: 2331
Joined: Mon Apr 09, 2007 3:36 pm

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by slobo » Thu May 12, 2011 2:37 am

bob wrote:
kranium wrote:
please see plot summary - "The Wizard of Oz".
Please seek medical/psychiatric help. your support of cloning/copying/etc is _really_ unbecoming...
All those who´ve been supporting the 2003 Iraq invasion need medical/psychiatric help, for sure.

By the way, Bob, do you think it was a correct decison to execute an unarmed terrorist instead of putting him on trial?
"Well, I´m just a soul whose intentions are good,
Oh Lord, please don´t let me be misunderstood."

F. Bluemers
Posts: 860
Joined: Thu Mar 09, 2006 10:21 pm
Location: Nederland
Contact:

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by F. Bluemers » Thu May 12, 2011 2:37 am

Milos wrote:
bob wrote:Since you keep jumping in, you can't use ignorance as an excuse for making these kinds of mistakes. You do know the difference between "variable names" and "language". In any language, the variable name "pawn_score_1" would be considered odd because it is a long name with no implied semantic as to what it represents. This has been discussed at length. Vas commented on this very issue a couple of years back. There are lots of examples in the code.
There is no pawn_score_1 in Ippo code, you just made that up, probably intentionally citing something wrongly so that it can't be checked in the code.
What is missing in the code are names for the constants. But this is for the obvious preprocessing reason. But again this has absolutely nothing to do with "unreasonable variable names".
So, I am still waiting for you to show some of the verifiable (and not invented by you) "unreasonable variable names".
IP* was _not_ 50 elo stronger than Rybka. In fact, it crashed often enough that it was weaker. As the bugs were fixed, it gained. But it had more bugs than Carter has little pills. I quickly gave up trying to use it on the cluster because it was crashing and losing enough games on time that it skewed the results... and left hundreds of core files lying around on top of that...
Ippo was (and still is) 50 Elo stronger than Rybka 3. I am very well aware of all the code changes from original Ippo version all the way to early Ivanhoe versions. As a matter of fact I know the Ippo code way better than you and probably 90% of the programmers on this forum.
The number of show-stopper bugs in Ippo was really small. Less than 5, to be precise. Having such a strong code with so few show-stopper bugs is simply impossible by only decompilation.
However, you are as always free to believe what you want even though you have no support at all in facts.
Can't see pawn_score_1 either,but that hardly matters:

Code: Select all

typedef struct
{
  UINT64 HESH, HESHpesh;
  UINT32 MAT, STATIC, _7;
  UINT8 rok, vsp, np, vza;
  UINT64 belATAKA, cheATAKA, belKODrent, cheKODrent, _9, _8;
  SINT32 ots, poz;
  UINT16 _5, _6, oob1, oob2, dv;
  UINT8 _0, _3, _4, len, sohFL, FLAG;
  UINT64 belKORshah, cheKORshah, _1;
}
vidDINAM;
I guess the "programmer" ran out of ideas for structure_names
:lol:

Tom Barrister
Posts: 227
Joined: Tue Oct 05, 2010 3:29 pm

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by Tom Barrister » Thu May 12, 2011 2:55 am

So this thread has followed the same path of all of the others.

As soon as facts come out, the people on the wrong side of the facts put spin after spin on things to divert the issue.

There's no point in trotting out all of the reasons that spin doctors (i.e. trolls who can use big words) are useless for anything except to stir up the manure.
This production is being brought to you by Rybka: "The engine made from scratch.™"

Milos
Posts: 3389
Joined: Wed Nov 25, 2009 12:47 am

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by Milos » Thu May 12, 2011 2:57 am

F. Bluemers wrote:Can't see pawn_score_1 either,but that hardly matters:

Code: Select all

typedef struct
{
  UINT64 HESH, HESHpesh;
  UINT32 MAT, STATIC, _7;
  UINT8 rok, vsp, np, vza;
  UINT64 belATAKA, cheATAKA, belKODrent, cheKODrent, _9, _8;
  SINT32 ots, poz;
  UINT16 _5, _6, oob1, oob2, dv;
  UINT8 _0, _3, _4, len, sohFL, FLAG;
  UINT64 belKORshah, cheKORshah, _1;
}
vidDINAM;
I guess the "programmer" ran out of ideas for structure_names
:lol:
You surely do not understand the code, otherwise you would not put this example which only illustrates your ignorance.
Hint, try finding out where those structure members (_1, _2, ...) are used in the rest of the code. Then you maybe realize what's their function and come up with some ingenious name for them. Until then, maybe let someone who actually knows something about Ippo to answer...

bob
Posts: 20687
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by bob » Thu May 12, 2011 3:03 am

Milos wrote:
bob wrote:Since you keep jumping in, you can't use ignorance as an excuse for making these kinds of mistakes. You do know the difference between "variable names" and "language". In any language, the variable name "pawn_score_1" would be considered odd because it is a long name with no implied semantic as to what it represents. This has been discussed at length. Vas commented on this very issue a couple of years back. There are lots of examples in the code.
There is no pawn_score_1 in Ippo code, you just made that up, probably intentionally citing something wrongly so that it can't be checked in the code.
What is missing in the code are names for the constants. But this is for the obvious preprocessing reason. But again this has absolutely nothing to do with "unreasonable variable names".
So, I am still waiting for you to show some of the verifiable (and not invented by you) "unreasonable variable names".
I thought most would "get the idea" from "pawn_score_1". But since you are a bit thick, this from the sources of ippolit, file name IPP_ENG.c

how about "murderer_1, murderer_2,

In other places, nonsense like this:

score -= (((0) << 16) + (3));

or this:

white_king_distance = (((((white_king_square > b) ? 3 : 6) * (((((b) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b) >> 3) - ((white_king_square) >> 3)) : -(((b) >> 3) - ((white_king_square) >> 3)))) >= (6 * (((((b) & 7) - ((white_king_square) & 7)) >= 0) ? (((b) & 7) - ((white_king_square) & 7)) : -(((b) & 7) - ((white_king_square) & 7))))) ? (((white_king_square > b) ? 3 : 6) * (((((b) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b) >> 3) - ((white_king_square) >> 3)) : -(((b) >> 3) - ((white_king_square) >> 3)))) : (6 * (((((b) & 7) - ((white_king_square) & 7)) >= 0) ? (((b) & 7) - ((white_king_square) & 7)) : -(((b) & 7) - ((white_king_square) & 7)))));

which is what happens when several consecutive assignments get collapsed by the optimizer to eliminate the unneeded temp variables we often use to make the code readable.

or this:

score += ((((((black_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((black_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((black_king_square) >> 3)) : -(((b + 8) >> 3) - ((black_king_square) >> 3)))) >= (6 * (((((b + 8) & 7) - ((black_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((black_king_square) & 7)) : -(((b + 8) & 7) - ((black_king_square) & 7))))) ? (((black_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((black_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((black_king_square) >> 3)) : -(((b + 8) >> 3) - ((black_king_square) >> 3)))) : (6 * (((((b + 8) & 7) - ((black_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((black_king_square) & 7)) : -(((b + 8) & 7) - ((black_king_square) & 7))))) * opponent_king_pawn_distancing[((b) >> 3)]);
score -= ((((((white_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((white_king_square) >> 3)) : -(((b + 8) >> 3) - ((white_king_square) >> 3)))) >= (6 * (((((b + 8) & 7) - ((white_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((white_king_square) & 7)) : -(((b + 8) & 7) - ((white_king_square) & 7))))) ? (((white_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((white_king_square) >> 3)) : -(((b + 8) >> 3) - ((white_king_square) >> 3)))) : (6 * (((((b + 8) & 7) - ((white_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((white_king_square) & 7)) : -(((b + 8) & 7) - ((white_king_square) & 7))))) * myself_king_pawn_distancing[((b) >> 3)]);

Does that look like something _ANY_ human would write? Almost looks like lisp from a distance...

In this version, I do not see the pawn_score_1, _2 and such that Vas pointed out. Perhaps that was in Robo rather than the original IP source with names translated to English. But there is a lot of this kind of stuff:

score += (((6) << 16) + (10));

Where 6 and 10 are middlegame/endgame score values. Most don't put the numeric constants in evaluation code, most use either #defines, or something similar, or else use regular variables so that the values can be changed by the user if he chooses.

The overall structure of this program bears resemblance to Crafty, in that everywhere in my code you see local variables accessed as tree->variable. In ip* (did it even have SMP to start with?) it has tower_dynamic->variable. Since Rybka started as Crafty, it is likely this overall structure was kept into Rybka 1 and 2. In fact, there are quite a few Craftyisms that lend more credibility to IP* coming from Rybka...

One thing is for sure, a programmer that writes a non-threaded program is not going to pass around a pointer to the local data, when it can be referenced as global data more efficiently. Crafty through version 14.x certainly did that, and the tree-> stuff was added in 15.0 to make the SMP code work.

Anyone that thinks this piece of trash is an original program written by a human has their head so far up their a$$ all they can see are esophagus and tonsils.

Of course, don't let any of those small facts interfere with your nonsensical discussion. Robo is a derivative. It isn't a perfect clone, because the SMP code from Rybka/Crafty was not copied. But the basic engine tells the story, if one is willing to read...

IP* was _not_ 50 elo stronger than Rybka. In fact, it crashed often enough that it was weaker. As the bugs were fixed, it gained. But it had more bugs than Carter has little pills. I quickly gave up trying to use it on the cluster because it was crashing and losing enough games on time that it skewed the results... and left hundreds of core files lying around on top of that...
Ippo was (and still is) 50 Elo stronger than Rybka 3. I am very well aware of all the code changes from original Ippo version all the way to early Ivanhoe versions. As a matter of fact I know the Ippo code way better than you and probably 90% of the programmers on this forum.
I doubt you know _anything_ better than 90% of the programmers on this forum. Certainly not ip*. Or you would know it for what it is.
The number of show-stopper bugs in Ippo was really small. Less than 5, to be precise. Having such a strong code with so few show-stopper bugs is simply impossible by only decompilation.
Ah, the voice of experience _again_??? First there were more than 5. Second, if you use a decompiler, the number of bugs would be expected to be _zero_. If you decompile, then try to edit the source to make it look _somewhat_ natural looking, then you introduce bugs... But the code is not naturally written, and nobody on the planet that has worked with assembly language, and compilers, will tell you differently...
However, you are as always free to believe what you want even though you have no support at all in facts.
I actually have far more facts supporting my opinion than you have supporting yours. you have none, in fact. Or at least you have offered none to date...

bob
Posts: 20687
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by bob » Thu May 12, 2011 3:06 am

slobo wrote:
bob wrote:
kranium wrote:
please see plot summary - "The Wizard of Oz".
Please seek medical/psychiatric help. your support of cloning/copying/etc is _really_ unbecoming...
All those who´ve been supporting the 2003 Iraq invasion need medical/psychiatric help, for sure.

By the way, Bob, do you think it was a correct decison to execute an unarmed terrorist instead of putting him on trial?
Not much point in debating, is it. You can't "unpull" the trigger.

However, since you asked, I think it was by far the best solution. Otherwise we put up with years of demonstrations, threats, kidnappings (you give us Osama back, you get xyz back) and such nonsense. This way he will be news for two weeks then forgotten.

F. Bluemers
Posts: 860
Joined: Thu Mar 09, 2006 10:21 pm
Location: Nederland
Contact:

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by F. Bluemers » Thu May 12, 2011 3:18 am

Milos wrote:
F. Bluemers wrote:Can't see pawn_score_1 either,but that hardly matters:

Code: Select all

typedef struct
&#123;
  UINT64 HESH, HESHpesh;
  UINT32 MAT, STATIC, _7;
  UINT8 rok, vsp, np, vza;
  UINT64 belATAKA, cheATAKA, belKODrent, cheKODrent, _9, _8;
  SINT32 ots, poz;
  UINT16 _5, _6, oob1, oob2, dv;
  UINT8 _0, _3, _4, len, sohFL, FLAG;
  UINT64 belKORshah, cheKORshah, _1;
&#125;
vidDINAM;
I guess the "programmer" ran out of ideas for structure_names
:lol:
You surely do not understand the code, otherwise you would not put this example which only illustrates your ignorance.
Hint, try finding out where those structure members (_1, _2, ...) are used in the rest of the code. Then you maybe realize what's their function and come up with some ingenious name for them. Until then, maybe let someone who actually knows something about Ippo to answer...
Ah,yes the Ipp "Programmer" didn't understand his "own" code.
Makes sense
:lol:

User avatar
michiguel
Posts: 6400
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by michiguel » Thu May 12, 2011 3:26 am

bob wrote:
Milos wrote:
bob wrote:Since you keep jumping in, you can't use ignorance as an excuse for making these kinds of mistakes. You do know the difference between "variable names" and "language". In any language, the variable name "pawn_score_1" would be considered odd because it is a long name with no implied semantic as to what it represents. This has been discussed at length. Vas commented on this very issue a couple of years back. There are lots of examples in the code.
There is no pawn_score_1 in Ippo code, you just made that up, probably intentionally citing something wrongly so that it can't be checked in the code.
What is missing in the code are names for the constants. But this is for the obvious preprocessing reason. But again this has absolutely nothing to do with "unreasonable variable names".
So, I am still waiting for you to show some of the verifiable (and not invented by you) "unreasonable variable names".
I thought most would "get the idea" from "pawn_score_1". But since you are a bit thick, this from the sources of ippolit, file name IPP_ENG.c

how about "murderer_1, murderer_2,

In other places, nonsense like this:

score -= (((0) << 16) + (3));

or this:

white_king_distance = (((((white_king_square > b) ? 3 : 6) * (((((b) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b) >> 3) - ((white_king_square) >> 3)) : -(((b) >> 3) - ((white_king_square) >> 3)))) >= (6 * (((((b) & 7) - ((white_king_square) & 7)) >= 0) ? (((b) & 7) - ((white_king_square) & 7)) : -(((b) & 7) - ((white_king_square) & 7))))) ? (((white_king_square > b) ? 3 : 6) * (((((b) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b) >> 3) - ((white_king_square) >> 3)) : -(((b) >> 3) - ((white_king_square) >> 3)))) : (6 * (((((b) & 7) - ((white_king_square) & 7)) >= 0) ? (((b) & 7) - ((white_king_square) & 7)) : -(((b) & 7) - ((white_king_square) & 7)))));

which is what happens when several consecutive assignments get collapsed by the optimizer to eliminate the unneeded temp variables we often use to make the code readable.

or this:

score += ((((((black_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((black_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((black_king_square) >> 3)) : -(((b + 8) >> 3) - ((black_king_square) >> 3)))) >= (6 * (((((b + 8) & 7) - ((black_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((black_king_square) & 7)) : -(((b + 8) & 7) - ((black_king_square) & 7))))) ? (((black_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((black_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((black_king_square) >> 3)) : -(((b + 8) >> 3) - ((black_king_square) >> 3)))) : (6 * (((((b + 8) & 7) - ((black_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((black_king_square) & 7)) : -(((b + 8) & 7) - ((black_king_square) & 7))))) * opponent_king_pawn_distancing[((b) >> 3)]);
score -= ((((((white_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((white_king_square) >> 3)) : -(((b + 8) >> 3) - ((white_king_square) >> 3)))) >= (6 * (((((b + 8) & 7) - ((white_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((white_king_square) & 7)) : -(((b + 8) & 7) - ((white_king_square) & 7))))) ? (((white_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((white_king_square) >> 3)) : -(((b + 8) >> 3) - ((white_king_square) >> 3)))) : (6 * (((((b + 8) & 7) - ((white_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((white_king_square) & 7)) : -(((b + 8) & 7) - ((white_king_square) & 7))))) * myself_king_pawn_distancing[((b) >> 3)]);

Does that look like something _ANY_ human would write? Almost looks like lisp from a distance...
These were the expansion of nested macros, as we discussed with Zach before (a non-recommended coding practice, BTW).

Miguel

In this version, I do not see the pawn_score_1, _2 and such that Vas pointed out. Perhaps that was in Robo rather than the original IP source with names translated to English. But there is a lot of this kind of stuff:

score += (((6) << 16) + (10));

Where 6 and 10 are middlegame/endgame score values. Most don't put the numeric constants in evaluation code, most use either #defines, or something similar, or else use regular variables so that the values can be changed by the user if he chooses.

The overall structure of this program bears resemblance to Crafty, in that everywhere in my code you see local variables accessed as tree->variable. In ip* (did it even have SMP to start with?) it has tower_dynamic->variable. Since Rybka started as Crafty, it is likely this overall structure was kept into Rybka 1 and 2. In fact, there are quite a few Craftyisms that lend more credibility to IP* coming from Rybka...

One thing is for sure, a programmer that writes a non-threaded program is not going to pass around a pointer to the local data, when it can be referenced as global data more efficiently. Crafty through version 14.x certainly did that, and the tree-> stuff was added in 15.0 to make the SMP code work.

Anyone that thinks this piece of trash is an original program written by a human has their head so far up their a$$ all they can see are esophagus and tonsils.

Of course, don't let any of those small facts interfere with your nonsensical discussion. Robo is a derivative. It isn't a perfect clone, because the SMP code from Rybka/Crafty was not copied. But the basic engine tells the story, if one is willing to read...

IP* was _not_ 50 elo stronger than Rybka. In fact, it crashed often enough that it was weaker. As the bugs were fixed, it gained. But it had more bugs than Carter has little pills. I quickly gave up trying to use it on the cluster because it was crashing and losing enough games on time that it skewed the results... and left hundreds of core files lying around on top of that...
Ippo was (and still is) 50 Elo stronger than Rybka 3. I am very well aware of all the code changes from original Ippo version all the way to early Ivanhoe versions. As a matter of fact I know the Ippo code way better than you and probably 90% of the programmers on this forum.
I doubt you know _anything_ better than 90% of the programmers on this forum. Certainly not ip*. Or you would know it for what it is.
The number of show-stopper bugs in Ippo was really small. Less than 5, to be precise. Having such a strong code with so few show-stopper bugs is simply impossible by only decompilation.
Ah, the voice of experience _again_??? First there were more than 5. Second, if you use a decompiler, the number of bugs would be expected to be _zero_. If you decompile, then try to edit the source to make it look _somewhat_ natural looking, then you introduce bugs... But the code is not naturally written, and nobody on the planet that has worked with assembly language, and compilers, will tell you differently...
However, you are as always free to believe what you want even though you have no support at all in facts.
I actually have far more facts supporting my opinion than you have supporting yours. you have none, in fact. Or at least you have offered none to date...

Milos
Posts: 3389
Joined: Wed Nov 25, 2009 12:47 am

Re: Houdini, Fire, IvanHoe, (and Rybka?) are 'clones'...?

Post by Milos » Thu May 12, 2011 3:39 am

bob wrote:I thought most would "get the idea" from "pawn_score_1".
The only idea that they can get that you are not able to express yourself in a precise and concise manner (or in the worst case that you are lying).
how about "murderer_1, murderer_2,
You call this KILLER_MOVE_1, KILLER_MOVE_2 in Crafty, you really think your name is more reasonable when translated to Russian?
In other places, nonsense like this:

score -= (((0) << 16) + (3));

or this:

white_king_distance = (((((white_king_square > b) ? 3 : 6) * (((((b) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b) >> 3) - ((white_king_square) >> 3)) : -(((b) >> 3) - ((white_king_square) >> 3)))) >= (6 * (((((b) & 7) - ((white_king_square) & 7)) >= 0) ? (((b) & 7) - ((white_king_square) & 7)) : -(((b) & 7) - ((white_king_square) & 7))))) ? (((white_king_square > b) ? 3 : 6) * (((((b) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b) >> 3) - ((white_king_square) >> 3)) : -(((b) >> 3) - ((white_king_square) >> 3)))) : (6 * (((((b) & 7) - ((white_king_square) & 7)) >= 0) ? (((b) & 7) - ((white_king_square) & 7)) : -(((b) & 7) - ((white_king_square) & 7)))));

which is what happens when several consecutive assignments get collapsed by the optimizer to eliminate the unneeded temp variables we often use to make the code readable.

or this:

score += ((((((black_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((black_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((black_king_square) >> 3)) : -(((b + 8) >> 3) - ((black_king_square) >> 3)))) >= (6 * (((((b + 8) & 7) - ((black_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((black_king_square) & 7)) : -(((b + 8) & 7) - ((black_king_square) & 7))))) ? (((black_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((black_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((black_king_square) >> 3)) : -(((b + 8) >> 3) - ((black_king_square) >> 3)))) : (6 * (((((b + 8) & 7) - ((black_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((black_king_square) & 7)) : -(((b + 8) & 7) - ((black_king_square) & 7))))) * opponent_king_pawn_distancing[((b) >> 3)]);
score -= ((((((white_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((white_king_square) >> 3)) : -(((b + 8) >> 3) - ((white_king_square) >> 3)))) >= (6 * (((((b + 8) & 7) - ((white_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((white_king_square) & 7)) : -(((b + 8) & 7) - ((white_king_square) & 7))))) ? (((white_king_square > b + 8) ? 3 : 6) * (((((b + 8) >> 3) - ((white_king_square) >> 3)) >= 0) ? (((b + 8) >> 3) - ((white_king_square) >> 3)) : -(((b + 8) >> 3) - ((white_king_square) >> 3)))) : (6 * (((((b + 8) & 7) - ((white_king_square) & 7)) >= 0) ? (((b + 8) & 7) - ((white_king_square) & 7)) : -(((b + 8) & 7) - ((white_king_square) & 7))))) * myself_king_pawn_distancing[((b) >> 3)]);

Does that look like something _ANY_ human would write? Almost looks like lisp from a distance...
Again just and exclusively bunch of preprocessor expansions of macros which proves nothing except that the code is obfuscated. Not a single example of "unreasonable variable names".
So again you didn't provide any facts.
The overall structure of this program bears resemblance to Crafty, in that everywhere in my code you see local variables accessed as tree->variable. In ip* (did it even have SMP to start with?) it has tower_dynamic->variable. Since Rybka started as Crafty, it is likely this overall structure was kept into Rybka 1 and 2. In fact, there are quite a few Craftyisms that lend more credibility to IP* coming from Rybka...
Even more BS. Everything is Crafty. You ego is really larger than a Moon. If you even bothered to read Mark's paper you would not write so much crap.
One thing is for sure, a programmer that writes a non-threaded program is not going to pass around a pointer to the local data, when it can be referenced as global data more efficiently. Crafty through version 14.x certainly did that, and the tree-> stuff was added in 15.0 to make the SMP code work.
Passing out a pointer gives 3-5% slower code in case of Robbo. There was an extensive discussion about that multiple times in this forum and different ppl measured this. Don't believing it, doesn't make it less true.
Robo is a derivative. It isn't a perfect clone, because the SMP code from Rybka/Crafty was not copied. But the basic engine tells the story, if one is willing to read...
The first version of Robbo is functionally identical to Ippo (so technically it is a real clone). Only variable names are translated, code is divided into files and macros are not expanded as in Ippo. Again you have wrong facts...

Ah, the voice of experience _again_??? First there were more than 5.
No there were not. And it's simple to prove me wrong, just list more than 5 show-stopper bugs (that would make it crash in your tests) in Ippo.
I'm waiting...
I actually have far more facts supporting my opinion than you have supporting yours. you have none, in fact. Or at least you have offered none to date...
All your "facts" are wrong or refuted. I'm still waiting for a single correct one. And seams to me I'll wait forever...

Post Reply