diff options
Diffstat (limited to 'lib/rites/rite_ef/precedence_ef.mli')
| -rw-r--r-- | lib/rites/rite_ef/precedence_ef.mli | 44 |
1 files changed, 36 insertions, 8 deletions
diff --git a/lib/rites/rite_ef/precedence_ef.mli b/lib/rites/rite_ef/precedence_ef.mli index 49195f9..b283a17 100644 --- a/lib/rites/rite_ef/precedence_ef.mli +++ b/lib/rites/rite_ef/precedence_ef.mli @@ -68,10 +68,21 @@ val unclassified : int text states an exception: entry 8 (All Souls) reads "yields to an occurring Sunday", so on a Sunday this returns a value that loses to entry 15 rather than the literal integer 8 (see the comment on - entry 8 in precedence_ef.ml for the exact value and why). Total over - every candidate {!Precedence.resolve} or {!Calendar} can construct, - including shapes the 1962 table itself does not describe (see - {!unclassified}). *) + entry 8 in precedence_ef.ml for the exact value and why). ALSO + {!unclassified} for any [Cel.Commemoration_only] candidate, checked + first, ahead of every rank-keyed branch -- CORRECTED, Task B fix round + 1 (coordinator finding 1): RG 91's own table enumerates only "dies + liturgici" (entry 24's own text, "Festa III classis..." -- FEASTS), so + a celebration reduced to a bare commemoration was never a row in the + table to begin with, confirmed by the calendarium's own notation (a + genuine feast carries a class number on its occurrence line; a bare + "Commemoratio" carries none). Before this fix, a [Commemoration_only] + candidate silently borrowed the SAME entry number as a genuine [Feast] + of its own [rank] -- manufacturing ties {!Precedence.compare_by} and + {!compare_precedence} both then had to break some other way, that RG 91 + itself never created. Total over every candidate {!Precedence.resolve} + or {!Calendar} can construct, including shapes the 1962 table itself + does not describe (see {!unclassified}). *) val band : Vocab_ef.season Precedence.context -> Vocab_ef.rank Precedence.candidate -> int (** RG 33's marker: every Sunday slug this rite's temporal cycle produces @@ -195,8 +206,16 @@ val september_ember_prefix : string CORRECTED, Task B (branch ef-rg16a): this used to sort by [Vocab_ef.rank] (RG 8's coarse four-class "dignity") and break same-rank ties alphabetically by slug -- an engineering convention with no - rubrical warrant, cited nowhere, silently deciding 66 days over - 2005-2050. RG 113's own second sentence, previously uncited + rubrical warrant, cited nowhere. Measured, fix round 1 (2005-2050, + reproducible via a temporary [git worktree] at the pre-fix commit): + a same-[rank] tie existed in the candidate pool offered to [admit] on + 599 days, most never reaching a real decision (RG 111's own admission + count often has room for both, e.g. a III-class day admits two); of + those, reversing the slug tie-break ALONE actually changed the ADMITTED + SET on 65 days and only the printed ORDER of an already-admitted pair + on a further 149 (docs/research/rules-register.md §6.1's own full + account, superseding this comment's earlier, unreproduced "66 days" + claim). RG 113's own second sentence, previously uncited (docs/research/rules-register.md §4's RG 113 entry), is the real rule: *"in admittendis et ordinandis aliis commemorationibus, servetur ordo tabellae praecedentiae"* -- admitting and ordering commemorations both @@ -205,8 +224,17 @@ val september_ember_prefix : string receive on its own, so {!Precedence.resolve} computes it once, generically, and hands each candidate its own value as the trailing [int] on [comms]'s triples (see {!Precedence.rules.admit}). Ties break - on slug ONLY within one identical [band] value (RG 113 gives no further - instruction there; still an uncited engineering convention, register §6 + on slug ONLY within one identical [band] value -- CORRECTED, fix round + 1 (coordinator finding 1): [band] itself used to hand a + [Cel.Commemoration_only] candidate the same table entry as a genuine + [Cel.Feast] of its own rank (RG 91's table has no row for a bare + commemoration at all), manufacturing most of the "identical [band] + value" ties this comment used to describe as RG 113's own residual. + Fixed in [band] itself; checked afterward (2005-2050 and the full + 1583-9999 domain, register §6.1) and found EMPTY of any remaining + "two different real table entries tied" case -- the slug fallback below + is exercised only between two [Commemoration_only] candidates both at + {!unclassified}, still an uncited engineering convention (register §6 "RG 113 tie-break"), matching {!Precedence.compare_by}'s own fallback, so the result never depends on the order [comms] arrives in. |