back to table · edit · history · where entries came from · files · download
1464 bytes, as of the version from 2026-10-26 04:16 (current). Recorded here, not run.
## Convert binary interval endpoints with exact_rational, not QQ
What happened: T505's serialization-containment check converted outward
binary endpoints with `QQ(endpoint)`. An independent control using the lower
80-bit ball endpoint for 1/3 showed that this conversion does not preserve
its exact binary value: QQ returned denominator 483570327845851669882471,
whereas `endpoint.exact_rational()` returned denominator
2417851639229258349412352. Sage's QQ conversion finds a nearby rational.
The checker was changed to `.exact_rational()` for both endpoints, and all
checks were rerun. No table value or its stated precision changed.
What the skill says now: a written decimal denotes an interval, and checks
must test what that interval claims. It does not specify how to convert
Sage floating-point interval endpoints exactly.
What it should say: for a binary RealNumber endpoint, use
`endpoint.exact_rational()` before comparing with an exact rational bound.
Do not use `QQ(endpoint)` as a synonym for exact conversion. A decimal's
center and last-place unit should also be constructed as exact rationals.
Overlap alone is weaker than containment of the entire computed ball.
Evidence: `endpoint-conversion.log`, `check_endpoint_conversion.py`,
`checks.py`, `checks-final-pre-fill.json` and `checks-stored.json` in this
run. The final checker requires each production ball's exact outward
endpoints to lie within its serialized 100-digit decimal interval.