Some thoughts on QS

[Don]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

On my question, how do you do your selective search he answered, by just throwing away all the bad moves.

As Don said, I think there are probably gems in CG that would benefit the current crop of engines. Richard basically had to figure all of this stuff out for himself. He also had to grapple with limited hardware. It's quite amazing really.

Absolutely. Someone should ask if he still has the Ossi papers and if he is willing to scan them.

[diep]

Oh really?
How did it find all those tactics 12 ply deeper always?

I remember the +12 ply settings, for its days it was impressive tactical.
Based upon which heuristics did it search deeper?

Vincent,

It's not hard for me to believe. If I were using see() for quies, I would probably be a lot more creative about extending moves on the last ply - particularly captures and checks to help cover things SEE doesn't. In fact with some creativity and by looking at the score and the alpha/beta window and some knowledge of tactical motifs you might very well be able to judiciously extend the last ply, perhaps more than once to get most of the power back that you lose from SEE.

It's all semantics anyway, but CG has a highly selective extended search - and I'll bet that was where most of the magic was.

We both agree upon that using a full blown Qsearch is way better Ed - no discussion. Also it seems you're trying checks (giving check) moves in qsearch, right?

I do that in Diep as well - not doing that would considerable weaken Diep - but remember, Diep isn't getting 30 plies like the ivanhoes and the stockfishes get.

So picking up that tactics if you get outsearched might be very important and crucial.

For those engines getting that 30 plies - considering they razor and do futility - maybe it's less relevant - in the end their evaluation function is SIMPLE.

It's totally PSQ based positional. Remove PSQ - you remove their elo.

Well this is exactly what i was doing with Diep on its last plies as well in 90s. In fact in some cases i do it today even. The problem is that other than check giving sequences, it's all rather expensive and that it adds at most 1 ply of tactics and if you're lucky 2.

That's why i limited it in most cases at the time to extending it 1 ply. Only when you've done this you'll realize how expensive it is nodewise.

But maybe that's why Genius had such a bad branching factor... ...and why it started losing so bigtime against the nullmove engines.

You need to give Frans Morsch the victory for that. He promoted recursive nullmove in a manner it never left.

I have not seen any form of search from the 80s/90s that positional is on par with recursive nullmove. All these tricks just find tactics faster.

Even then doing a few selective moves just before qsearch, which improve your engines understanding, that's most interesting to study.

The way how Genius selected moves to try is most interesting to know.

Please note that of course also diep has incremental attacktables.

[Uri Blass]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

I think that this system is clearly wrong also in the days of Genius(Genius3 is from 1994) and the only reason that it was effective in games is that people did not know to write a good evaluation at that time.

Fritz5 and Fritz5.32 used this system and I believe that they changed it in Fritz6 and got a signficant improvement.

From the ssdf rating list:

97 Fritz 6.0 128MB K6-2 450 MHz 2612 17 -17 1751 48%
108 Fritz 5.32 128MB K6-2 450 MHz 2555 20 -20 1194 48%

From the CEGT 40/4 rating list that may be equivalent to tournament time control at the time of Genius:

666 Fritz 6 2455 13 13 1791 49.1% 2462 31.7%
729 Fritz 5.32 2425 13 13 2006 52.0% 2411 29.7%

[Don]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

I think that this system is clearly wrong also in the days of Genius(Genius3 is from 1994) and the only reason that it was effective in games is that people did not know to write a good evaluation at that time.

The approach has some real strengths but also some big weaknesses so I cannot refute what you are saying. The primary strength is that you can encode a vastly greater amount of knowledge using such a system but it's not clear to me whether that would have made up for it's weaknesses back then or not.

Fritz5 and Fritz5.32 used this system and I believe that they changed it in Fritz6 and got a signficant improvement.

I urged Frans Morsch to stop doing it and it's possible that he listened to me - or it may just be that he was going to do it sooner or later anyway. I doubt that I told him anything he didn't know though, he is a pretty smart guy.

The obvious problem of course is that when you search deep you are analyzing positions that could be totally different from the root position the tables are based on. It's my belief that such a system would be terrible for a modern program but possible quite good for a program that rarely searches deeper than 5 ply - like some of those old programs. The ELO rating curve is severe for shallow searches so a really good but slow evaluation would kill your program.

I was never very good about keeping up with what everyone else was doing, but I believe this was a very popular technique only in the early days of 8 bit computing. I'm sure there are exceptions of course but but maybe Frans was one of the last hold-outs.

