I thought that's exactly what I did -- showed you a way to add one "teeny tiny" character, just for purposes of computer translation in extraordinary circumstances. (And even though I have done that, you say you prefer a binary system with more characters. So, which is it that you really want?)
I don't want to give the impression I'm ungrateful for your suggestions and for your lucid explanations. Nothing could be further from the truth. However, from the way you phrase this, I don't get the sense that you're intending to extend the formal syntax of nactation with this idea. And that's a pity.
I've brought this up before, but I think it's a huge mistake to promulgate two nactation variants - one for humans and the other "just for the purposes of computer translation". The only point of storing nactation symbols in a computer is to mediate communication between humans. (If you're interested in a compact solution for storing position information that's "just for computers", take a look at the 14-digit GNU PositionID string, which encodes the exact position of all 30 checkers in a 25 point matrix.)
Ultimately, I'd like to copy the nactation sequences commonly posted on this forum and paste them into a program that efficiently decodes the string and stores the underlying positions. But if people here are speaking the "human" variant (as is likely), then my system may not understand the sequence!
Let me contextualise the issue with a real-world example.
I'm busy with a long-term project to construct a database of early game positions. I've already imported Tom Keith's excellent and under-rated archive of replies. (This is by far the most thorough collection of such information available online.) Now I'm attempting to update the equities with more modern data, kindly posted to this forum by experts such as yourself. There's just one hitch: Tom's data is listed in traditional notation, while the data here is presented in nacbracs.
No problem, I think: I'll just hand-nactate all of Tom's positions, and then get the computer to automatically join the nactated positions with the wonderful nacbracs resource provided by Kye Hedlund . In this way, I can hone my nactation skills on 1783 early positions and end up with an archive updated with the latest data.
Easier said than done.
Here's a typical example of the type of problem I face:
The 21S-11 (money) position you mentioned? It's not listed in Alexandre's set, and I can't find it anywhere within the bgonline forum archive. I think Kye used Stick's Snowie data, although I suspect he may've mistyped it.
Tom lists 4 options for 21S-11 (supplemented here with my nactation):
| Rank | Traditional notation | Relative equity | Nactation |
|---|---|---|---|
| 1 | 24/22, 6/5(2) | 0 (best) | e |
| 2 | 24/23, 6/5(3) | -0.007 | E |
| 3 | 24/23(2), 6/5(2) | -0.026 | E |
| 3 | 8/5, 6/5 | -0.046 | P |
And here's my own XG analysis for comparison:
                        |
| ||||
| XGID=-aa---E-C---dEa--c-e----B-:0:0:1:11:0:0:0:0:10 | |||||
| Blue to play 11 | |||||
| 1. | Rollout1 | 24/22 6/5(2) | eq: +0.179 | |||
| ||||||
| 2. | Rollout1 | 24/23 6/5(3) | eq: +0.159 (-0.020) | |||
| ||||||
| 3. | Rollout1 | 24/23(2) 6/5(2) | eq: +0.135 (-0.044) | |||
| ||||||
| 4. | XG Roller+ | 8/5 6/5 | eq: +0.090 (-0.088) | |||
| ||||||
| 5. | XG Roller+ | 8/7(2) 6/5(2) | eq: +0.055 (-0.124) | |||
| ||||||
| 1 41472 Games rolled with Variance Reduction. Moves and cube decisions: 3 ply | ||||||
eXtreme Gammon Version: 1.21
It seems Tom's early bot chose the top four plays in the correct order, but the equities are way out (to be expected given the rudimentary GNU rollout settings he employed then). So I'd want to update those.
Now what if I hadn't rolled this out myself? Could I use Kye's data for such an update?
Well, he lists the nacbracs for 21S-11 as [e H31].
The first choice (e) looks good, but what's up with H31? Kye surely can't mean the 6/2* uber-whopper? My guess is that he intended 24/23, 6/5(3), but couldn't figure out the appropriate symbol (or couldn't work out how to put it in his database). You might dismiss this as a simple and avoidable nactation error, but I think it signposts bigger problems (potentially insurmountable for the computer programmer).
By promoting a system with "assumptive" alternatives, you suggest that it's okay for players to choose from a selection of disparate options. And users are naturally going to shy away from computer unfriendly font-styles, choosing creative "assumptive" alternatives instead. You indicate that for 24/23, 6/5(3), "E is unnecessary; f is unambiguous". If that's the case, why offer both? It's just going to cause confusion, both for computers and for humans. (I can imagine some players might guess that f implies 24/23, 8/7(3) or 24/23, 8/6.)
A handy phrase springs to mind: "assumption is the mother of all screw-ups".:-)
Similarly, why offer both font-style and 2-character nactation family encoding options for different audiences? It's confusing. My suggestion: put the font-style hierarchy out to pasture...
In my opinion, there should only ever be one 'best' symbol to describe a play, and one simple plain-text format for dissemination of that symbol. It should either be correct, or incorrect. No grey areas. For a play like 64R-32, it seems to me that playing 13/11*, 13/10 might be nactated D or H. But which is 'best'?
I am an enormous fan of nactation, so I hope you'll take this as constructive criticism. I think the system has the potential to be incredibly influential on the way mainstream backgammon is studied and discussed going forward. But unless these types of ambiguities are resolved, I fear interest will not expand beyond a cult following of hard-core cryptography nerds. (Which is fine, I suppose: I'm one of them :-)
Matt