TalkChess.com

Tarrasch doesn't support engine matches so no worries there.

Laskos wrote: ↑Thu May 09, 2019 9:08 pm

mjlef wrote: ↑Thu May 09, 2019 8:02 pm

Gabor Szots wrote: ↑Thu May 09, 2019 9:58 am

Ovyron wrote: ↑Wed May 08, 2019 10:48 pm

Gabor Szots wrote: ↑Tue May 07, 2019 8:32 amWhere do I set MultiPV under the Shredder GUI?

It seems that you can't set MutiPV under the Shredder GUI (it hides the setting in engine options, and doesn't allow to set it directly; I had to make my own compile of McCain that calls it "MultiPW" just to fix this.)

The best you can do is using the F6 Key to increase MutiPV lines by one, and the F5 Key to decrease them by one, but it's impossible to play MultiPV games in the Shredder GUI (as it defaults to 1 in play mode.)

Thank you for your reply. I edited my Komodo eng file to include a line MultiPV=6, only I don't know whether it has an effect.

MultiPV is used by most people to see multiple lines. What they do not realize is the higher MultiPV is set, the worse the overall play since it takes longer in alpha-beta programs to find multiple bes moves. You have to basically do multiple searches excluding the the previously discovered lines, an that slows things down. In K MCTS, there is almost no cost to MultiPV, so you still get the best lines, but playing the best line is still as strong.

Different GUIs handle this differently in terms of what you can set in the engine in different modes.

Mark

I don't totally understand. Isn't it just a "partial MultiPV"? The second, third etc. lines being progressively less explored? Am I wrong? And isn't this "partial MultiPV" doable with AB engines in a similar fashion using the regular search for the best move?

it is a bit complex, but I will try to explain. You need to search either by aspirating or with open windows to get the score of the best move. Then you start a new search that skips that move, and should find the second best move. You can aspirat it to try and save time, but no matter what you do, present programs which can have very selective searches, will still sometimes find the second search comes up with a higher scoring move than the first "best" root move. So most seem to sort them by score, and ignore that the search was not stable. You would think the second search would take a significantly less time, but it often does not. I believe this this has to do with LMR and pruning. The first move is reduced and pruned less than the second and higher. So the search to find the second best move takes nearly as long as the first search. But it depends on the moves and what they lead to. Once you get to the bad moves that say lose material, it goes a lot faster.

If you means does an MCTS MultiPV search had varying quantity or tree and quality of search, yes it does. But those searches are based on win probabilities, and so should be searched less deeply or widely. I think when people use MultiPV they want to know what are the good lines and are less concerned with bad lines.

mjlef wrote: ↑Fri May 10, 2019 3:17 am

Laskos wrote: ↑Thu May 09, 2019 9:08 pm

mjlef wrote: ↑Thu May 09, 2019 8:02 pm

Gabor Szots wrote: ↑Thu May 09, 2019 9:58 am

Ovyron wrote: ↑Wed May 08, 2019 10:48 pm

Gabor Szots wrote: ↑Tue May 07, 2019 8:32 amWhere do I set MultiPV under the Shredder GUI?

It seems that you can't set MutiPV under the Shredder GUI (it hides the setting in engine options, and doesn't allow to set it directly; I had to make my own compile of McCain that calls it "MultiPW" just to fix this.)

The best you can do is using the F6 Key to increase MutiPV lines by one, and the F5 Key to decrease them by one, but it's impossible to play MultiPV games in the Shredder GUI (as it defaults to 1 in play mode.)

Thank you for your reply. I edited my Komodo eng file to include a line MultiPV=6, only I don't know whether it has an effect.

MultiPV is used by most people to see multiple lines. What they do not realize is the higher MultiPV is set, the worse the overall play since it takes longer in alpha-beta programs to find multiple bes moves. You have to basically do multiple searches excluding the the previously discovered lines, an that slows things down. In K MCTS, there is almost no cost to MultiPV, so you still get the best lines, but playing the best line is still as strong.

Different GUIs handle this differently in terms of what you can set in the engine in different modes.

Mark

I don't totally understand. Isn't it just a "partial MultiPV"? The second, third etc. lines being progressively less explored? Am I wrong? And isn't this "partial MultiPV" doable with AB engines in a similar fashion using the regular search for the best move?

it is a bit complex, but I will try to explain. You need to search either by aspirating or with open windows to get the score of the best move. Then you start a new search that skips that move, and should find the second best move. You can aspirat it to try and save time, but no matter what you do, present programs which can have very selective searches, will still sometimes find the second search comes up with a higher scoring move than the first "best" root move. So most seem to sort them by score, and ignore that the search was not stable. You would think the second search would take a significantly less time, but it often does not. I believe this this has to do with LMR and pruning. The first move is reduced and pruned less than the second and higher. So the search to find the second best move takes nearly as long as the first search. But it depends on the moves and what they lead to. Once you get to the bad moves that say lose material, it goes a lot faster.

If you means does an MCTS MultiPV search had varying quantity or tree and quality of search, yes it does. But those searches are based on win probabilities, and so should be searched less deeply or widely. I think when people use MultiPV they want to know what are the good lines and are less concerned with bad lines.

I think that regardless of pruning and reducing, with MultiPV each move will on average take nearly as long as the one before. If there are 30 moves, tossing out one and starting over from scratch, needing an accurate score for the best move, should take 97% of the time to search 29 moves, probably more since the best move takes way more than its proper share of time. With MCTS, as long as there are alternate moves that are fairly close to the best move in score, they will get fairly close to equal search time so I think the MultiPV is only slightly inferior in quality when it matters, with no slowdown.

Mark
[/quote]
If you means does an MCTS MultiPV search had varying quantity or tree and quality of search, yes it does. But those searches are based on win probabilities, and so should be searched less deeply or widely. I think when people use MultiPV they want to know what are the good lines and are less concerned with bad lines.
[/quote]

I look at it a different way.

When using Multi-PV for opening analysis - lines I want to play in Over-The-Board tournaments, I use it often to see how 'narrow the path' is for my opponent to keep from getting a bad position. Stringing together a series of moves when there are more options to 'go wrong' - even if we are just talking, say, .25 of a pawn here and there can result in end positions where your opponent can go wrong.

When you use it this way, you can more easily chose 2nd, 3rd, 4th... 'best' options (often within a narrow evaluation range of course) for your side, if you help move the analysis along manually to see where they might give your opponent more chances to 'go wrong'. Human chess is a 'game of mistakes'.

I wish engine programmers could somehow use this line of thought for opening preparation. Perhaps it would be more of a GUI solution...I don't know. But that strikes me as a benefit to the user of engines for opening analysis that is largely untapped. Right now it is a manual process.

It does strike me that the programmers might be able to tweak MCTS for opening analysis of this nature.

leavenfish wrote: ↑Sat May 11, 2019 8:29 pm Mark

If you means does an MCTS MultiPV search had varying quantity or tree and quality of search, yes it does. But those searches are based on win probabilities, and so should be searched less deeply or widely. I think when people use MultiPV they want to know what are the good lines and are less concerned with bad lines.
[/quote]

I look at it a different way.

When using Multi-PV for opening analysis - lines I want to play in Over-The-Board tournaments, I use it often to see how 'narrow the path' is for my opponent to keep from getting a bad position. Stringing together a series of moves when there are more options to 'go wrong' - even if we are just talking, say, .25 of a pawn here and there can result in end positions where your opponent can go wrong.

When you use it this way, you can more easily chose 2nd, 3rd, 4th... 'best' options (often within a narrow evaluation range of course) for your side, if you help move the analysis along manually to see where they might give your opponent more chances to 'go wrong'. Human chess is a 'game of mistakes'.

I wish engine programmers could somehow use this line of thought for opening preparation. Perhaps it would be more of a GUI solution...I don't know. But that strikes me as a benefit to the user of engines for opening analysis that is largely untapped. Right now it is a manual process.

It does strike me that the programmers might be able to tweak MCTS for opening analysis of this nature.
[/quote]

The scores reported by an MCTS engine like Komodo MCTS already reflect the possiblility of the opponent going wrong in plausible ways. Maybe it doesn't do it the same way you would, but at least to a significant degree it does what you want.

lkaufman wrote: ↑Sat May 11, 2019 11:48 pm ~snip~

The scores reported by an MCTS engine like Komodo MCTS already reflect the possiblility of the opponent going wrong in plausible ways. Maybe it doesn't do it the same way you would, but at least to a significant degree it does what you want.

That's really interesting. If this is possible with MCTS, have you considered adding a mode to Komodo which adds more weight to the possibility of the opponent going wrong, which would allow people to find trappy lines in analysis?

konsolas wrote: ↑Sun May 12, 2019 6:23 pm

lkaufman wrote: ↑Sat May 11, 2019 11:48 pm ~snip~

The scores reported by an MCTS engine like Komodo MCTS already reflect the possiblility of the opponent going wrong in plausible ways. Maybe it doesn't do it the same way you would, but at least to a significant degree it does what you want.

That's really interesting. If this is possible with MCTS, have you considered adding a mode to Komodo which adds more weight to the possibility of the opponent going wrong, which would allow people to find trappy lines in analysis?

If regular Komodo did that, it would just become a much weaker cousin of Komodo MCTS. That's the fundamental difference between standard ("Alpha-Beta") engines and MCTS engines; standard ones assume that the opponent will always play the move the engine considers best, whereas MCTS assumes that all reasonable moves have some chance of being chosen. Komodo MCTS (and Lc0 and spinoffs if you have suitable GPU) are the engines you should use.

I have a question. If I purchase chessbase Komodo 12 (or latest chessbase version)
then can I get the newest version of the engine?

Basically I want the newest Komodo with the latest chessbase GUI.

h1a8 wrote: ↑Mon May 13, 2019 2:56 am I have a question. If I purchase chessbase Komodo 12 (or latest chessbase version)
then can I get the newest version of the engine?

Basically I want the newest Komodo with the latest chessbase GUI.

Then just wait a few days until Komodo 13 goes on sale on the chessbase website. They haven't announced anything yet, but in the past they always release within a couple weeks of any new integer version of Komodo on our website.

lkaufman wrote: ↑Mon May 13, 2019 4:32 am

h1a8 wrote: ↑Mon May 13, 2019 2:56 am I have a question. If I purchase chessbase Komodo 12 (or latest chessbase version)
then can I get the newest version of the engine?

Basically I want the newest Komodo with the latest chessbase GUI.

Then just wait a few days until Komodo 13 goes on sale on the chessbase website. They haven't announced anything yet, but in the past they always release within a couple weeks of any new integer version of Komodo on our website.

Ok thanks. And if I get Komodo 13 then do I get a year of engine updates? Or just all updates from 13 and prior to version 14 ?