30: Test_DontPlayMe (1250) 2017-05-23 00:59 (2017-05-23 06:32に編集)

Promotion to Knight seems to occur in Chess in about 1.5% of the cases, mostly to promote with check. I can imagine that in Shogi deferral occurs way more, for two reasons:
1)The promoted version is never wildly stronger than the unpromoted
2) If you defer, you can always promote later. If you promote to a Knight in Chess, you are stuck with it.

I have no Mac, so I cannot test it. On Linux it seems to work. You have to move the mouse pointer away from the promotion zone, though. In the forward direction it would not work. This is what the message "Pull Pawn backwards to underpromote", which appears above the board, means. I guess Shogi would also need a different message there, as it isn't only Pawns that underpromote.

The 'sweep promotion' method was really designed for Chess; for Shogi the popup dialog is probably more convenient. One problem was that in Shogi you do not know yet whether a move will be a promotion when the piece is 'picked up' in a drag-drop move. For Chess you know that Pawns picked up on the 7th rank will promote (only and always). So in Shogi the promotion procedure can only be invoked after the destination square is known, and in a drag-drop move you would already have released the mouse button at that point. So it only works on click-click moves there, where the button press selects the destination square, and the release can then be used to select the piece and complete the move entry.

In the Windows Shogi-variants package that I host I have configured WinBoard to use the popup menu. I guess it is a mistake that the the XBoard OSX App is configured differently.

29: kmullin (1100) 2017-05-22 10:27 (2017-05-22 10:29に編集)

Ok, i can get it work with the 'Almost Always Queen (Detour Under-Promote)' box unchecked. Thanks. It didnt occur to me that this option would affect shogi behavior.

However, i cant get the mouse behavior you describe (which i read elsewhere online) on my version of Xboard with a trackpad on my Macbook Pro 2012 when the 'Almost Always Queen (Detour Under-Promote)' box is checked.

I guess that unpromotion is more common in shogi than in western chess particularly in the case with 銀 silvers and also 桂馬 knights. It's common enough in mate sequences and there's the well-known example of an unpromoted silver in the 相掛かり棒銀 Double Wing Climbing Silver joseki.

28: Test_DontPlayMe (1250) 2017-05-20 19:14

XBoard has two modes for controlling promotion, which are selected by the 'Almost always promote to Queen' checkbox in the General Optiones menu. I agree that for Shogi this is a bit of a confusing name, and in fact for Chess variants that do not feature a Queen too. With this option turned off, a move that can potentially promote will cause a popup dialog to appear with buttons for each possible promotion choice. (In Shogi the choices would be limited to 'Promote' and 'Defer'.)

When the checkbox is ticked, XBoard assumes there is a default choice ('Queen' in Chess, 'Promote' in Shogi), and would assume that is what you want, without asking. Unless you click the destination square of the move in a special way: press the (left) button, then move the mouse vertically, and only then release the button. While you sweep the mouse with the button pressed, the piece displayed in the destination square will cycle through all possible choices (in Shogi only the original and promoted version), and you simply release the button when you see the desired piece. This is on average faster, as under-promotion / deferral occurs much less frequently than promotion to the strongest piece. And even if you want to defer, the tiny extra mouse motion you need is faster than moving the mouse to the desired button of a popup dialog after you made a static click on the destination square.

27: kmullin (1100) 2017-05-19 23:16 (2017-05-19 23:58に編集)

I now think that the best general way to use engines on a Mac is to use Shogidokoro 将棋所 with Wine/mono. Compiling the various engines is a hassle. (Most [all?] engine authors create binaries for Windows only.) Plus, it's not guaranteed that you will be able to compile the code anyway since typically the documentation for them is very poor (they just write the code) and only in Japanese. 

And, in fact, getting some engines to work at all can be complicated since you have to get files from different places (different engines can often use the same evaluation function or book [joseki] file) and figure out which binary works with your CPU (e.g. i dont think i cant run Nozomi on my hardware). So, figuring out compiling them is another layer of complication.

