1 Million Training Positions for Texel Tuning

[Whiskers]

I’m sorry if we’re talking past each other lol. It’s the “convert fens to an array of objects” part that seems like it would take the longest. After all, don’t you still need to perform calculations for say mobility?

Ah, ok.

So, when I talk about reading in the FENs and creating an array of objects, I mean we read in each fen, and extract the "features" from that position, as well as record the outcome, and store this in an a position object. This is what that looks like in my code:

Code: Select all

type TuningPosition struct {
	Features []Feature
	Outcome  float64
}

That feature vector (read: list) is what we use to compute the evaluation of each position, by taking the dot product between it and the weight vector.

Now, you're correct, it takes time to extract the features from each position. But (1) the important thing is, is that this done only once, at the beginning of the program, and from that point onward you have a very compact representation of all the FENs which allows you to quickly compute the evaluation. And (2) this extraction of features actually doesn't take that long. When I start up my tuner it takes about 20s to convert the FEN dataset into an array of TuningPosition objects. And after that we never have to worry about feature extraction again.

Oh, I finally get it. For some reason I got it into my head that you extract the features from each position each iteration. I'll try it soon enough!

[JoAnnP38]

I’m sorry if we’re talking past each other lol. It’s the “convert fens to an array of objects” part that seems like it would take the longest. After all, don’t you still need to perform calculations for say mobility?

Ah, ok.

So, when I talk about reading in the FENs and creating an array of objects, I mean we read in each fen, and extract the "features" from that position, as well as record the outcome, and store this in an a position object. This is what that looks like in my code:

Code: Select all

type TuningPosition struct {
	Features []Feature
	Outcome  float64
}

That feature vector (read: list) is what we use to compute the evaluation of each position, by taking the dot product between it and the weight vector.

Now, you're correct, it takes time to extract the features from each position. But (1) the important thing is, is that this done only once, at the beginning of the program, and from that point onward you have a very compact representation of all the FENs which allows you to quickly compute the evaluation. And (2) this extraction of features actually doesn't take that long. When I start up my tuner it takes about 20s to convert the FEN dataset into an array of TuningPosition objects. And after that we never have to worry about feature extraction again.

Oh, I finally get it. For some reason I got it into my head that you extract the features from each position each iteration. I'll try it soon enough!

Great discussions guys. I admit I wasn't following at all at first. But now I see the light. Unfortunately, I really need to refactor my evaluation so that it directly uses the feature vector to calculate the evaluation in-game or else it would be a maintenance nightmare to do this strictly in the tuning utility. Every time the evaluation might change you would also have to update the utility. But if the evaluation created the feature vector and then multiplied it times the weights to produce the evaluation value, then I could reuse the feature vector in the turning utility, and it would be whenever the evaluation was updated automatically. It's a good thing I'm already porting Pedantic to C++ so I can make this change at the same time.

[Dann Corbit]

The one million positions with search scores and some statistics.
If I have several games in my database, I will have a wins, draws and losses total.
Obviously, if the position is a forced mate, then the stats are not valuable.

[Dann Corbit]

There are 24,709 decided positions (abs(score) of 10,000 or above)
There are 159,870 positions where one side is up a full piece (score between 300 and 10,000
There are 108,500 positions with a score between 150 and 300 centipawns in absolute value
There are 709,276 positions with abs(score) between 0 and 150

[JoAnnP38]

The first time I wrote my optimization routine based on the Texel method, I just reused my evaluation function as-is to calculate qScore in the sigmoid function. However, since I was also using the local search outlined on the Chess Programming Wiki my code was really molasses slow. It is especially problematic since I am trying to process 2+ million positions. So, now that I am rewriting this due to programmer error (see my developer's log if you want to laugh at my misfortune) I am going to redesign it to use extract the position features and then calculate the qScore using the dot product of two vectors (features * weights). Does anyone have any thoughts on the System.Numerics library in .NET? I know that it provides some basic functions that support vectors and simple operations (like multiply and add) and will use hardware SIMD functionality if present. However, is it worth starting there or should I be looking at using the Sse2/3 Intrinsics directly?

[lithander]

https://github.com/lithander/Leorik/blo ... reTuner.cs

...has some out-commented SIMD code in the bottom of the file. But leveraging multi-threading through the Parallel API was more valuable for me.