Similarities between Ippolit and Rybka3:
1. Separate basic functions for white and black.
2. Check for stop search - only in white_make_move.
3. Similar structure and calculation of material table (maybe weights are different - I don't compared).
4. Separate index for white-field and black-field bishops in material table.
5. The principe of eval calculation - one weight contains two number for "opening" and "endgame".
6. Similar recalculation of history.
And so on...
Differences - agreed with Alexander Schmidt. I can add:
1. Different structure of transposition table - close to Fruit.
2. Ippolit faster than Rybka 3 on 85% (in real NPS).
Osipov Jury wrote:Similarities between Ippolit and Rybka3:
1. Separate basic functions for white and black.
2. Check for stop search - only in white_make_move.
3. Similar structure and calculation of material table (maybe weights are different - I don't compared).
4. Separate index for white-field and black-field bishops in material table.
5. The principe of eval calculation - one weight contains two number for "opening" and "endgame".
6. Similar recalculation of history.
And so on...
Differences - agreed with Alexander Schmidt. I can add:
1. Different structure of transposition table - close to Fruit.
2. Ippolit faster than Rybka 3 on 85% (in real NPS).
Name a fast searcher other than Rybka and Ippolit.
Osipov Jury wrote:Similarities between Ippolit and Rybka3:
1. Separate basic functions for white and black.
2. Check for stop search - only in white_make_move.
3. Similar structure and calculation of material table (maybe weights are different - I don't compared).
4. Separate index for white-field and black-field bishops in material table.
5. The principe of eval calculation - one weight contains two number for "opening" and "endgame".
6. Similar recalculation of history.
And so on...
Differences - agreed with Alexander Schmidt. I can add:
1. Different structure of transposition table - close to Fruit.
2. Ippolit faster than Rybka 3 on 85% (in real NPS).
So, for me Ippolit is not a clone. It is a three had monster, composed by
Rybka, Fruit and Other contributions, including original ones.
I think we are facing something really new in Computer Chess World, something that has no definition yet.
"Well, I´m just a soul whose intentions are good,
Oh Lord, please don´t let me be misunderstood."
Osipov Jury wrote:Similarities between Ippolit and Rybka3:
1. Separate basic functions for white and black.
2. Check for stop search - only in white_make_move.
3. Similar structure and calculation of material table (maybe weights are different - I don't compared).
4. Separate index for white-field and black-field bishops in material table.
5. The principe of eval calculation - one weight contains two number for "opening" and "endgame".
6. Similar recalculation of history.
And so on...
Differences - agreed with Alexander Schmidt. I can add:
1. Different structure of transposition table - close to Fruit.
2. Ippolit faster than Rybka 3 on 85% (in real NPS).
So, for me Ippolit is not a clone. It is a three had monster, composed by
Rybka, Fruit and Other contributions, including original ones.
I think we are facing something really new in Computer Chess World, something that has no definition yet.
It's a Frankenstein Clone. I not the first to say it, but it describes it pretty well.
Christopher Conkie wrote:
To compare what specifically Jury? The code has stayed the same on the site since we found it. Any alterations that we made to make it work or add certain features, were done with the 0080a code.
This is very strange.
The first version had a number 0080a.
In the first version made a lot of changes compared to Rybka 3.
For six months nothing added.
Yes, correct. It is very strange. The only things that were done were an attempt at translation to English and then Italian (0.084)
It is the months before 0.080a that really matter. It would be very interesting to know what 0.001 looked like.
It still does not look written by a human, it looks like a human has amended something created by software..
What do you in your experience of these things think of the code Jury?
Your point of view would be valued on this if you can say something about what you personally see.
Christopher
When I first took a look, my first opinion was "this is something that was produced by doing the inverse of "compile, optimize, write executable." That is, "take executable, decompile, then try to edit the resulting mess to make it marginally readable." However, when one really optimizes the executable instruction stream, de-compiling becomes a horrendous task, since the instructions for a single line of C get intermingled with instructions from other lines of C to prevent pipeline stalls and memory waits when possible. Going from C to optimized asm is pretty straightforward. But going backward is a one-to-many mapping form of translation that produces code that is very hard to read. Without good variable names, it is even harder.
We found the page with the source for the first time on 6th May 2009.
Then we compiled it and showed it to various programmers asking them what they thought of it.
Christopher
and ... what did the various programmers thought of it ...?
Bye
Ingo
Very strong. Very buggy. Even with the crashes it was stronger than any source program I had previously tested (crashes counted as a loss). This in itself was pretty remarkable. I chose to not use it because I didn't have time to try to debug pigeon-C and the non-deterministic crashes made the results somewhat unreliable.