83,240
edits
The curious structure of an MTN: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 83: | Line 83: | ||
}}</small> | }}</small> | ||
{{tablebottom}} | {{tablebottom}} | ||
Another thing we routinely forget is how important the logical structure of your writing is. Not just the organisation of the paragraphs, but the underlying semantic structure of the sentences themselves. | |||
Any statement boils down to a logical proposition, and so on. It is just like software code, only instead of subroutines, conditions, logic gates, if/then statements lawyers call them [[Obligations binding|obligations]], [[Rights cumulative|rights]], [[Discretion|discretions]], [[proviso]]<nowiki/>s, [[incluso]]<nowiki/>s, [[option]]<nowiki/>s, [[Definitions|definition]]<nowiki/>s and so on. | |||
For example, an obligation is an if-then statement; option is an either-or gate. Some legal operators like “([[whether or not]]...)”, “([[Including, but not limited to|including without limitation]]...)”, “([[for the avoidance of doubt]]...)”, “([[May, but shall not be obliged to|may, but need not]]...)” do not constrain or expand the propositions they act on and can be omitted from a logic map (just as they should be omitted from the ''draft'', dammit). | |||
Any “logic gate” that splits a proposition into alternatives increases its inherent complicatedness. How you organise your gates, therefore, makes a big difference to how complicated your proposition turns out. | |||
Take the alternative statements about cricket and rugby balls in the panel at right. (For non-initiates, [[rugby]] is played with a large oval ball which may be any colour; [[cricket]] with a small round ball which (for one-day cricket) must be white and (for test cricket) must be red. In the abstract, the variables at play here are: | |||
* ball '''shape''' (round or oval) | |||
*round or oval | * ball '''colour''' (red or white (or other)) | ||
*red or white | * '''code''' (rugby or cricket) | ||
*rugby or cricket, | * code '''variation''', which in turn breaks into | ||
: | ** cricket: '''test''' or '''one-day''' (relevant only to cricket) | ||
: | ** rugby: '''union''' or '''league''' (relevant only to rugby) | ||
The ''' | How you arrange these variables can generate a more or less complicated logical structure, depending on how many distinct logic trees you create, and how you order the variables within a given logic tree. | ||
One can (making it up as we go along) formulate a few design principles here: | |||
====== Distinct logic trees ====== | |||
* '''Create distinct logic trees''': The more distinct logic trees you have, the simpler your overall logic will be, though there is a limit (if each logic tree is a straight line then you don't have any logic at all). | |||
* '''Make sure they are distinct''': Distinct logic trees should not intersect with each other: their terms are mutually exclusive. (Intuitively, we suspect that the downstream logic beyond “cricket” will not intersect with any downstream logic beyond “rugby”). | |||
* '''Avoid dead-ends''': Try to minimise logic trees that end in a “no” as these are dead twigs that carry no legal/semantic content, but clutter up the structure. | |||
====== Logic gates ====== | |||
* '''Non-overlapping categories''': Look for categories of items (such as “rugby” and “cricket”) that do not overlap and deal with them in separate logic trees. There is no real benefit to designing a single tree to accommodate these as alternatives. | |||
* '''Postpone logic gates as far as possible''': Where a logic gate must happen (that is, a split between sub-categories within a single logic tree), make it happen as late as possible, in order to... | |||
* '''Avoid duplicating branches''': Design each logic tree so that a given logic gate only happens once. (In the top diagram , the logic gate between the four code variations appear four times and the logic gate for ball shape appears twice, while the colour logic gate only once. If your draft is studded with expressions like “holder of a bearer note and/or registered owner of a registered note (as the case may, for the time being, be)” you have put your logic gate in the wrong place. | |||
====== [[Definitions]] ====== | |||
'''Definitions can function as distinct mini-trees''': On that note: a definition can act as a mini-logic tree if it contains a logic gate. For example, creating a definition like ''“'''Noteholder'''” means the holder of a bearer note [[and/or]] registered owner of a registered note ([[As the case may be|as the case may]], [[for the time being]], be)'' you can simplify the inherent logic of your text: the more the logic gate appears, the more economy a definition can bring. | |||
Again, there is a tension: creating a definition that you only use once or twice can make comprehension harder. And sometimes by getting rid of the “duplicate gates” problem a definition obscured the fact that the logic was designed badly in the first place. | |||
If you want to create a single proposition that covers all these variables, you commit yourself to a lot downstream branching, because that our single logical structure must accommodate all the permutations. | |||
Therefore, if you frame your logic around first the colour of the ball then its shape, you buy yourself a number of branches which get to “NO” answers, and are therefore useless. See the first figure on the right. The colour of the ball doesn't matter for rugby, so you should postpone that branch until colour does matter for all the remaining branches. that is, after you have got to “cricket”. | |||
The subject of the sentence and sequence of the branches makes a difference. For example, focussing on the ball first then its colour then its shape, and articulating these by reference to the games, commits to sixteen branches. If we break the proposition into two and focus first on shape, we can reduce this to five. if we reframe the proposition to focus on the game, we can get it down to the three, which is the minimum. | |||
There is doubtless some information theory that optimises the logical structure, but intuitively it seems to us common options should be delayed as far as possible, and where games are largely common, separating out the points where they differ into a separate set of propositions may help. | There is doubtless some information theory that optimises the logical structure, but intuitively it seems to us common options should be delayed as far as possible, and where games are largely common, separating out the points where they differ into a separate set of propositions may help. | ||