Exploring an unusual evaluation function

[Gerd Isenberg]

Hi Dave,

may be you are aware that early programs like Barricelli's Freedom and Marsland's Wita used mobility aka ratio of computer's moves / opponent moves as evaluation term, and Papa the logarithm of that product to form an entropy.

If you look to current strong alpha-beta based engines, evaluation is still dominated by material balance, but king safety and passed pawn terms may exceed the value of multiple pawns. Square control and (weighted) mobility are important terms as well.

How did Delta and Advance evaluate positions?

Best Regards,
Gerd

[omnivorist]

Hi Dave,

may be you are aware that early programs like Barricelli's Freedom and Marsland's Wita used mobility aka ratio of computer's moves / opponent moves as evaluation term, and Papa the logarithm of that product to form an entropy.

I wasn’t aware of that Gerd. Thanks so much for your post - really interesting.
If I continue my investigations I imagine I might continue to concentrate on measures that do not rely on explicit chess knowledge like pawn structure.

It would be great to research the early history of chess engines. Are you aware of any sources of information ?

[omnivorist]

It would be great to research the early history of chess engines. Are you aware of any sources of information ?

Hi Gerd, I replied before looking at the links you provided. I will look at these and explore the CPW site. It looks like it might be the answer to my question.

[omnivorist]

Gerd Isenberg has pointed out that my idea is by no means a new one,
I’m grateful for that. It might save a lot of time.
All the same. Writing my engine has wetted my appetite for chess programming,

[Gerd Isenberg]

Due to your initial thanks in Advance (Adv<thanks>ance), I wrongly assumed you are this David Wilson, author of Advance and Delta - starting a comeback after a long break from chess programming

Yes, the idea using mobility in evaluation is old, also note Slater's Statistics for the Chess Computer and the Factor of Mobility and the discussion with Alan Turing.

[YUFe]

I hope my musings might inspire others to look for a 'sweet spot' in the eval/search balance.

I am afraid that we can be certain, that you are nowhere near it, from a purely theoretic approach looking at the compute balance of move generation and tracking to evaluation. Think about how much less time you would have to spend per individual move to get another level of moves. Then think about how the compute relation of eval() to generate_next_legal move() would have to change to make it that much faster. Then guess if N+1/N dept loosing much of the smartness can possibly be worth it? I think this one does not take more than common sense.

If your evaluation function would take a big portion of the per move compute, then you could optimize by having two different eval() or a two staged eval() with early return. The idea being to discard fail moves as soon as possible.
When searching you do not look into plys that are either too good (fail high / the other would have to be stupid) or too bad (fail low / you would have to be stupid). It might be possible to identify and discard some of these quickly and early / with reduced compute.
Then only for the leaves or to discard more you use the smart but expensive NN inference.

You are right, my thinking and aesthetic preference is kind of the opposite to yours on this one.
My thinking was more like: Why do you have to search when the information is already all there in a condensed form?
The move generation is in a way adding the rules of the game to the board setting, but it isn't actually generating additional information.
All you need to know is the rules, where the pieces are and who's turn it is.
You do not need to eliminate noise by filtering the input.

[omnivorist]

I hope my musings might inspire others to look for a 'sweet spot' in the eval/search balance.

You are right, my thinking and aesthetic preference is kind of the opposite to yours on this one.
My thinking was more like: Why do you have to search when the information is already all there in a condensed form?
The move generation is in a way adding the rules of the game to the board setting, but it isn't actually generating additional information.
All you need to know is the rules, where the pieces are and who's turn it is.
You do not need to eliminate noise by filtering the input.

You make a very good point and I have to agree with you. Experience of writing my own engine has made clear the impossibility of buying significant extra search depth with savings in eval - something that you suggest might have been apparent with common sense. Maybe. But choosing to base eval purely on mobility was about more than simply saving compute. I was genuinely intrigued by the possibility that mobility might encapsulate an essential and valuable measure of the position.

And no I am not the David Wilson, author of Advance but - as will now be apparent - a newcomer to chess programming with an interest in the subject. I spent some 25 years in the semiconductor and high-performance computer industries writing design automation, simulation and modelling software in C and C++. I am semi-retired these days with the time to follow-up long-standing questions like this.

[omnivorist]

Due to your initial thanks in Advance (Adv<thanks>ance), I wrongly assumed you are this David Wilson, author of Advance and Delta - starting a comeback after a long break from chess programming

Sorry but no. I’m a newcomer to the field unaware of both my namesake and his work. I am retired these days, after 25+ years in the semiconductor and high-performance computer industries and a more recent spell as an architect. Writing a chess engine has been a way of re-acquainting myself with programming as well as exploring my long held ‘hunch’ about an eval based on mobility alone - a notion that has been politely and patiently shown to be of limited value. But hey - if we don’t ask the questions what’s the hope of finding an answer.

[brianr]

Many years ago some work was done on basing piece values on mobility.
In particular Reinhard Scharnagl (passed away in 2015) used this approach with his engine SMIRF.
Information is not easy to find these days, but the Wayback machine has quite a bit:
https://web.archive.org/web/20060507091 ... tz1_e.html
Many of the links work (and there are other later snapshots).

I think his approach was intended to be applicable to just about any sort of chess variant.

There is/was also a GUI and there are some relatively current efforts, such as:
https://github.com/rchastain/smirf-u

[omnivorist]

Many years ago some work was done on basing piece values on mobility.
In particular Reinhard Scharnagl (passed away in 2015) used this approach with his engine SMIRF.
Information is not easy to find these days, but the Wayback machine has quite a bit:
https://web.archive.org/web/20060507091 ... tz1_e.html
Many of the links work (and there are other later snapshots).

There is/was also a GUI and there are some relatively current efforts, such as:
https://github.com/rchastain/smirf-u

Thanks - I’ll take a look at that, even though my explorations have reached something of a dead end. I hadn’t realised when I started out that I was attempting to resurrect ideas that had first been discussed in 1950! As I was only 1 at the time, I guess I can be excused.