VectorLibHow parity is proven
The original C++ and VectorLib run on the same simulated robot, compared bit for bit.
The test suite compiles the original C++ (LemLib 0.5.6, LemLib-TitanTron and TitanReset, unmodified) against a mock of PROS backed by the same simulated robot. It then runs identical scripts through the C++ and through VectorLib. Every output is compared exactly: motor commands as integers, positions as raw float bits.
| What was compared | Values | Differences |
|---|---|---|
| LemLib pure functions: angle error, PID, drive curves, pose maths, path parsing | 41,513 | 0 |
| LemLib driver control: tank, arcade, curvature | 198,135 | 0 |
| LemLib motions on 7 sensor setups × 2 gain sets, every millisecond | 1,718,132 | 0 |
| TitanTron: early lambdas, scaled IMU, point paths, live gains, odom offsets | 470,267 | 0 |
| TitanReset: DSR maths and resets on a simulated field | 130,638 | 0 |
| Total | 2,558,685 | 0 |
The home page replays one of these runs: LemLib's example autonomous, recorded every 10 ms from both implementations.
Where VectorLib deliberately differs
Where reproducing the C++ exactly would mean reproducing undefined behaviour, VectorLib does the defined thing:
cancelAllMotionswhile a motion is queued leaves LemLib's mutex locked, and the next motion deadlocks. VectorLib releases it.- TitanReset's
stop_location_recordingleaves a dangling task pointer, and its debug screen reads an IMU pointer that is never set. VectorLib defines both. - LemLib's
findClosestleaves its result uninitialised when every distance is NaN. VectorLib starts it at 0.
The full list, with reasons, is in PARITY.md.