Re: [Scidvspc-devel] Fics score bar / sc_pos analyze

[C H. M. <han...@gm...>]

Hi Steve,

I havent looked into the UCI handshake flow implementation in scidvspc
currently, but won't it already provide most of the needed plumbing,
for the flow which I have mentioned, which should even avoid the crash
issue which you have mentioned.

Again given the end goal, I suggested the most flexible path. But
otherwise I do agree that if the scidlet covers a depth of 6 to 8 in
200 msecs, which it should in today's PCs, it should give a good
enough eval. Maybe it is even faster, havent used it recently.

On Sun, Jan 12, 2025 at 12:53 PM Steve A <ste...@gm...> wrote:
>
> Haha - Getting an eval on some random board is only possible this way really. Your idea could be done, but involves a whole new big API / class way complicating an already huge project.
>
> Using scidlet is a compromise, but sufficient, and quite a powerful feature too. Main problem is if engine.cpp segfaults, the whole app comes down now :(
>
> I've added some polish today. Getting close to finished.
>
> On Sun, Jan 12, 2025 at 12:52 PM C Hanish Menon <han...@gm...> wrote:
>>
>> Hi Steve,
>>
>> Ideal thing would be for the engine to run in the background and
>> refine the eval with time (as it goes deeper, like what the analysis
>> engine flow does). However if multiple games are being observed, and
>> we try to have multiple instances of the engine running wrt each game
>> being observed, that could turn out to be too much load.
>>
>> So instead having a SINGLE local engine running in the background and
>> inturn sending it
>>
>> a) a new board position (resulting from latest move wrt a game; if
>> multiple games are being followed and their evalbar updated using this
>> mechanism)
>>
>> b) a latest move (if only one game is being followed, here even
>> periodic update of the bar should be easily possible if reqd)
>>
>> and inturn using the eval from the local engine at the end of the
>> configured short time window, could still give a ok enough rough eval
>> especially for human games where deep twists/traps that can change the
>> eval may not be that common.
>>
>> NOTE: Havent looked at uci and xboard protocols for ages now, however
>> my vague memory seems to indicate the possibility of both the above
>> flows in one or the other.
>>
>> Also rather because engines like stockfish etal will normally reach
>> much deeper compared to the internal engine (scidlet?) within a given
>> time window, so making the engine to use, as well as
>> short-time-window-to-use configurable by the end user could be a
>> useful thing, with the default config being the internal engine.
>>
>> On Sat, Jan 11, 2025 at 11:18 AM Steve A <ste...@gm...> wrote:
>> >
>> > I've realised we can use the scid's never-used inbuilt chess engine to add a quick score to fics observed games! :) It's currently given a 200 millisecond run before we update the observed board. (Is this optimal?)
>> >
>> > But I was of the opinion, ages ago we had a problem with "sc_pos analyze" segfaulting occasionally. I may have fixed it sometime... but am uncertain of it's status. (engine.cpp)
>> >
>> > Maybe the problem was only at near mate positions with low piece count.
>> > So, testing is in order i guess... Hmmm.
>> >
>> > Cheers.
>>
>>
>>
>> --
>> Keep ;-)
>> HanishKVC



-- 
Keep ;-)
HanishKVC