| |
BGonline.org Forums
Proposal to redefine suffix -n in a move sequence
Posted By: Taper_Mike In Response To: Proposal to redefine suffix -n in a move sequence (Taper_Mike)
Date: Sunday, 5 May 2013, at 4:43 p.m.
Proposed Suffixes for Unlimited Games Mneumonic Suffix Jacoby Rule Enforced Beavers Allowed Jacoby/Beaver Field in XGID Money none, or -m yes yes 3 Normal match scores -n no no 0 Beavers -b no yes 2 Jacoby -j yes no 1
Unlimited Games Versus Quasi-Money
My proposal is that all the suffixes in the table above apply only in unlimited games. I believe that the best rollout settings for a “normal-match-score” rollout are unlimited games, no Jacoby, no beavers. These settings mirror the rules of match play exactly, and the result is the same as if a match were tied at “infinity-away.”
It is no accident that suffixes above correspond exactly to the settings used by the Jacoby/Beaver field of an XGID.
Another suffix, -q, for quasi-money, can be used to describe match scores that are tied at many-away. Several years ago Stick and Nack occassionally used -q to describe rollouts made at 7-away/7-away, 9-away/9-away, and other similar scores. The practice never caught on, however, and perhaps it is just as well. Score effects can still have a significant impact in a quasi-money rollout, and not all scores are equal.
I like Dmitriy’s idea here. For these kinds of scores, you are better off just using a suffix that gives the exact score. An opening 63S-32, for instance, with the score tied at 7-away, can be written as 63S-32.–7–7.
Nactation as a Transcription Tool
All of the arguments against my proposal have focused on the use of Nactation to describe rollouts. Quite correctly, posters have pointed out that in practice a setting of no-beavers produces the same result as a setting where beavers are allowed.
Fair enough.
But what about the circumstance where Nactation is used to transcribe the moves in a chouette? The human players involved will make all sorts of cubing mistakes. Occassionally correct play will demand that a beaver be offered. If the Nactation sequence for a game carries no information about the status of beavers, an XG analysis of the game might cause XG to flag a failure to beaver as an error. When you analyze your own games, that may not matter. Usually, you will remember the circumstance. If you pull a sequence off the Internet, however, or get it from some other source, you may have no way of knowing what the actual status of beavers was.
My proposal solves the problem, by supplying all the tools needed to independently record the status of both Jacoby and beavers.
Why Not Respect the Settings a Player Has Chosen?
Not everyone has gotten the memo regarding the futility of making a rollout where beavers are allowed. Many players prefer to roll with beavers, and many without. Just this week, we have seen a -j posting from Timothy Chow and a -b posting from Ken Bame.
My theory is that people who make and share their rollouts understand the settings they have selected. I see nothing wrong with recording those choices exactly as they were made.
One-to-Many Relationships
Feel free to skip down to the bottom if the details of database management cause your eyes to glaze over.
The three central tables in my database are Opening, Score, and Rollout. A move sequence, such as 63S-32, has a record in the Opening table.
In principal, each move sequence can be rolled out at many different scores. That’s where the Score table comes in. For every move sequence in the Opening table, there are potentially many different scores entered in the Score table. In the case of 63S-32, for instance, I have entries in the Score table for 63S-32 (money), 63S-32-d, 63S-32-g, and 63S-32-s. The Score table does not repeat the move sequence for a position, but instead records only a link back to the corresponding entry in the Opening table. The Score table then records the suffix, along with the XGID for the position.
Finally, I have the Rollout table. For each different Opening and Score, there are potentially many different rollouts.
The problem that caused me to formulate my proposal has to do with inaccurate XGIDs. I have several hundred rollouts, for instance, of fourth-roll cube actions. Some were made for Jaboby, but no beavers. Others were made with both Jaboby and beavers. My problem is that the same XGID cannot describe both.
My proposal is designed to allow Nactation to more closely parallel the structure an XGID. Were my proposal adopted, I could easily add a few more score records, entries such as 63S-32-j and 63S-32-b, link the appropriate rollout records to them, and be done.
Another feasible solution is simply to remove XGID from the Score table, and place it in the Rollout table. That way, I could record an individual XGID for each rollout. There would never be any conflict between a score suffix and an XGID. (I have begun to conclude that I am headed in that direction no matter what happens to my proposal here. There are some other forces steering me that direction.)
Summary
Solving my database problem, however, does not address the issues of transcription and accuracy in documentation described above.What do you think?
Mike
| |
BGonline.org Forums is maintained by Stick with WebBBS 5.12.