TalkChess.com

Perhaps you just add more men to your generator, test it (with fewer men) in your computer then ask some volunteers to compile and run in their systems?

I can help to run if it requires no more than 16 GB (the mem size of my iMac).

Would it be trivial to adapt the Syzygy EGT generator for Shatranj? Or would it be easier to just write a dedicated generator for that? I am only interested in the WDL statistics of a few specific 6-men end-games (KRFE-KR and KFF-KFE). I don't need the tables itself, so I don't care about compressi...

In UCI2WB I just scan with strstr (or StrCaseStr) for the keywords of the standard infos, and then read the token that follows them as the corresponding value. So it would indeed just ignore the 'wdl' and its parameters. This is not optimally efficient; it would be better to just scan through the i...

A programmer can display any data he wants in good visual forms without waiting for chess GUI developers to add them. That's not an advantage, that's a disadvantage. A GUI is supposed to look the same no matter which engine is running underneath. Consistency is an important part of usability. What ...

Let me suggest a description about self-explaining data in which engines can tell chess GUIs how to display their data in the form of tables. There is zero chance I'd be willing to shift the decision on how to present data from the USER INTERFACE to the ENGINE. Those are suggestions but not decisio...

Let me suggest a description about self-explaining data in which engines can tell chess GUIs how to display their data in the form of tables. Table 1) Data (partly command) - A row of a table requires data as an array. Each item has a column name and value. Value could be an integer, a real number o...

I suggest a simple way: engines just send (JSON info) what they want. This won't work for reasons already outlined in my post. The engine has no idea how much detail the GUI wants. And you can send enough info the make the GUI crawl... HGM's idea seems fine. That is why I agreed with your suggestio...

Let me put it differently: with some more work (i.e. thinking about enable/disable info issue) it might be possible to specify a way to send more info inside UCI that could contain WDL and also serve as a well-designed vehicle for transmitting more information (which still has to be specified, beca...

Defining an extension won't help with the core problem: the goal of the protocol is to have engines and GUIs interoperate. So ideally, the things that are defined are useful across multiple engines, and the GUIs have some good way of representing them to the user. If something fits neither, it make...

Instead of adding a UCI option for every individual feature, I would prefer to have some "extension" of UCI added and switched on with one option. For example, it can be UCI_jsonExtension, and then uci info command could have something like uci info ... json {wdl:[0.2,0.3,0.5],other_field:"spaceles...