Anyway, with a new computer competition completed, you can now run the elmo evaluation function and book with YaneuraOu やねうら王 (early 2017 version) to give you possibly the strongest engine today. Elmo was undefeated in the competition beating even Ponanza multiple times. So, it will handily beat Gikou 技巧 and Apery (mentioned earlier on this topic thread) as well as the even stronger Gikou 2. There's also the modified eloqhappa (elmo-Qhapaq) which is the elmo evaluation function with the Qhapaq learning technique added. However, it's not clear that eloqhappa is actually an improvement on elmo. But, they may give you different best moves for the same positions? It's also possible to use elmo with Silent Majority instead of YaneuraOu, but YaneuraOu seems to be stronger than Silent Majority with the elmo eval. And, i was able to get all of these working with Shogidokoro on a Mac as well as many others (Apery Twig[大樹の枝]/WCSC26/Ukamuse [浮かむ瀬], BlunderXX, YaneuraOu+Qhapaq, YaneuraOu+Ukamuse+YaneuraOu book #3, Silent Majority+Ukamuse+Mabu book [まふ定跡], Tanuki [ナイツ・オブ・タヌキ], Yomita [読み太], Spear2009, Re_Silent_Majority+AperyWCSC26, SeoTsume [脊尾詰; just for mate problem solving, but it's amazing!]).

Nonetheless, i still like Shogi Browser Q 将棋ぶらうざＱ and prefer its options over Shogidokoro, which is kind of buggy. I just dont want to compile all the engines. 

For Xboard, i havent been able to figure out how to move a piece within the promotion zone without it promoting. It promotes by default, but that's not always the desired option.

Links:

https://github.com/mk-takizawa/elmo_for_learn
https://github.com/yaneurao/YaneuraOu
https://github.com/gikou-official/Gikou/releases
https://github.com/qhapaq-49/qhapaq-bin/releases
https://github.com/Jangja/silent_majority/tree/1.2
https://github.com/HiraokaTakuya/apery/releases/tag/SDT3
https://github.com/HiraokaTakuya/apery/releases/tag/WCSC26
http://ak110.github.io/
https://github.com/mafu-opening-theory/Shogi_opening_theory
https://github.com/nodchip/hakubishin-/releases
https://github.com/TukamotoRyuzo/Yomita
https://github.com/Kenbin/silent_majority/tree/test/build
http://panashogi.web.fc2.com/seotsume.html

26: Test_DontPlayMe (1250) 2016-09-08 15:28 (2016-09-08 15:30に編集)