Frans is an amazing engineer. He has these incredibly strong PC programs but he could also write programs for tiny and cheap embedded devices that used hardly any memory - where piece square tables would have been considered a shameful luxury. I think his PC programs shared some of the same ideas because even though they were far more sophisticated (hash tables, etc) they had the same "waste no resource" feel such as an evaluation function that was no bigger than it had to be. People were always critical of Fritz as a "dumb but fast" program but I thought it was quite impressive.

From the ssdf rating list:

97 Fritz 6.0 128MB K6-2 450 MHz 2612 17 -17 1751 48%
108 Fritz 5.32 128MB K6-2 450 MHz 2555 20 -20 1194 48%

From the CEGT 40/4 rating list that may be equivalent to tournament time control at the time of Genius:

666 Fritz 6 2455 13 13 1791 49.1% 2462 31.7%
729 Fritz 5.32 2425 13 13 2006 52.0% 2411 29.7%

[diep]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

I think that this system is clearly wrong also in the days of Genius(Genius3 is from 1994) and the only reason that it was effective in games is that people did not know to write a good evaluation at that time.

Fritz5 and Fritz5.32 used this system and I believe that they changed it in Fritz6 and got a signficant improvement.

From the ssdf rating list:

97 Fritz 6.0 128MB K6-2 450 MHz 2612 17 -17 1751 48%
108 Fritz 5.32 128MB K6-2 450 MHz 2555 20 -20 1194 48%

From the CEGT 40/4 rating list that may be equivalent to tournament time control at the time of Genius:

666 Fritz 6 2455 13 13 1791 49.1% 2462 31.7%
729 Fritz 5.32 2425 13 13 2006 52.0% 2411 29.7%

Uri, just shut up with this total idiocy you write here.

These guys got engines to work at cpu's with 128 bytes RAM and 2KB rom.
Later on they had 4 kilobyte of RAM and a 1Mhz H8 chip. That chip is a lot slower than a 1 Mhz ARM/MIPS type cpu.

Later CPU's had a 4KB RAM and 64KB ROM and a few Mhz.

You just don't have the system time nor code to get real deep.

It's true things are better now, but that's because we have more RAM and faster cpu's in the first place and we had 30 years more time.

If you are sure you are gonna get 4 ply with a todays engine and 6 plies with what they did do, then i'm not so sure any of todays engine would stand a chance. Besides that todays engines you care about forward prune last 3 plies without picking up tactics, so they would lose everything against Genius, as Genius simply would win tactical every game as todays engines are last few plies tactical 500 elo weaker than what engines back then picked up last few plies.

In the 90s i was the big promotor of course of not using preprocessor engines. Bob joined me in that. With that we were initially the only ones.

Yet that was already at very capable CPU's compared to the days that genius was dominating.

Genius dominated in the 80s.

It tactical won every game it played.

To quote Frans Morsch about those days: "Every game was decided within 25 moves, as either you dropped a piece somewhere, or your opponent blundered a piece or even queen."

That's the days when Genius dominated.

Had you lived in those days and been busy with computerchess, you would have been one of those guys posting against Bob and me in the 90s saying that only seeing tactics deeper would be interesting and that preprocessing would be more than sufficient as it is FASTER.

Furthermore you live in an illusion. The reason todays evaluation functions of the PSQ beancounters is so fast is because they use a LOOKUPTABLE for the material.

I didn't checkout sizes, but that'll be a megabyte huge or so in most cases.

You didn't have the RAM for that back in 80s.

Your entire RAM is 4 kilobyte or less. You cannot calculate even todays evaluation within sufficient clockcycles.

Everything is 8 bits.

You are so far away from reality that it's not even funny.

If you got outsearched 1 ply that was a lot. If they outsearched you 2 plies.
I remember Bob writing in RGCC that Diep's approach of improving the evaluation function and focussing completely upon evaluation, that this would never work as a slower evaluation function would mean getting outsearched ply, which would prove too much.

Basically now you defend better evaluation functions, which i'm of course favouring, yet you do that with the knowledge of today, without realizing the limitations of the 80s.

Again YOU DON'T HAVE ENOUGH RAM FOR A LOOKUP TABLE, and if you had you'd gladly use it for a hashtable. LMR can't work without hashtable, to give you one example, and would not work back then of course, as alternatives are much better then.

Nullmove was victorious only years later. We speak of mid 90s then.

Ed Schroder got number 1 on SSDF by what was it 1998 or so?
With a program doing about everything todays game tree search programmers only get forced to use in their NIGHTMARES.

At the first series of processors where better evaluation functions were possible, the world champions name is Ed Schroder. Basically he already followed the idea of a better evaluation function but more importantly was searching very selective meanwhile not missing too much tactics.

The world title of Ed not only ends domination of Genius in a clear manner, it also sings the song of how to better evaluate and it also terminates the dominance of supercomputers in open hardware contests.

[Don]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

I think that this system is clearly wrong also in the days of Genius(Genius3 is from 1994) and the only reason that it was effective in games is that people did not know to write a good evaluation at that time.

Fritz5 and Fritz5.32 used this system and I believe that they changed it in Fritz6 and got a signficant improvement.

From the ssdf rating list:

97 Fritz 6.0 128MB K6-2 450 MHz 2612 17 -17 1751 48%
108 Fritz 5.32 128MB K6-2 450 MHz 2555 20 -20 1194 48%

From the CEGT 40/4 rating list that may be equivalent to tournament time control at the time of Genius:

666 Fritz 6 2455 13 13 1791 49.1% 2462 31.7%
729 Fritz 5.32 2425 13 13 2006 52.0% 2411 29.7%

Uri, just shut up with this total idiocy you write here.

These guys got engines to work at cpu's with 128 bytes RAM and 2KB rom.
Later on they had 4 kilobyte of RAM and a 1Mhz H8 chip. That chip is a lot slower than a 1 Mhz ARM/MIPS type cpu.

Later CPU's had a 4KB RAM and 64KB ROM and a few Mhz.

You just don't have the system time nor code to get real deep.

It's true things are better now, but that's because we have more RAM and faster cpu's in the first place and we had 30 years more time.

If you are sure you are gonna get 4 ply with a todays engine and 6 plies with what they did do, then i'm not so sure any of todays engine would stand a chance. Besides that todays engines you care about forward prune last 3 plies without picking up tactics, so they would lose everything against Genius, as Genius simply would win tactical every game as todays engines are last few plies tactical 500 elo weaker than what engines back then picked up last few plies.

I would like to see a test of Genius vs any top program that is normalized by node count run at less than say 20,000 nodes. As you say those programs were handicapped by the hardware - they were forced to make compromises we don't have to make. If I had to take a wild guess I would say Komodo would win, but if it turned out the opposite I would not be surprised. Komodo was not designed to do 20k node searches.

Today if I do 20k nodes Komodo searches on average 9.5 ply deep. It has a far superior evaluation to CG so I think it would win - however everything you say is true too - although genius is selective Komodo is more selective. I could see Komodo losing some games for this reason but in general I would expect it to outplay Genius. And tactics dominate little searches.

I wish Richard would package up genius into a UCI compatible engine for PC's without making any other changes so we would not have to speculate, one of the early versions that really dominated computer chess at the time. I would rather that than one of the later versions even if the later CG's are technically stronger. I'm pretty sure our memories will not match the reality and we might be disappointed when comparing to modern programs.

I think it might be possible, if the source code to any dos emulator is available, to wrap this up and make a single executable (without the graphics) with a UCI interface? There should be some attempt to preserve these old programs in some form that is accessible by modern GUI's.

Don

[diep]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

I think that this system is clearly wrong also in the days of Genius(Genius3 is from 1994) and the only reason that it was effective in games is that people did not know to write a good evaluation at that time.

The approach has some real strengths but also some big weaknesses so I cannot refute what you are saying. The primary strength is that you can encode a vastly greater amount of knowledge using such a system but it's not clear to me whether that would have made up for it's weaknesses back then or not.

Fritz5 and Fritz5.32 used this system and I believe that they changed it in Fritz6 and got a signficant improvement.

I urged Frans Morsch to stop doing it and it's possible that he listened to me - or it may just be that he was going to do it sooner or later anyway. I doubt that I told him anything he didn't know though, he is a pretty smart guy.

Are you sure he was doing this?

There is 3 ways to evaluate. You can use a preprocessor. You can evaluate moves and you can use leaf evaluation.

I've always popularized leaf evaluation. Seemed to me Frans tried to focus upon evaluating moves.

The obvious problem of course is that when you search deep you are analyzing positions that could be totally different from the root position the tables are based on. It's my belief that such a system would be terrible for a modern program but possible quite good for a program that rarely searches deeper than 5 ply

In Aegon 1997 it was a French programmer who was leading the pack.
He said clearly at the corridor where a group of programmers were walking: "preprocessing no longer works above 10 ply for VirtualChess".

the question IMHO is a clockcycle issue. Todays evaluation would not be possible at the dedicated computers, as it's using huge lookup tables.

Now it's obvious which side i have taken. In fact it was Bob posting publicly at RGCC that losing 2 ply would prove too much. Note i'm losing more than 2 plies today and i couldn't be happier with such a huge extensive evaluation function which is the largest and the best on the planet

But sure - it's slow.

However if we may choose between getting 3 ply search depth with todays engines or 6 ply with what they did do, knowing they also picked up massively more tactics each ply, then the choice is simple.

You're not through the tactical barrier there.

- like some of those old programs. The ELO rating curve is severe for shallow searches so a really good but slow evaluation would kill your program.

First tournament i showed up i got 5 ply search depth, that was at a 486.
Now of course compilers were not so great in those days and my C code a lot crappier than that compiler.

I played against 90Mhz pentiums.

Todays Diep evaluation function would do a much better job, yet i would need to do it the SMK way and go for a real dubious shallow search. Nullmove and reductions would be too expensive and have too much overhead for that. Real dubious search just to pick up tactics.

The question then is whether your evaluation function, that searches positional only 2 plies then or so and the rest is just tactical extensions, whether that would make a chance against preprocessors; now i assume of course a preprocessor using todays knowledge in the preprocessror.

At those small search depths up to a ply or 9 we must realize clearly that a number of strategical issues are relative easy to put in a preprocessor.

We must however not blow up things. They simply had very little chessknowledge back then also in those preprocessors.

I have clear proofs of that, and it involves positions where i tried to make things clear to Diep, which obviously is in 0 of those preprocessors from back then.

So in that sense they didn't use the preprocessor tables to the full extend either.

There is a few rather simple strategical concepts that do not even need too much code, which you can put in a preprocessor rather well and which are rather complicated to build in a leaf evaluation.

In a preprocessor you're more busy with the MOVE you actually play than how things work today. Being busy with the move is a lot SIMPLER and therefore easier to bugfree program. That it's a wrong concept above those plydepths, that's trivially what i said so back in 90s and i had rather little support - only Bob.

I was never very good about keeping up with what everyone else was doing, but I believe this was a very popular technique only in the early days of 8 bit computing. I'm sure there are exceptions of course but but maybe Frans was one of the last hold-outs.

He evaluated moves AFAIK.

Shredder in 90s still was a big preprocessor i got impression; of course by then most programs were hybrid.

Frans is an amazing engineer. He has these incredibly strong PC programs but he could also write programs for tiny and cheap embedded devices that used hardly any memory - where piece square tables would have been considered a shameful luxury. I think his PC programs shared some of the same ideas because even though they were far more sophisticated (hash tables, etc) they had the same "waste no resource" feel such as an evaluation function that was no bigger than it had to be. People were always critical of Fritz as a "dumb but fast" program but I thought it was quite impressive.

There is no discussion about Frans capabilities at the dedicated machines; superior assembler and a good debugger.

Maybe it's the courtcases of chessbase and their massive tricks to dick other engines, that spoiled the fritz idea for me.

From the ssdf rating list:

97 Fritz 6.0 128MB K6-2 450 MHz 2612 17 -17 1751 48%
108 Fritz 5.32 128MB K6-2 450 MHz 2555 20 -20 1194 48%

From the CEGT 40/4 rating list that may be equivalent to tournament time control at the time of Genius:

666 Fritz 6 2455 13 13 1791 49.1% 2462 31.7%
729 Fritz 5.32 2425 13 13 2006 52.0% 2411 29.7%

[/quote]

SSDF was in and in corrupt. I remember an email communication between me and Thoralf Karlsson. I had noticed that Tiger was dicked by 1 elopoint at the SSDF rating list; basically tiger was number 1, but by waiting another few months until an update from fritz arrived, fritz could beat it by 1 elopoint.

that's why i had shipped Thoralf the question on whether if i would ship diep, it would be on the next possible rating list.

He wanted the value of 2 computers. Around a 5000 dmark, to GARANTUEE they would manage to get it on the rating list within normal time frame (3 months) rather than wait 6 months like with Tiger.

This guy was so corrupt. I was told he was a surgeon and made good money being a surgeon. Seemingly that wasn't enough for him.

