You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All three are mine, from the previous round, found by review.
1. Only one SUFFIX_OR_FAMILY survived per segment. ambiguous_pick was a
single slot the peel loop overwrote, so "John Smith MA JD" made two
coin-flips and reported one -- defeating the point of reporting.
Collect them instead. The sibling SUFFIX_OR_NICKNAME emitter already
did this correctly, so it was an oversight, not a design.
2. The detail string was wrong under two of three name orders. The
comment claimed the unpeeled piece "stays the last name piece -- the
family name under every order"; _name_positions maps a two-piece
name to [FAMILY, GIVEN] under FAMILY_FIRST, so it is the GIVEN name
there and the text said otherwise. Ambiguity.detail is public, so
this misinformed callers. Now reads the role back after assignment.
3. Origin resolution was quadratic, and so was the check it fed.
Resolving each ambiguity's offset rescanned every token, and
ParsedName.__post_init__'s subset check then did `tok not in
self.tokens` per referenced token -- O(ambiguities x tokens) twice
over. Reachable because the new closer sweep can emit one ambiguity
per delimiter character. Bisect over the (already sorted) token
starts, and hash the token tuple once:
') ' * N before after
N=1600 182 ms 12 ms
N=3200 -- 25 ms (linear)
The subset check was pre-existing but only became reachable at scale
once ambiguities started carrying tokens.
Verified: differential harness 486 names, 2 intentional diffs, 0
unexplained. The review separately confirmed the 8147ac6 peel change
against 304 generated shapes under all three name orders -- 86 changed,
all 86 from disagreeing with v1 to matching it, 0 regressions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments