Repository navigation
Keep the mechanism drawing a .mec file carries - #28
Merged
Merged
Conversation
A .mec file stores, with each mechanism, the "chess board" the DOS programs
drew it on: a grid of two-character cells holding state numbers and line
drawing. mec_load read the board and discarded it. It is now kept as
Mechanism.layout, {state name: (column, row)}, row 0 at the top. For
bgtv2a.mec that is the arrangement of Fig. 3 of Burzomato et al. (2004).
Only the positions are taken. Which states are connected is given by the
rates, and the lines on the boards cannot be read back reliably: they use
corner pieces and long runs, and the cube mechanisms are drawn in an oblique
projection.
layout is every state or None, since part of a layout is no use to anything
that draws. Checked against the 85 mechanisms that load from a collection of
29 files: 47 give a complete layout. The other 38 give None, for one of
three reasons - the file stores no drawing (17), an oblique drawing has
overwritten some state cells (3), or the file stores no state names, so
every state has the same blank one and positions keyed by name cannot tell
them apart (18).
Conventions met in those files and covered by tests: a state number after
C or O, bare two-digit numbers, a leading zero ("03"), and "C0" for state
ten.
The tests build their boards from text, so they need no .mec file. Two more
run against a real bgtv2a.mec when SCALCS_MEC_DIR points at one.
A Mechanism defined in Python has layout None. A record from
dcio.formats.mec that carries a layout has it passed through.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A .mec file stores, with each mechanism, the "chess board" the DOS programs drew it on: a grid of two-character cells holding state numbers and line drawing. mec_load read the board and discarded it. It is now kept as Mechanism.layout, {state name: (column, row)}, row 0 at the top. For bgtv2a.mec that is the arrangement of Fig. 3 of Burzomato et al. (2004).
Only the positions are taken. Which states are connected is given by the rates, and the lines on the boards cannot be read back reliably: they use corner pieces and long runs, and the cube mechanisms are drawn in an oblique projection.
layout is every state or None, since part of a layout is no use to anything that draws. Checked against the 85 mechanisms that load from a collection of 29 files: 47 give a complete layout. The other 38 give None, for one of three reasons - the file stores no drawing (17), an oblique drawing has overwritten some state cells (3), or the file stores no state names, so every state has the same blank one and positions keyed by name cannot tell them apart (18).
Conventions met in those files and covered by tests: a state number after C or O, bare two-digit numbers, a leading zero ("03"), and "C0" for state ten.
The tests build their boards from text, so they need no .mec file. Two more run against a real bgtv2a.mec when SCALCS_MEC_DIR points at one.
A Mechanism defined in Python has layout None. A record from dcio.formats.mec that carries a layout has it passed through.