Vas about IPP engine

[Gian-Carlo Pascutto]

the sources as they are presented seems to me a preprocessed file more then anything else.

Aka, the actual input to the compiler instead of what the original programmer has written

This is logical, because when you reverse engineer the binary, you are looking at the compiler output, not the output before the preprocessor.

[Alexander Schmidt]

• No tables in Ippolit
  Different Movegen
  Completely different UCI handling
  Different evaluation
  Different search
  Different Maximum Depth

One addition:

• Different time management

One more:

Different endgame knowledge.

Show me something similar except the strength

I am still waiting...

And I am still waiting. But hurry up, quoting becomes difficult

[Osipov Jury]

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

[Christopher Conkie]

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.

That would be my next question.



Christopher

PS I do believe we are getting somewhere.

[Alexander Schmidt]

Thank you

I am no programmer, so I do not know how common this similaries are. But I am looking forward to see further informations

[slobo]

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.

[Terry McCracken]

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.

[Osipov Jury]

It's a Frankenstein Clone. I not the first to say it, but it describes it pretty well.

This is not "Frankenstein Clone". This is promotion action for Rybka 4.

[bob]

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.

[bob]

Hello

...

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.