Other SSDF members i spoke to, they confirmed this image. Everything was for sale and the way how most testing happened was total amateuristic.

Like one example i'll give of a guy telling me he gave a normal pentium 200Mhz computer was given time reduction, so less than 40 in 2 level, meanwhile the other computer a 166Mhz Pentium MMX was given the full 40 in 2.

this were the MMX processor had a larger L1 cache and was so much significant faster for a lot of engines.

chessbase ran exclusively at the MMX machines at SSDF.

So it enjoyed i suppose, but can't verify that as it was a word of mouth, everywhere a time advantage meanwhile also running at faster hardware.

I remember reports from several book authors and programmers who explaiend to me about disappearing games. They saw their program lose a game, then they knew it would take another line, because of book learning, and the next game they received, was not this line, but something they calculated had to be 200 games further.

Entire sets of games missing in short.

I noticed so many mistakes.

I remember Fritz enjoying the advantage of always being master and starting with white. A HUGE advantage. In combination with missing games that meant they statistically always played more white games than black.

I remember Fritz not giving the SR command to opponents, causing Rebel to not learn. They should simply not have posted those results on SSDF and given Ed the opportunity to fix it.

I remember repeated games.

And always the smell of corruption and bribing was there and i am a witness of that happening there, besides the word of mouth from (ex-)SSDF members.

In this sense computerchess always has been rotten.

It's not like the other guys other than chessbase were innocent either. Ed had his own arbitration trick. Rebel only would report games to be lost when score was above 5.0, yet it would stop the game being a rook down and that it evaluated then as 4.5, so it would be part of the 'aborted games' or seen as a draw rather than carry a 1-0 or 0-1.

Shredder had a trick that if it lost the current game, it would store the PGN of that loss as a sideline in the previous game.

The previous game being a draw or a win of course for shredder.

Though this contributed not that much elo as it 'happened' by accident only with the first game you played. If it won i can't remember it ever having been stored as a sideline...

At a certain point i decided that diep would not easily run in other GUI's as these guys used too many tricks to dick other engines.

[Uri Blass]

Hi Don,

Over the years I've had quite a few conversations with Richard. Here's what I know (and I'm sure he wouldn't mind me sharing).

• CG doesn't have a Q Search as Ed rightly said
  I know from playing with the engines its search is extremely asymetrical i.e it searches broadly on opponents moves and narrow on its own moves
  It doesn't use null move (or didn't back in 2000)
  It keeps an incremental attack table for each square
  It uses evaluation terms at each node to prune (in lieu of null move)

Yes, all of that. I have seen part of his documentation, the Ossi papers as I have called them. They were wrongly (as I later found out) mailed to me instead of Richard's home address, a package of 200 A4 pages. Ossi wrote very instructive an detailed eval terms with clarifying diagrams that went into some form of PST structure initialized before the search started. Hundreds of patterns and pawn structures. Hence CG had a fast eval driven by a kind of sophisticated PST based system.

In those days the piece square tables tended to be pre-processed and with some creativity you could have a very comprehensive evaluation function that was also very cheap because the values were determined just once, before each search begins. You could take the time to have a very expensive analysis to determine where to put pieces.

Some of my early programs also had such a system - in fact I built a little language so that Larry could express evaluation concepts in a more natural way. This has it's limitations for a deep searching program but it was quite effective for programs that could only search a fraction of the depth today's programs could.

I think that this system is clearly wrong also in the days of Genius(Genius3 is from 1994) and the only reason that it was effective in games is that people did not know to write a good evaluation at that time.

Fritz5 and Fritz5.32 used this system and I believe that they changed it in Fritz6 and got a signficant improvement.

From the ssdf rating list:

97 Fritz 6.0 128MB K6-2 450 MHz 2612 17 -17 1751 48%
108 Fritz 5.32 128MB K6-2 450 MHz 2555 20 -20 1194 48%

From the CEGT 40/4 rating list that may be equivalent to tournament time control at the time of Genius:

666 Fritz 6 2455 13 13 1791 49.1% 2462 31.7%
729 Fritz 5.32 2425 13 13 2006 52.0% 2411 29.7%

Uri, just shut up with this total idiocy you write here.

These guys got engines to work at cpu's with 128 bytes RAM and 2KB rom.
Later on they had 4 kilobyte of RAM and a 1Mhz H8 chip. That chip is a lot slower than a 1 Mhz ARM/MIPS type cpu.

