Don wrote: Uri Blass wrote: Don wrote: Rebel wrote: Steve Maughan wrote:
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%
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.