Logical coordinate
Read table rows in Path order. lks_path_compare() defines that order. Display text is readable but is not a lexical sort key. A changed Path does not change an item's application ID.
Interactive explanation
One ordering model at a time
This page replays recorded results. It does not run production C or simulate the AVL index.
The comparator is bound when the Tree is created. New items enter numeric value order; equal values retain insertion order. The Tree assigns Paths, and a congested gap may relabel existing coordinates.
The application chooses coordinates and may insert, remove, or rekey one item by exact Path. The layer-list sequence below is taken from the public C example. Its IDs are application identity; Paths are mutable ordering state.
0 / 10
Current operation
Ready to insert
Choose Step or Play.
Existing Paths changed: 0
| Position | Application item | Comparator value | Current Path | Change |
|---|
Exact Paths are recorded snapshots. Reset or switching sequences starts at the beginning.
Physical index
Both Tree models use a Path-keyed AVL index. Physical parent and child links are implementation-defined and do not mean Path prefix or logical parentage. Managed relabel retains the existing physical nodes while replacing Path coordinates.
Persistence
Canonical display text represents one readable Path. A versioned LK1: key can persist and bytewise-sort one current coordinate. Neither stores item payloads, permanent IDs, or a whole Tree.
Limits to plan for
A managed insertion can relabel the full logical range. A large relabel can cause significant synchronous tail latency. Path depth and storage depend on the workload. Complete insertion has no proven worst-case O(log n) guarantee or formal amortized bound.
Caller-owned items and comparator context must stay alive. Remove an item, change comparator-visible fields, then reinsert it; do not mutate its sort key while resident.