Later CPU's had a 4KB RAM and 64KB ROM and a few Mhz.

You just don't have the system time nor code to get real deep.

It's true things are better now, but that's because we have more RAM and faster cpu's in the first place and we had 30 years more time.

If you are sure you are gonna get 4 ply with a todays engine and 6 plies with what they did do, then i'm not so sure any of todays engine would stand a chance. Besides that todays engines you care about forward prune last 3 plies without picking up tactics, so they would lose everything against Genius, as Genius simply would win tactical every game as todays engines are last few plies tactical 500 elo weaker than what engines back then picked up last few plies.

In the 90s i was the big promotor of course of not using preprocessor engines. Bob joined me in that. With that we were initially the only ones.

Yet that was already at very capable CPU's compared to the days that genius was dominating.

Genius dominated in the 80s.

It tactical won every game it played.

To quote Frans Morsch about those days: "Every game was decided within 25 moves, as either you dropped a piece somewhere, or your opponent blundered a piece or even queen."

That's the days when Genius dominated.

Had you lived in those days and been busy with computerchess, you would have been one of those guys posting against Bob and me in the 90s saying that only seeing tactics deeper would be interesting and that preprocessing would be more than sufficient as it is FASTER.

Furthermore you live in an illusion. The reason todays evaluation functions of the PSQ beancounters is so fast is because they use a LOOKUPTABLE for the material.

I didn't checkout sizes, but that'll be a megabyte huge or so in most cases.

You didn't have the RAM for that back in 80s.

Your entire RAM is 4 kilobyte or less. You cannot calculate even todays evaluation within sufficient clockcycles.

Everything is 8 bits.

You are so far away from reality that it's not even funny.

If you got outsearched 1 ply that was a lot. If they outsearched you 2 plies.
I remember Bob writing in RGCC that Diep's approach of improving the evaluation function and focussing completely upon evaluation, that this would never work as a slower evaluation function would mean getting outsearched ply, which would prove too much.

Basically now you defend better evaluation functions, which i'm of course favouring, yet you do that with the knowledge of today, without realizing the limitations of the 80s.

Again YOU DON'T HAVE ENOUGH RAM FOR A LOOKUP TABLE, and if you had you'd gladly use it for a hashtable. LMR can't work without hashtable, to give you one example, and would not work back then of course, as alternatives are much better then.

Nullmove was victorious only years later. We speak of mid 90s then.

Ed Schroder got number 1 on SSDF by what was it 1998 or so?
With a program doing about everything todays game tree search programmers only get forced to use in their NIGHTMARES.

At the first series of processors where better evaluation functions were possible, the world champions name is Ed Schroder. Basically he already followed the idea of a better evaluation function but more importantly was searching very selective meanwhile not missing too much tactics.

The world title of Ed not only ends domination of Genius in a clear manner, it also sings the song of how to better evaluate and it also terminates the dominance of supercomputers in open hardware contests.

I remember that Genius3 on P90 beat kasparov in 1994 and
I thought about the 90th and not about older times when your entire RAM is 4 kilobyte or less.

[Rebel]

It's not like the other guys other than chessbase were innocent either. Ed had his own arbitration trick. Rebel only would report games to be lost when score was above 5.0, yet it would stop the game being a rook down and that it evaluated then as 4.5, so it would be part of the 'aborted games' or seen as a draw rather than carry a 1-0 or 0-1.

Connect your brain to some anti-virus software.

[diep]

It's not like the other guys other than chessbase were innocent either. Ed had his own arbitration trick. Rebel only would report games to be lost when score was above 5.0, yet it would stop the game being a rook down and that it evaluated then as 4.5, so it would be part of the 'aborted games' or seen as a draw rather than carry a 1-0 or 0-1.

Connect your brain to some anti-virus software.

Ah you don't like it.

Well i got a phone call back then from Jan Louwman who at 36 machines had been testing Diep.

"Diep won nothing against Rebel".

Ed, we speak of a game or 150, time control 40 in 2 back then and Diep had, according to Rebel's GUI won 0 games, which is what Jan told me through the phone very upset

When i checked out Diep's logs i saw a different truth though on what had been played

Checking Rebel closer then the naked truth became obvious.

You guys all had your methods to increase score. After all, the human operator interpreting the score is most important. Jan thought it was games that were removed by Rebel because of 2 times the exact same game and had not given those games attention of course. He just read up the score that Rebel GUI displayed