incorrect MPV list in SCID about berserk HOT 10 CLOSED

Please send me the FEN of the position in question.

It is important to note Berserk will output what it is thinking and not necessarily the best move. During a certain depth Berserk will output moves that hit the bounds of its current aspiration windows.

I'm not sure what other engines you're comparing it too, but this is fairly standard AFAIK once a certain time has been eclipsed (allowing the user to see the engine is still calculating rather than frozen).

from berserk.

r1bq1rk1/ppp2pp1/2n2n1p/1Bp1p3/4P3/2NP1N2/PPP2PPP/R2Q1RK1 b - - 0 9

btw this happens with all FENs .. i recorded a small screencast of Berserk and Pedone, showing their different listing .. when using mpv many engines show the next mpv listing in SCID after all mpv are calculated .. other engines (like Ethereal) show each mpv eval directly after it's calculated .. here Berserk behaves strange and unlogical, it must be a bug ..

from berserk.

i would think that "play what it's thinking" when time's up can often give a suboptimal result .. why does Berserk not show the best move of the last finished depth ? I have no insight in engine coding, i'm just a user ..

from berserk.

Berserk prints what it's thinking, but that's not the "bestmove" that will necessarily be printed when a non-infinite search completes. In order for the "bestmove" to be changed, the depth must be fully completed, and a move must be found within the determined aspiration window.

I will look at this closer to see if I can determine why Berserk is printing such a short PV regardless.

from berserk.

The reason for this short output is due to a reset of the PV table at the start of the Negamax method. (See here)[https://github.com/jhonnold/berserk/blob/main/src/search.c#L251]. Then, most likely a cutoff is occurring which then causes a short PV to be returned. In many cases no bestmove has been even added to the PV table, but Berserk force prints whatever is in the first slot of the PV table. (See here)[https://github.com/jhonnold/berserk/blob/main/src/search.c#L747]. This second line may be the reason for issues with SCID?

Either way, I checked 3 other engines to validate that short pv printing isn't uncommon:

• Ethereal Go Depth 30
• Weiss Go Depth 30
• SF Go Depth 30

You can see in the outputs for all 3 of those engines, short PVs are printed.

from berserk.

it's not only about "short pv printing" .. it's mainly about the fact that at each depth Berserk shows a list where the move-on-top is of the next (!?) depth .. almost no other engine does that .. the ones you tested differ in the way they show their mpv lists while increasing depth .. this short video shows the SCID output of all your 3 engines concerning my FEN, plus Berserk at the end :

Ethereal and SF build / refresh their list during calculation, while Weiss shows the whole list of any next depth as soon as all mpv moves are calculated.

your pastebin listings are not a good test, you should test in SCID, because this program gives the wrong listing - whatever the cause ..

from berserk.

For future reference this issue is not related to the printing of a short pv in general, but the printing of a short pv in the case of MultiPV being enabled and hanging for a long time.

I know why this is the case and implemented this way due to trying to support another program called nibbler. I will work to support both SCID output and nibbler together. A 4.5.2 release that addresses this will be around eventually.

from berserk.

OK .. i know nibbler - it's is made for Leela but also supports normal A/B UCI engines, although this support is limited by design -- some weeks ago i communicated about this with the creator .. SCID might have a different protocol / handling of the UCI info lines, but many engines feed their info lines properly to SCID and so should Berserk i think .. btw. all (my) Ethereal versions have slight problems with their MPV list in SCID : the top-N moves are (sometimes) not properly sorted by eval, which is annoying, while most other engines do ..

from berserk.

This should no longer be an issue on the main branch.

from berserk.

yes, it's solved !
i compiled the main code by git clone and i got a (avx2) binary called v5.0.0-dev which has a different byte size then (the) previous v5.0.0-dev, so it's different, and indeed in SCID the concerning issue does NOT happen !
Thanks !

from berserk.