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...
