Amstaff wrote: ↑Sat May 08, 2021 12:26 pm
Hello I'm sorry but I do not see how to turn on MultiPV in the engine options for Komodo Dragon 2.
Not in UCI- options of most of the GUIs except as for analysis mode, there most GUIs offer a special command for more output- lines and primary variants, but not as for game- playing.
One exception is Arena,that has for all UCI- engines installed an option in engine- settings named MultiPV, in Shredder- GUI you can add manually a line
MultiPV=x
in eng.- file, x for the number of primary lines computed in analysis as well as in game playing mode.
Pity that doesn't work on the other hand e.gin Fritz- .uci- file regards
The same goes for Banksia GUI
"Good decisions come from experience, and experience comes from bad decisions."
__________________________________________________________________
Ted Summers
Krzysztof Grzelak wrote: ↑Sat May 08, 2021 9:17 am
One of the worst versions I've ever seen. Gentlemen from Komodo, think about whether you know how to program. Because in my opinion not. He will find another job and forget about programming.
Could you precisely articulate what the problem is? I'm a user and didn't notice anything problematic, so I'm interested in what you found out.
Amstaff wrote: ↑Sat May 08, 2021 12:26 pm
Hello I'm sorry but I do not see how to turn on MultiPV in the engine options for Komodo Dragon 2.
Thanks for any info.
Gerald
[d]r3k2r/bpp2ppp/p2p4/P7/2B1P1n1/2P2Nq1/1P3P2/R1BQ1RK1 w kq - 4 17
This position is evaluated -0.68/32 with 17.h1. If I make the move 17.h1 the position is quickly evaluated -4. When I go back to the above position (I've kept the engine running) then sometimes the position is evaluated -4, sometimes -0.8. I've never seen such strange engine behavior. Is this normal?
Edit: I did some further tests and somehow feel that Dragon 2 acts like a random number generator around this position. Can anyone confirm this?
KLc wrote: ↑Sat May 08, 2021 4:22 pm
Okay, I noticed something strange with Dragon 2.
[d]r3k2r/bpp2ppp/p2p4/P7/2B1P1n1/2P2Nq1/1P3P2/R1BQ1RK1 w kq - 4 17
This position is evaluated -0.68/32 with 17.h1. If I make the move 17.h1 the position is quickly evaluated -4. When I go back to the above position (I've kept the engine running) then sometimes the position is evaluated -4, sometimes -0.8. I've never seen such strange engine behavior. Is this normal?
Edit: I did some further tests and somehow feel that Dragon 2 acts like a random number generator around this position. Can anyone confirm this?
Ponder=false
Use Syzygy=false
Threads=2
OwnBook=false
Hash=512
Edit: OK, exactly the same erratic behavior with Dragon (1).
I set my laptop to use just two threads to duplicate your settings, and Dragon 2 shows the score dropping from about a pawn down to about 4 pawns down in the given position somewhere between 18 and 23 ply, and keeping it beyond your 32 ply. MP search is nonreproducible on all modern programs, so some variation is expected unless Threads=1, but other than this I can't explain why your computer doesn't see the win quickly. If you go back and forth between positions you need to clear hash if you hope to get the same results each time, but with MP even that doesn't insure it.
As an OTB tournament player of 40 years now (and a lot of online human play of late!), for preparation of lines to play OTB (or non-engine online play), the primary reason you look to an engine for 2nd, 3rd, 4th ‘best moves’ is largely because:
1- The move will simply give you an easier position to play or one which better suits your style.
2- The move will give your opponent more difficult decisions to make in the next few moves and thus end up giving you MORE chances to get an even better position than if you had chosen the ‘best’ engine choice.
It is ‘choice’ in chess - as one works his way from move 1 thru to the end of the game - which gives each side the opportunity to go wrong.
The more and more difficult choices you set your opponent, the more likely he is to fumble and give you positions even more favorable than if you played a +.50 move over a +.25 or +.15 to begin with because the engine assumes ‘best play’.
That is why I’ve always been fascinated with MCTS….but I’ve never been able to wrap my head around or visualize how the output comes into being. And of course, the PV had to be pretty accurate too, which is why Dragon 2 looks especially promising!.
The best way I can think to represent this is as a sort of ‘tree’ where you regard your opponents choices over the next few moves in response to which move you chose in a position.
A tree where the top engine choices give you a bunch of GREEN (good) branches or RED (bad) branches.
The +.50 best engine move might show a lot of green - fairly easy future choices for your opponent so the best you are likely to come out with is a +.50 position in the next few moves, but the +.25 or +.15 moves show perhaps progressively more red branches among reasonable looking (non- outright blunder) responses emanating out from them – more perfectly reasonable looking choices/pitfalls the opponent could take which could land you with an outcome greater than if you had simply chosen the +.50 to begin with. Think of it is ‘Gametheory’ for Chess analysis.
KLc wrote: ↑Sat May 08, 2021 2:48 pm
Could you precisely articulate what the problem is? I'm a user and didn't notice anything problematic, so I'm interested in what you found out.
KLc wrote: ↑Sat May 08, 2021 2:48 pm
Could you precisely articulate what the problem is? I'm a user and didn't notice anything problematic, so I'm interested in what you found out.
Your result of minus 52 elo for Dragon 2 vs. Fat Fritz 2 (basically Stockfish 13 with a different but comparable strength net) is roughly in line with what the rating lists should show based on the 10-12 elo gain for Dragon 2. We only claim to be equal to Stockfish 13 if either of two conditions applies: 1. you are playing FRC (chess 960) or 2. you are setting them both to display five or more lines of analysis (MultiPV).