The XBoard OSX Shogi App has now been upgraded with an improved UCI2WB adapter for running USI engines. (Direct link: 
http://www.mediafire.com/download/6fti4osn18xj24v/XBoardSg_4.9.1_OSX_Intel.dmg ) This allows you to install even the non-compliant USI engines in the standard way (by ticking the UCCI/USI checkbox), and provides two new options in the Engine Settings dialog:

A checkbox 'Floating Byoyomi' must be ticked for engines like GPSfish and Saya Chan, which play only by byoyomi, ignoring the time on their clock. This fools the engines into using the base time by telling them they have more byoyomi (2.5% of the time left on their clock being added to it).

A numerical option 'Byoyomi (sec)', where you can specify a constant byoyomi (used for all moves of the game). This can be used for adjusting time usage of engines with strange time usage under the Floating Byoyomi option. When set to -1 (and Floating Byoyomi not ticked) byoyomi isnot used at all, and the engine would be used with the classical or incremental time control set for XBoard. There are now many engines that do not uderstand these time controls, however, and must use one of the two forms of byoyomi TC. (IIRC Laramie, BlunderUSI, GPS Shogi and TJshogi had no problems running under classical TC.)

Note that these byoyomi options only have effect when XBoard is running in incremental TC (of which sudden-death is a special case). One would expect good time usage when the byoyomi the engine assumes is equal to the increment XBoard uses there. The fact that the GUI adds any left-over time to the clock in incremental mode would just delay entering the byoyomi phase, so that the engine keeps the leeway of being able to think extra long when it is needed for a larger number of moves.

25: Test_DontPlayMe (1250) 2016-09-08 00:52 (2016-09-08 00:56に編集)

Either File-> Load Game, and browse to a kif file, or copy the game to the clipboard, and use Edit -> Paste Game (or press Ctrl-V when the XBoard main window has focus).

Both Shift-JIS and UTF8 encoding should work.

24: kmullin (1100) 2016-09-07 23:36

@Test_DontPlayMe, 

For XBoard opening .kif files, should one use 'File' > 'Load Game' from the file menu?

23: kmullin (1100) 2016-09-07 23:12 (2016-09-07 23:21に編集)

@oekaki_coco,
Ok, I'll try Shogidokoro.

On the 81Dojo kifu files, I was able to open them with S Browser Q by doing two things: 

(1) change the file's encoding from UTF-8 to Shift JIS encoding [why does Japan still use this anyway?]. S Browser Q requires Shift JIS.
and 
(2) fix the time format within the file. 81Dojo ends the time value for each move with ' /) '. It seems that S Browser Q requires there to be a number following the ' / '. So, one can do a simple replace of '/)' with '/00:00:00)'. Of course, if one has lots of .kif files from 81Dojo, then it's probably better to write a script to do this automatically. And, maybe 81Dojo should modify their kifu saving code to include a 00:00:00 value following the backslash to improve compatibility.

22: Test_DontPlayMe (1250) 2016-09-07 16:56

XBoard 4.9.0 should also accept pasting of kif games. (Please let me know if there are problems with that; it is a novel feature.)

The time-usage problem seems to be mostly with the engines themselves. They seem to be developed only for running at certain time controls, unable to handle all combinations of parameters. The worst example of this is Kuma (Bear Shogi?), which always plays 30-min sudden-death games, no matter how long you order it to think through the USI interface.

Several engines also have the problem that they seem to base their thinking time solely on the byoyomi. So if you play 10 min + 20 sec byoyomi, they will think 20sec, and with 10 min + 10 sec byoyomi they think 10 sec for each move. That might be reasonable if the byoyomi is substantial. But if you set them to play 1 hour + 1 sec byoyomi, they start thinking 1 sec/move, and over entire game use up only 1 or 2 min of the 1 hour they have available, as the game will usually not last more than 120 moves. This under-usage of time of course makes them lose badly against opponents that would use the full hour, and think 1-2 min for the first 30 moves after the opening. If you set the byoyomi to 0 on such engines, as it would be in sudden-death games (like 5 min + 0 sec byoyomi), such engines do not use any time at all, and just search 1 or 2 ply deep, playing like an idiot.

So it depends not so much on the UI you use as on the combination of (and sometimes absolute value of) time-control parameters.

This problem seems so common that I will probably equip XBoard (or actually the UCI2WB adapter through which it runs USI engines) with a work-around option for engines that ignore the base time. Activating this option would cause the UI to ly to the engine about the byoyomi it has, by adding a reasonable fraction of the timeleft on its clock to the byoyomi. E.g. the true byoyomi setting of the UI (which could be 0 for sudden-death games), plus the clocktime divided by 30. That would converge to the true byoyomi as the clock time runs out, so that the engine would not forfeit on time if the game lasts unexpectedly long. A checkbox 'Floating Byoyomi' in the Engine Settings dialog couldactivate this.

21: oekaki_coco (1893) ☗1☗3☗32016-09-06 20:09 (2016-09-06 20:10に編集)

@kmullin,

If it is easy for you to handle gikou, it may be simple on shogidokoro.
As for the analysis of your games, that one is briefer.
Unfortunately you cannot paste  81dojo's kif on Shogibrowser-Q.
You must convert it by other software.
However, you can paste  on Shogidokoro.
And it is usable in English.
Please try it.


@Test_DontPlayMe,

In the computer shogi, control of the time sometimes becomes the problem.
And it is a problem of UI or is the problem of the shogi engine and is both.
Because it is matched with the environment of the developer.
Those shogi engines are not for everybody to play, and this is because it is made as a competition of the computers.
And the rule of the time is sometimes replaced.
So the developer thinks that it works normally in one's environment to be the most important. Other cases are not so important.
Probably XBOARD is not made to control in the time for new shogi engine.
It may become the problem and may not become.
It is different by the version of  the shogi engine.
It is different by the version of  the UI.
Most developers adjust it on the basis of "Shogidokoro"
If you want to solve the problem, you should try various combinations.