Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments by rescharn

LatestLater Reverse Order EarlierEarliest
Piece Values[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Wed, Jun 18, 2008 10:53 AM UTC:
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 ...

Reinhard Scharnagl wrote on Sun, May 25, 2008 10:39 AM UTC:
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.

Reinhard Scharnagl wrote on Tue, May 13, 2008 07:05 PM UTC:
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]

Reinhard Scharnagl wrote on Tue, May 13, 2008 03:50 PM UTC:
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.

[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Sat, May 10, 2008 10:21 PM UTC:
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.

Piece Values[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Sun, May 4, 2008 07:09 AM UTC:
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.

Reinhard Scharnagl wrote on Sat, May 3, 2008 08:06 PM UTC:
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.

Reinhard Scharnagl wrote on Sat, May 3, 2008 06:43 PM UTC:
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.

Vyrémorn Chess. Large variant on two overlapping square boards. (Cells: 132) [All Comments] [Add Comment or Rating]
Reinhard Scharnagl wrote on Sat, May 3, 2008 05:54 PM UTC:
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.

Piece Values[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Sat, May 3, 2008 05:24 PM UTC:
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 ...

Reinhard Scharnagl wrote on Sat, May 3, 2008 05:00 PM UTC:
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.

Reinhard Scharnagl wrote on Sat, May 3, 2008 04:35 PM UTC:
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.

Reinhard Scharnagl wrote on Sat, May 3, 2008 03:57 PM UTC:
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

Reinhard Scharnagl wrote on Sat, May 3, 2008 12:17 PM UTC:
You will find a (hopefully) actual table of several piece value sets at:
http://www.10x8.net/Compu/schachveri1_e.html

Reinhard Scharnagl wrote on Sat, May 3, 2008 10:17 AM UTC:
Well, Harm, you know, that I failed in using 10x8 Winboard GUIs, so I
discontinued trying that.

Reinhard Scharnagl wrote on Sat, May 3, 2008 09:18 AM UTC:
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.

Reinhard Scharnagl wrote on Fri, May 2, 2008 08:32 PM UTC:
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.

Reinhard Scharnagl wrote on Fri, May 2, 2008 06:20 PM UTC:
Derek, you will receive versions compiled using complete piece values.

Reinhard Scharnagl wrote on Fri, May 2, 2008 05:48 PM UTC:
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

Reinhard Scharnagl wrote on Fri, May 2, 2008 04:46 PM UTC:
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.

Reinhard Scharnagl wrote on Fri, May 2, 2008 03:57 PM UTC:
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

Reinhard Scharnagl wrote on Fri, May 2, 2008 02:36 PM UTC:
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.

Reinhard Scharnagl wrote on Thu, May 1, 2008 10:21 AM UTC:
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.

Reinhard Scharnagl wrote on Sun, Apr 27, 2008 07:41 PM UTC:
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.

Aberg variation of Capablanca's Chess. Different setup and castling rules. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]
Reinhard Scharnagl wrote on Sat, Apr 26, 2008 06:07 AM UTC:
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.

25 comments displayed

LatestLater Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.