[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments by rescharn
Derek, I have changed your values again within my piece value table.
I hope, you will report on some 9*N vs. 4*A games using your special SMIRF
engine modified to your values. I am very convinced, that the effect of
value reduced unbalanced big pieces exists.
P.S.: Here is a hint to check out my marginally refined approach at page:
http://www.10x8.net/Compu/schachansatz1_e.html
http://www.10x8.net/Compu/schachansatz1_e.html
H.G.M wrote: ... Focussing on mobility only also makes you overlook disastrous handicaps a certain combination of moves can have. A piece that has two forward diagonal moves and one forward orthogonal (fFfW in Betza notation) has exactly the same mobility as that with forward diagonal and backward orthogonal moves (fFbW). But the former is restricted to a small (and ever smaller) part of the board, while the latter can reach every point from every other point. My guess is that the latter piece would be worth much more than the former, although in general forward moves are worth more than backward moves. (So fWbF should be worth less than fFbW.) But I have
not tested any of this yet.
Before I try to think over this argument, remember, all (non Pawn) pieces of the CRC piece set have non orientated gaits. Thus this argument could not change anything in value discussion of the CRC piece set, especially concerning the value of an Archbishop.
Before I try to think over this argument, remember, all (non Pawn) pieces of the CRC piece set have non orientated gaits. Thus this argument could not change anything in value discussion of the CRC piece set, especially concerning the value of an Archbishop.
H.G.M. wrote: ... It thus cannot tell us anything about
piece values. Just like deleting the white Queen and all 8 black Pawns
cannot tell us anything about the value of Q vs P.
I fully agree with that. Because my A vs. N example has not been intended to calculate piece values. Instead it should put light on some obscure details. The strange effect is not caused by the ability of N to cover each other. This also holds for A. It is caused by the absence of exchangeable counterparts for A of equal (or bigger) value size.
My example should demonstrate the existence of new effects in games of different armies. And that implies, that one should be carefully, when trying to calculate or verify piece values by having series of matches between different armies. Such effects as demonstrated in my N vs. A example should be discussed, eliminated or if not to be avoided to be integrated inside a formula. I suggested to reduce the values of such unbalanced big pieces somehow (I am not yet sure how exactly) in the equations you are using to find out special piece values. But without such purification attempts misinterpretations are not to be avoided.
I fully agree with that. Because my A vs. N example has not been intended to calculate piece values. Instead it should put light on some obscure details. The strange effect is not caused by the ability of N to cover each other. This also holds for A. It is caused by the absence of exchangeable counterparts for A of equal (or bigger) value size.
My example should demonstrate the existence of new effects in games of different armies. And that implies, that one should be carefully, when trying to calculate or verify piece values by having series of matches between different armies. Such effects as demonstrated in my N vs. A example should be discussed, eliminated or if not to be avoided to be integrated inside a formula. I suggested to reduce the values of such unbalanced big pieces somehow (I am not yet sure how exactly) in the equations you are using to find out special piece values. But without such purification attempts misinterpretations are not to be avoided.
H.G.M. wrote: ... Defending each other for Archbishops is useless (in the absence of opponet
Q, C or A), as defending Archbishop in the face of Knight attacks is of
zero use. So the factthey can do it is not worth anything. ...
Now you have got it. The main reason is the missing of counterparts of equal (or bigger) value. That is, what makes any effective covering impossible. And this is a payload within an (I confess very extremely designed) game between different armies.
P.S.: any covering of A also by P is useless then ...
Now you have got it. The main reason is the missing of counterparts of equal (or bigger) value. That is, what makes any effective covering impossible. And this is a payload within an (I confess very extremely designed) game between different armies.
P.S.: any covering of A also by P is useless then ...
Vyrémorn Chess. Large variant on two overlapping square boards. (Cells: 132) [All Comments] [Add Comment or Rating]George Duke wrote: ... RN and BN should ideally be called Champion and Centaur, because P. Carrera made them around year 1617. ...
Well, despite of avoiding christian influenced names like Archbishop, I suggested Centaur for RN (to remember Carrera) and Archangel (also existing in Jewish and Islamic contexts) for BN. This is done that way for to also preserve the well established abbreviations A and C.
Well, despite of avoiding christian influenced names like Archbishop, I suggested Centaur for RN (to remember Carrera) and Archangel (also existing in Jewish and Islamic contexts) for BN. This is done that way for to also preserve the well established abbreviations A and C.
H.G.M. wrote: ... After an unequal trade, andy Chess game becomes a game
between different armies. ...
And thus I am convinced, that I have to include this aspect into SMIRF's successor's detail evaluation function.
... This can still be done in a reasonably realistic mix of pieces, e.g. replacing Q and C on one side by A, and on the other side by Q and A by C, so that you play 3C vs 3A, and then give additional Knight odds to the Chancellors. ...
And by that this would create just the problem I have tried to demonstrate. The three Chancellors could impossibly be covered, thus disabling their potential to risk their own existence by entering squares already influenced by the opponent's side.
And thus I am convinced, that I have to include this aspect into SMIRF's successor's detail evaluation function.
... This can still be done in a reasonably realistic mix of pieces, e.g. replacing Q and C on one side by A, and on the other side by Q and A by C, so that you play 3C vs 3A, and then give additional Knight odds to the Chancellors. ...
And by that this would create just the problem I have tried to demonstrate. The three Chancellors could impossibly be covered, thus disabling their potential to risk their own existence by entering squares already influenced by the opponent's side.
H.G.M. wrote: ... Both
imbalances are large enough to cause 80-90% win percentages, so that just
a few games should make it obvious which value is very wrong.
Hard to see. You will wait for White to lose because of insufficient material, and I will await a loss of White because of the lonely big pieces disadvantage. It will be the task then to find out the true reasons of that.
I will try to create two arrays, where each side think to have advantage.
Hard to see. You will wait for White to lose because of insufficient material, and I will await a loss of White because of the lonely big pieces disadvantage. It will be the task then to find out the true reasons of that.
I will try to create two arrays, where each side think to have advantage.
Harm, I think of a more simple formula, because it seems to be easier to find out an approximation than to weight a lot of parameters facing a lot of other unhanded strange effects. Therefore my less dimensional approach is looking like: f(s := sum of unbalanced big pieces' values, n := number of unbalanced big pieces, v := value of biggest opponents' piece). So I intend to calculate the presumed value reduction e.g. as: (s - v*n)/constant P.S.: maybe it will make sense to down limit v by s/(2*n) to prevent a too big reduction, e.g. when no big opponents' piece would be present at all. P.P.S.: There have been some more thoughts of mine on this question. Let w := sum of n biggest opponent pieces, limited by s/2. Then the formula should be: (s - w)/constant P.P.P.S.: My experiments suggest, that the constant is about 2.0 P^4.S.: I have implemented this 'Elephantiasis-Reduction' (as I will name it) in a new private SMIRF version and it is working well. My constant is currently 8/5. I found out, that it is good to calculate one more piece than being without value compensation, because that bottom piece pair could be of switched size and thus would reduce the reduction. Non existing opponent pieces will be replaced by a Knight piece value within the calculation. I noticed a speeding up of SMIRF when searching for mating combinations (by normal play). I also noticed that SMIRF is making sacrifices, incorporating vanishing such penalties of the introduced kind.
Which Mac OS X generic GUIs could be recommended for UCI engines? I intend to write a 10x8 and 8x8 aware pendant to my Windows SMIRF for Mac OS X during this year, but I intend to base it on the UCI protocol then. But if there already is a very sophisticated GUI, I doubt that there would be any need left still for such a multi geometry / variant approach.
H.G.M. wrote: '... he threw the coin only 10 feet up into the air, on each try. While I brought my coin up to 30,000 feet in an airplane ...'
Understanding your example as an argument against Derek Nalls' testing method, I wonder why your chess engines always are thinking using the full given timeframe. It would be much more impressive, if your engine would decide always immediately. ;-)
I am still convinced, that longer thinking times would have an influence on the quality of the resulting moves.
Understanding your example as an argument against Derek Nalls' testing method, I wonder why your chess engines always are thinking using the full given timeframe. It would be much more impressive, if your engine would decide always immediately. ;-)
I am still convinced, that longer thinking times would have an influence on the quality of the resulting moves.
To H.G.M.: why have you to be that unfriendly? But to give you a strong argument, that longer thinking phases could change a game result: have a look at: [site removed], where [a claim is made], that there would be a mate in 9. In fact there SMIRF has been in a lost situaton. But watching a chess engine calculate on that position, you could see, that an initial heavy disadvantage switches into a secure win. Having engines calculate with short time frames would probably lead to another result. Here increasing thinking time indeed is leading to a result switch. [The above has been edited to remove a name and site reference. It is the policy of cv.org to avoid mention of that particular name and site to remove any threat of lawsuits. Sorry to have to do that, but we must protect ourselves. -D. Howe]
Harm wrote: ... 'OTOH, a program that evaluates every position as a completely random number starts to play quite reasonable ches, once the search reaches 8-10 ply. Because it is biased to seek out moves that lead to pre-horizon nodes that have the largest number of legal moves, which usually are the positions where the strongest pieces are still in its possession.' ... This is nothing but a probability based heuristic simulating a mobility evaluation component. But having a working positional evaluation, especially when also covering mobility, that randomizing method is not orthogonal to the calculated much more appropriate knowledge. Thus you will overlay a much better evaluation by a disturbing noise generator. Nevertheless this approach might have advantages through the opening, preventing some else working implementations of preinvestigated killer combinations.
H.G.M.: '... This move blundered away the Queen with which Smirf was supposed to mate, after which Fairy-Max had no trouble winning with an Archbishop agains some five Pawns. ...' Well, there still is a mating bug within SMIRF. Though I have improved SMIRF's behavior near mating situations (please request a copy of this unpublished engine if needed for key owners' testings), it still seems to be there. There might be a minimal chance, that it sometimes could be caused by a communication problem using the adapter. But I am still convinced, that it is caused by a internal bad evaluation storing design, which hopefully would be corrected in Octopus sometimes ...
Sam Trenholme: '... and I needed to give Smirf over a minute to make a move ...' I presume, you had used the donation ware version of SMIRF, which probably is about 150 Eló behind of the donators' bonus version of SMIRF (actually improved again). Nevertheless Joker80 is the top 10x8 engine.
Grotesque Chess. A variant of Capablanca's Chess with no unprotected Pawns. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]'... support for the 'free' castling ...' This is not clear to me. I think it over to possibly implement free castling into SMIRF, but still there is missing a detailed explanation of rules and notations (I would suggest: O-c-O if King is castling to column c). Where could I have a closer look?
To H.G.M.: Harm, you are proposing a lot of things simultaneously. So let me answer slowly. There should be a main primary demand, that such an extended FEN should end in an IDENTICAL string, when applied to common chess variants. Otherwise I would not like to support it. There already has been a quarrel concerning X-FEN and Shredder-FEN, which is incompatible to that demand. Nevertheless in the early days of X-FEN I modified its definition concerning a less important element to also cover the proposed additional demand to have a partial castling string in FEN NEVER longer than 4 letters. I would like to preserve that state of the art of X-FEN. Actually I would like as a first step to merely support castling rights, where the castling piece will be placed upon the next inner square neighbored to the (one only) castled King. The King will be placed by default THREE steps from the a-side performing 'O-O-O' and TWO steps from the other side performing 'O-O'. The algebraic notation should use source and target coordinate, when the king is moving at least two steps when castling with the most outside Rook. Otherwise the coordinate of the involved piece has to replace the (redundant) target square. This is for to serve two goals: a) to avoid a mixing up with traditional King's moves, b) to give the GUI a unique information, by which input gesture a castling should be intended without any doubt. Such a modification should not be interpreted as a 'capturing' of the involved piece, instead as a jostling it for to have it join the castling procedure. To encode the castling rights: the default is to address the most outer Rook by traditional letters 'Qq' for the a-side, 'Kk' for the opposite side. In any other case the column letter of the involved piece should be used: in upper case, where a white colored piece is addressed, in lower case, where that piece would be black colored. Now to different castling methods: because such methods would target all possible castlings (never different methods for different pieces) it does not make sense to encode this related to the elementary castlings. Instead the whole partial castling string inside a FEN has to be addressed. In SMIRF I solve this by applying a special prefix letter, which has to be different from any possible column letter to avoid misinterpretations. Now let me stop at this point, to have the written text being discussed.
H.G.M.: '... how much effort one should put into upkeeping a unified approach ...' Why not, if the effort isn't too big? So let's try out some ideas. H.G.M.: uses: 'Ke1-i1&Rj1-h1' Maybe I am too traditional, but I would like to have an encoding startig with 'O'. Here I would suggest to write 'O-i-h' using the first column letter for an untypical King's target square and the second one for an untypical (not inner neighbored) Rook's target square. H.G.M.: '... but simply as FROM and TO square ...' Appending a letter (I would prefer the involved Rook's/piece's source column letter) is only a partial solution, because this forces the GUI to somehow generate the input gesture squares, which demands, that its programmer has anticipated this (what is not necessarily the case at a new variant). But, because the problem of two unique squares representing this move exists nevertheless, it would be covering more, to use those square coordinates also for to communicate the move. Nevertheless here again is an encoding problem, when a free castling would also allow to place the Rook on different selectable squares. Thus I still have problems with such types of castlings. My understanding of a GUI is, that it has not to know much about chess. It has to ask for all the possible moves, have the user make a selection e.g. by clicking at two squares, and to communicate this choice to the engine, using the move code it has sent before by request.
H.G.M.: '... there is no way in WB protocol to request it from the engine ...' This is true also for UCI. I regard this to be a very big weakness, which I have avoided in SMIRF's TMCI protocol, which is unfortunately used by nobody else but your Smirf-O-Glot. Because engines using that new FEN and multi-variant approach still have to be written, why not to extend used protocols in this point? A GUI SHOULD be able to ask an engine for ALL possible moves. There is no need for an intelligence for this inside the GUI, because it would not be able to grow with upcoming new variants. H.G.M.: '... the O-i-h system ...' Nevertheless I would like to use following convention for stored PGN files: if there is only ONE castling move possible at all, it will be matched by ANY string starting with 'O'. The use of different letters e.g. M (Marshal) instead of C (Chancellor) or C (Cardinal) instead of A (Archbishop) should not be handled by the FEN string, but by a new to be defined PGN translation tag e.g. for embassy chess: [translate 'M=C C=A']. This is for showing traditionally translated piece letters (to be used on the GUI and PGN only, but NOT inside FEN). An exception to this is the use of J=Janus, having the special meaning of avoiding any Chancellor. Here it would be necessary to use also an additional tag [translate 'O-O=O-O-O O-O-O=O-O'] because of the unlucky old switched encoding decision inside of Janus. Thus a FEN string always should use those piece letters with a well defined, preferable traditional meaning: this moment I suggest J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R). ANY big piece type MENTIONED inside the INITIAL sent FEN might be used for promotions, additionally all the well known 8x8 and 10x8 standard pieces (but using J would disable C).
Sam Trenholme: ' ... looks like 8x10 Chess (Capablanca chess, etc.) is dead. ...' ... must be a zombie - you can't kill it. ;-)
Schoolbook. 8x10 chess with the rook + knight and bishop + knight pieces added. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]Sam, in fact not in this thread, I repeatedly have tried to investigate details of 'free castling', which still is not quite clear to me. Maybe caused by the fact, that my mother language is german, I am still interested in some clarifications: e.g. whether the King always has to move at least two steps or not, which would be the outermost target fields, whether the Rook always has to be placed beside of the castled King or not, and what would be the recommended notation e.g. O-c-O (?). Such missing information unfortunately prevented me from implementing related variants into SMIRF.
Thank you, George, for explanting. In SMIRF I already have implemented traditional, symmetric and modern castling, which is defined by the King's destination squares and thus also will work for randomized setups. But having randomized pieces, there might be Kings neighbored or near to Rooks, thus the given definiton of free castling will not be usable for such varying starting arrays, because it would ban any castling towards such blocked sides. That is a weakness, as I think. A more flexible definition therefore would be welcomed and moreover would less interfere with any claimed patents. How about following (which probably will be in conflict only marginally with some of those games using free castling): you can choose any square on the base row to be the King's castling target field except of the center and the border squares. The left squares are related to the left Rook, the right squares are related to the right Rook. A castling Rook will always be placed to the inner side of the castled King. Only still unmoved pieces will be allowed to castle. Castling is invalid under check or if the King will have to pass or reach a threatened square. All squares between King and its target (included) and between Rook and its target (included) have to be free from third pieces (therefore at least all squares between King and Rook have to be free). A clear notation would be O-c-O, with a central letter related to the King's target square column.
Derek: '... Please raise the material value of your archbishop within your CRC model? ...' If there would be a theoretical explanation of your value estimation beside of that statistical argument, I will think over my model. For me it is more interesting to have a well argued and preferred *SIMPLE* value derivation, even if that would not match all experiences. That is, because such thoughts also could influence the lay-out of other program parts e.g. like the detail evaluation. P.S.: Thus it would be best to present a short and convincing argument.
H.G.M.: '... But the point really is that Derek ASKS you to provide such a version of SMIRF to help him conduct an experiment he thinks is interesting. ...' Harm, I have released such special versions of SMIRF. But in the meantime SMIRF internally has separated the mobility parts from the static values and replaces it by combining a positional detail evaluation, where needed. This is not at all a mature approach, because I make and improve it merely by my own. Here I am not very interested in an epicycle theory kind approach, but more in Kepler's laws related approach, using clear and simple statements, which could be of practical use. To see statistical results might give a hint for researches, but I would like to see convincing explanations.
To Derek Nalls and H.G.M.: For your testing purposes I will provide new SMIRF releases. There will be three of them. The regular one will have the suffix -0, the one with the minor increased Archbishop basic exchange value will have the suffix -1, and the one more increased will have the suffix -2. SMIRF basic exchange values will be for 10x8: P=1.0000 S=3.0556 B=3.5972 R=5.4306 A=6.6528 / 7.5685 / 8.0278 C=8.4861 Q=9.0278 So I will be waiting for your testing results ...
25 comments displayed
Permalink to the exact comments currently displayed.