[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments by rescharn
Capablanca Random Chess. Randomized setup for Capablanca chess. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]Well, having no suggestions yet, I made some myself: All castlings placing the King three squares from the left white side will be written as O-O-O (standard). All castlings placing the King two squares from the right white side will be written as O-O (standard). All other castlings will be written e.g. O-O-b terminated by the King's target column letter, here 'b'. Would that be acceptable?
Hi Sam, there seem to be different kinds of free castling, thus including one-step-castlings. This is one reason and another, because a castling should be obviously in its notation Thus I would prefer adaptions to the classic notation. Another question is, that a GUI should be more flexible in accepting several kinds of notations. Nevertheless I try to unify such notations into a common mimic.
In the case of a real free castling there is the possibility to also have castlings, wherein the king is making only one single step. Then an encoding as e.g. Kd1 is not sufficient to distinguish a castling move from a simple King's move. Moreover in traditional chess O-O and O-O-O is used. Thus the representation should be very related to that. using O-O-x has more common parts to those traditional forms than O-x. Thus I am preferring that. By posting here I intended to investigate the status quo of writing down castling moves in variants, before I would start to implement such abilities in SMIRF's successor application Octopus.
Rules of Chess: En passant capture FAQ. Answers to some questions about the en passant capture rule.[All Comments] [Add Comment or Rating]The question: 'Can other pieces except pawns capture en passant?' has been negated. But that is not quite exact. I will explain this: There had been a time in ancient chess, where pieces had been allowed to make only one single step. Thus chess had been a very slow game. Later in Italy chess has been modernized: the sliding of some pieces has been invented, an initial double step of pawns was introduced, and castlings were designed. But those moves have not been regarded each to be a continuous move, instead they had been interpreted as a serie of independent moves, by which chess could be sped up. This point of view leads by exception of the sliding moves (to avoid trouble when those pieces do capturings themselves) to the situation, that an opponent was allowed to answer by capturing also to any of the intermediately used target fields. Now only pawns are allowed to answer that way on pawns double step moves. And so it is clear, why that e.p move is merely allowed in the intermediate following move. But looking at castling moves you see, that a king still is not allowed to pass any square, where he would be in chess. That is nothing else, than that every enemy piece would be allowed to capture him via e.p..
Aberg variation of Capablanca's Chess. Different setup and castling rules. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]A short remark on piece values: first, my published model is not my last word, I still am working on that. As I have stated already an amount of time ago, piece values are depending from the percentage of emptyness of the board. It concerns the mobility value part of sliding pieces. This would lead to dynamic piece values of sliding pieces slowly growing through a game. SMIRF unfortunately is far away from that. Then I modified my thoughts on the nature of a bishop pair value bonus, which in fact had not been implemented in SMIRF yet at all. Errornously I derived that value modification from the fact, that a Bishop can reach merely one half of a board. But this is only a legal but misleading view on that strange effect. Today I am relating this paradoxon to the hideability of pieces more valued than a Bishop. Thus there is a chance to positionally devalue an opposite single Bishop by moving ones big pieces preferred on squares coloured oppositely to the Bishop's one. But that view demands the value bonus not to be applied statically by summing up piece values and such a bonus, but by writing an appropriate positional detail evaluation (as I have done intuitively in SMIRF). To try to find out piece values by having teams of different armies fighting each other seems to be very promising at a first sight. But as you see in those huge table bases: a lot of optimal play is done pure combinatorically and could end contrarily, if placing one piece only a step aside. Thus it is hard to understand why to densly relate outcomes of a games and piece values. In an extreme constellation having King+Knight against King (which is a draw anyway) such an approach would lead to the conclusion, that a Knight is valued to nothing.
To Derek: we know how much work you have invested in your piece value theory, so I understand, that you are somehow enraged on H.G.M.'s interpretations of his attempts. But all individuals I know to be investigating in that matter are strong-minded people. Thus please do not misinterpret their persisting in their viewpoints as pure animosity. To all: I understand, that the clearness and consistence of a value defining model is not enough to convince doubters to the 'truth' of such models. That way generated values have to be verified in practise. The easy part of that is to compare such figures to those experienced from 8x8 chess through centuries. The difficult rest of verification is to apply claimed value scales e.g. in 10x8 and to check out if they are well-working. But it is unsufficient, to simply optimize a bunch of values within a given variant, because that does not establish a neutral theory, which could be applied on other scenarios, to be falsified or verified therein. A valid theory's conclusions have to exceed their input by magnitudes. Watching the results of H.G.M.'s very interesting 'Battle of the Goths' experiments, what does this induce for our value theory discussion? In my opinion, there hardly could be derived anything concerning this question. Of course, some games have to be reviewed intensively for to see, whether there would have been structural imbalances. But to me it seems impossible to separate those engines' positional abilities from their tactical power, which is obviously very depending from the maturity of their implementation. My program SMIRF is - as repeatedly stated - my first self-written playing chessengine, also often repaired and modified, but still caught in its initial naive design with a lot of detected basic weaknesses. Its detail evaluation as an example is incredible slow. Mating phases of games lead to concurring incompatible evaluations in SMIRF, thus some games will be lost even though having a clear mating line in view. SMIRF has been programmed without using foreign sources. By all of that it is no ripe engine - and thus I plan to put my experiences into a follow-up engine Octopus, which nevertheless will need a lot of time. Derek and I have experimented with having different models applied to equal engines, identical beside of those different value approaches. Though this seems to be the more relyable approach for to verify value models, it nevertheless has structural weaknesses too, as in the realization of such a program there will be a lot of parts, reflecting the ideas of its creator, making it not completely independent of the ideas of that programmer. So what is the arriving conclusion from H.G.M.'s event? SMIRF has to be rewritten as Octopus to become more mature. And maybe H.G.M. might try to embed his value model within a verificatable abstract theory, if he would like to widen its acceptance.
To H.G.M.: There is no need for a polemic like: '1) Joker80 knows how to play a game of 10x8 Chess, and does so better than Smirf (oh, sorry about the 'insult', how politically incorrect of me to say such a thing...)' SMIRF still is behind, but that does not necessarily imply anything for used value models. The majority of Jokers losses were reached by SMIRF type engines, but I hesitate to derive some value related conclusions from that.
SMIRF lost several games by making a weird move instead of continuing a mating process. This has nothing to do with value models, but is related to other internal problems. So I hope e.g. for SMIRF-o-glot to ask for SMIRF's move decision explicitely instead of simply taking the move posted last as the optimal one during its thinking process, because there might indeed be a change during the last microseconds especially in such situations. Anyway SMIRF still does not handle mating scenarios correctly, which leads to some thrown away victories.
There are a lot of other design problems within SMIRF, thus I could explain its losses yet without having to throw away my piece value model.
Excuse me, when writing an old suggestion how to reduce tactical draws (where material does not force a draw): Instead of only accepting or refuting a draw the opponent player should have the right to simply change the sides (because the suggestor obviously is convinced that would be no disadvantage). A draw should be possible only after at least one such a change of sides and a minimum of five moves following it.
Aberg variation of Capablanca's Chess. Different setup and castling rules. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]Maybe it could be interesting to read some ideas of mine at http://www.10x8.net/Compu/schachwert1_e.html .
Well, I recalculated the values for both piece types using my last published model (which probably is not perfect ;-) ): High Priestess: 8x8: 6+1/28; 10x8: 6+5/36; 10x10: 6+19/45 Minister: 8x8: 6+5/7; 10x8: 6+3/4; 10x10: 6+44/45 Let me admit, that now it seems to me more impressive, to scale piece values no longer to a Pawn normalised as 1, instead to do it using a Knight normalised to 3. This remains neutral to the pieces' values relative to each other, but it seems to create more comparable value series. The High Priestess' strength is more vulnerable by a decreasing board size. Values of both types tend to become equal at an unlimited board size.
Aberg variation of Capablanca's Chess. Different setup and castling rules. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]HGM: It is pure luck, that chess computer program strengths accompanied our masters for a time. Nobody will try to win a sprint against a Porsche, because the difference is even more obvious. So it does not tell anything about how to handle a subject, when different species are competing. As for our both chess programs, which are obviously of different maturity, you can find out, which is currently more successful, but that does not mean, that the winning one is based on 'more correct' ideas. Ideas are rarely implemented in equal quality. Maybe it needs a lot of approaches of different people to have a decision on such a question after a long time period.
Harm, let me then focus on your method to have one engine play itself other using different armies: I am convinced - so please correct me if need be - that your engine has implemented just that value scheme, you are talking about. Suppose, that true values probably are somehow different from the built in figures. Then your engine will throw away underestimated pieces too cheap and keep overestimated too dear. Thus it will start and avoid a lot of trades in unjustified manner. And the bad payload for this is, that you are not able to detect it, because equal engines are blind to penalize each other for such mistakes. And in the end therefore such tests tend to become a self fulfilling prophecy.
I wrote: Then your engine will throw away underestimated pieces too cheap and keep overestimated too dear. Thus it will start and avoid a lot of
trades in unjustified manner.
This hardly occurs, because this is SELF-PLAY.
Probably you have not understood my intention. On games between our engines you commented to some trades, that your program would never do such. And this I suppose is true. Thus your engine vs. engine games are avoiding such type of trades, and never experiencing, whether such trades would be beneficial or not.
Trades in your type of engine vs. engine games will happen only, if both engines agree in the equality of that trades, or if one engine has already come into an inferior situation and could not avoid a bad trade. But then the game might allready be decided.
Thus there are no trades caused by different views of pieces values, which could make a trade attractive for BOTH sides. Thus your model is never verified at such critical moments.
This hardly occurs, because this is SELF-PLAY.
Probably you have not understood my intention. On games between our engines you commented to some trades, that your program would never do such. And this I suppose is true. Thus your engine vs. engine games are avoiding such type of trades, and never experiencing, whether such trades would be beneficial or not.
Trades in your type of engine vs. engine games will happen only, if both engines agree in the equality of that trades, or if one engine has already come into an inferior situation and could not avoid a bad trade. But then the game might allready be decided.
Thus there are no trades caused by different views of pieces values, which could make a trade attractive for BOTH sides. Thus your model is never verified at such critical moments.
Harm: If there is a best strategy (i.e. best set of piece values) it must be shared by both sides. The theoretically best play is amongst the set of self-play games. And it is only the score that results from theoretically best play that determines the piece value.
First there is no 'best play' without having complete information. But such is far away from human experiences. Nevertheless supposing to be in such a hypothetic well informed situation, indeed participating optimal players would behave related to the way you stated - beside of the fact, that then there would be no longer a need for any piece value at all, because then all nodes merely will be valued as +1, 0 or -1.
So the question is, whether your approach would be convergent to any claimed ideal value model. Living within a world without such a perfect information and using engines, which all are wearing blinkers then hiding tabooed piece trades, I intensively doubt on that. You will have to try a lot of different models implemented into engines of equal maturity to find out after a lot of experiments.
First there is no 'best play' without having complete information. But such is far away from human experiences. Nevertheless supposing to be in such a hypothetic well informed situation, indeed participating optimal players would behave related to the way you stated - beside of the fact, that then there would be no longer a need for any piece value at all, because then all nodes merely will be valued as +1, 0 or -1.
So the question is, whether your approach would be convergent to any claimed ideal value model. Living within a world without such a perfect information and using engines, which all are wearing blinkers then hiding tabooed piece trades, I intensively doubt on that. You will have to try a lot of different models implemented into engines of equal maturity to find out after a lot of experiments.
J.J.: '... Play the High Priestess and Minister on SMIRF or ...'
SMIRF still is not able to use other non conventional piece types despite of Chancellor (Centaur) or Archbishop (Archangel). You have to use other fine programs. Nevertheless the SMIRF value theory is able to calculate estimated piece exchange values.
Currently I am about to learn the basics of how to write a more mature SMIRF and GUI for the Mac OS X operating system. Thus it will need a serious amount of time and I hope not to lose motivation on this. Still I have some difficulties to understand some details of Cocoa programming using Xcode, because there are only few good books on that topic here in German language. We will see if this project will become ready ever.
SMIRF still is not able to use other non conventional piece types despite of Chancellor (Centaur) or Archbishop (Archangel). You have to use other fine programs. Nevertheless the SMIRF value theory is able to calculate estimated piece exchange values.
Currently I am about to learn the basics of how to write a more mature SMIRF and GUI for the Mac OS X operating system. Thus it will need a serious amount of time and I hope not to lose motivation on this. Still I have some difficulties to understand some details of Cocoa programming using Xcode, because there are only few good books on that topic here in German language. We will see if this project will become ready ever.
Well Derek, I did not understand exactly, what you have done. But it seems to me, that you exchanged or disposed some different pieces from the Capablanca piece set according to SMIRF's average exchange values. Let me point to a repeatedly written detail: if a piece will be captured, then not only its average piece exchange value is taken from the material balance, but also its positional influence from the final detail evaluation. Thus it is impossible to create 'balanced' different armies by simply manipulating their pure material balance to become nearly equal - their positional influences probably would not be balanced as need be. A basic design element of SMIRF's detail evaluation is, that the positional value of a square dominated by a piece (of minimal exchange value) is related to 1/x from its exchange value. Thus replacing some bigger pieces by some more smaller types keeping their combined material balance will tend to increase their related positional influences. You see, that deriving conclusions from having different armies playing each other, is a very complicated story.
The infeasibility of using different armies to calculate piece values
To Derek Nalls and H.G.M.:
Nearly everyone - so I think - will agree, that inside a CRC piece set the value of an Archbishop is greater than the sum of the values of Knight and Bishop, and even greater than two Knight values. Nevertheless, if you have following different armies playing against each other:
[FEN 'nnnn1knnnn/pppppppppp/10/10/10/10/PPPPPPPPPP/A1A2K1A1A w - - 0 1']
then you will get a big surprise, because those 'weaker' Knights will be going to win.
There are a lot of new and unsolved problems, when trying to calculating piece values inside of different armies, including the playability of a special piece type, e.g. regarding the chances to cover it by any other weaker one.
To Derek Nalls and H.G.M.:
Nearly everyone - so I think - will agree, that inside a CRC piece set the value of an Archbishop is greater than the sum of the values of Knight and Bishop, and even greater than two Knight values. Nevertheless, if you have following different armies playing against each other:
[FEN 'nnnn1knnnn/pppppppppp/10/10/10/10/PPPPPPPPPP/A1A2K1A1A w - - 0 1']
then you will get a big surprise, because those 'weaker' Knights will be going to win.
There are a lot of new and unsolved problems, when trying to calculating piece values inside of different armies, including the playability of a special piece type, e.g. regarding the chances to cover it by any other weaker one.
Derek, my example must be extreme. Only then light might fall to the obscure points. My current interpretation to that strange behavior: it is part of a piece's value, that it is able to risk its own existence by entering attacked squares. But that implies that it could be covered by a minor piece. And covering is possible only, if there is at least one enemy piece of equal or higher value to enable a tolerable exchange. In your and mine examples that is definitely not the case. My conclusion is, that the most valued pieces will decrease in their values, if no such potential acceptable exchange pieces exist. My assumption to that is, a suggested replace value would be: ( big own piece value + big enemy piece value + 1 pawn unit ) / 2 This has to be applied to all those unbalanced big pieces. ( Just an idea of mine ... ) P.S.: after rethinking on the question of the value of such handicaped big pieces (having no equal or bigger counterpart) I now propose: ( big own piece value + 2 * big enemy piece value ) / 3
Derek, now it no longer is that easy. Because now in SMIRF piece values are only implemented in their statical part. Their mobility part will be covered by the detail evaluation. The '-X' versions of SMIRF have made a mixture of those, the '-0' version is completely without mobility fractions. This is a minor detail of my new approaches. Nevertheless if you would separate those components compiles are possible.
Well, Derek, I will use my own values for 8x8, if you have none new for Q,A,C ... I still have not published my current values (because they normally are not used inside of SMIRF, and only the mobility parts have been modified), I will use those then in the requested compiles: N,B,R,A,C,Q for 8x8: 3.0000, 3.4119, 5.1515, 6.7824, 8.7032, 9.0001 N,B,R,A,C,Q for 10x8: 3.0556, 3.6305, 5.5709, 7.0176, 9.1204, 9.6005
Derek, you will receive versions compiled using complete piece values.
Different armies in action: 4*Archbishop vs. 8*Knight
Following game could be reviewed using the SMIRF donationware release
from: http://www.chessbox.de/Compu/schachsmirf_e.html
(but first replace the single quotes by double quotes before pasting)
[Event 'SmirfGUI: Different Armies Games']
[Site 'MAC-PC-RS']
[Date '2008.05.02']
[Time '18:30:40']
[Round '60 min + 30 sec']
[White '1st Smirf MS-174c-0']
[Black '2nd Smirf MS-174c-0']
[Result '0-1']
[Annotator 'RS']
[SetUp '1']
[FEN 'nnnn1knnnn/pppppppppp/10/10/10/10/PPPPPPPPPP/A1A2K1A1A w - - 0 1']
1. Aji3 Nd6 {(11.02) -1.791} 2. Aab3 Ne6 {(12.01=) -1.533} 3. c4 c5 {(12.01=)
-0.992} 4. d4 cxd4 {(13.00) -0.684} 5. c5 Ne4 {(12.01) -0.535} 6. Ac2 d5
{(11.39) +0.189} 7. f3 N4xc5 {(11.01=) +0.465} 8. Ag3 Nac7 {(11.01) +0.900} 9.
b4 Ncd7 {(11.01=) +1.475} 10. f4 g6 {(10.31) +1.750} 11. Ai5+ Ngh6 {(11.03+)
+1.920} 12. g4 j6 {(12.01=) +2.225} 13. Aie1 Nig7 {(11.01=) +2.363} 14. Ac1d3
f6 {(10.20) +2.506} 15. a4 N8f7 {(11.01=) +2.707} 16. Kg1 a5 {(11.01) +2.803}
17. bxa5 Nc6 {(11.15) +2.910} 18. Ab3 Nji6 {(11.01) +2.570} 19. j4 f5 {(12.03=)
+3.010} 20. gxf5 Ngxf5 {(11.01) +3.342} 21. a6 bxa6 {(11.01=) +3.998} 22. a5
Ne3 {(11.15) +4.156} 23. Aa4 Nb5 {(11.01=) +4.504} 24. Ab3 Nig7 {(11.03=)
+5.244} 25. Aih4 Nf6 {(11.02) +5.324} 26. Aef2 Nfh5 {(10.19) +6.395} 27. Ah3
Nhxf4 {(11.01) +6.172} 28. Adxf4 Nxf4 {(14.01) +5.979} 29. Axf4 g5 {(12.14)
+6.086} 30. Ahxg5 Nxg5 {(14.01=) +6.018} 31. Axg5 Kg8 {(14.11) +5.176} 32. Axe3
dxe3 {(16.01=) +5.117} 33. Axd5+ Kh8 {(16.01=) +5.117} 34. Axc6 Nhf5 {(14.18)
+5.127} 35. Ab4 Nc7 {(15.00) +4.803} 36. Ad3 Ki8 {(15.00) +4.838} 37. Kh1 Nd6
{(14.01) +4.891} 38. j5 Ngf5 {(14.01=) +5.189} 39. Ac5 Ndb5 {(14.01) +5.248}
40. Ad3 Nbd4 {(14.01) +5.365} 41. Ae4 Ncb5 {(16.02) +5.631} 42. Ki1 e6 {(15.23)
+5.932} 43. Ad3 h6 {(15.01) +5.250} 44. Ac4 h5 {(15.01=) +5.467} 45. i3 Kj7
{(15.12) +5.637} 46. Ad3 Nc3 {(15.09) +5.715} 47. Axa6 Ndxe2 {(15.00) +5.678}
48. Ad3 Ned4 {(14.01=) +6.117} 49. a6 Ncb5 {(14.01=) +6.602} 50. Kj1 e2
{(15.01=) +8.080} 51. Ae1 e5 {(15.01=) +11.59} 52. i4 e4 {(15.01=) +12.16} 53.
ixh5 Nf3 {(14.02) +12.56} 54. Af2 e3 {(15.22) +14.61} 55. Ad3 e1=Q+ {(16.02)
+16.00} 56. Axe1 Nxe1 {(17.01=) +23.09} 57. h6 ixh6 {(15.02=) +M~010} 58. h4
Nxh4 {(12.01=) +M~008} 59. a7 Nxa7 {(10.01=) +M~008} 60. Ki1 Neg2+ {(08.01=)
+M~007} 61. Kh2 e2 {(06.01=) +M~006} 62. Kh3 e1=Q {(04.01=) +M~005} 63. Kg4
Qe4+ {(02.01=) +M~004} 64. Kh3 Qf3+ {(02.01=) +M~003} 65. Kh2 Qi3+ {(02.01=)
+M~002} 66. Kh1 Qi1# {(02.00?) +M~001} 0-1
You will find out, that the handicap of being a big piece without having any exchangeable counterpart is dominating the kind of the battle.Well, H.G.M., if you are believing in your value model, and your engine is using it, then this engine will avoid valid trades (as I regard them to be). If you would trust in your model, you could easily add a black Knight and remove some white Pawns and still have a value sum 'advantage' of the white Archbishops' team. So why do you not test these arrays?
The arrays as I have tested with SMIRF have had an advantage for White of 3.1296 in my model.
In your model (normalized to a Pawn = 1) the advantage has been about 12.944 (more than a Queen's value).
P.S.: Why not have some test games between SMIRF using Black having 9 Knights against your program having 4 Archbishops, each having 10 Pawns? In your value model it should be nearly impossible for Black to gain any victory at all.
P.P.S.: The game as proposed is no subject for Blitz, because it is decided by deep positional effects. So I used 60 min / game + 30 sec / move for the time frame, which is important.
The arrays as I have tested with SMIRF have had an advantage for White of 3.1296 in my model.
In your model (normalized to a Pawn = 1) the advantage has been about 12.944 (more than a Queen's value).
P.S.: Why not have some test games between SMIRF using Black having 9 Knights against your program having 4 Archbishops, each having 10 Pawns? In your value model it should be nearly impossible for Black to gain any victory at all.
P.P.S.: The game as proposed is no subject for Blitz, because it is decided by deep positional effects. So I used 60 min / game + 30 sec / move for the time frame, which is important.
Well, Harm, you know, that I failed in using 10x8 Winboard GUIs, so I discontinued trying that.
25 comments displayed
Permalink to the exact comments currently displayed.