Repository navigation
fix(recovery): align trace half-tie rounding - #1437
Merged
Merged
Conversation
ryanbr
added a commit
that referenced
this pull request
Aug 19, 2026
… skin-temp comment Two residuals left behind by the rounding/formatting parity work in @bhelm's #1437 and #1440, found by re-checking those merges rather than by a report. #1437 aligned the half-tie rule but left the near-zero case divergent, and the helper turned out to hold TWO traps for a negative zero. Math.round returns a Long, which has no negative zero, so negating it before the division collapses -0.0 to +0.0 for anything that rounds to zero; and `-0.0 < 0.0` is FALSE, so a sign comparison cannot route an exact -0.0 into a negating branch at all. The second is reachable, not hypothetical: the skin-temp term is z = -|dev| / scale, so a deviation of exactly 0.0 produces -0.0. These values are interpolated straight into the trace, so either trap printed z=0.0 on Android against z=-0.0 on Apple. Rounding the magnitude and reapplying the sign with copySign handles both; verified on a JVM across -0.0, small negatives, half-ties in both directions and positives. #1440's comment described a bug that does not exist. `%+.1f` renders -0.0 as "-0.0" and 0.0 as "+0.0" on both C printf and Java's Formatter, checked directly. The real defect it fixed was the sign built from `dev >= 0`, which is TRUE for -0.0, prepending "+" to a value already formatting as "-0.0" and printing "+-0.0". The comment now states only what was checked, and gives the honest reason the explicit branch stays: it pins the edge so the two zeroes cannot drift from the twin on a Foundation whose formatter has not been tested. Two mirrored vectors per platform cover the near-zero and the exact -0.0 case. Android 4,067 tests / 0 failures; both files sit under Packages, so swift-packages executes the Swift twin.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Aligns Kotlin Recovery diagnostic trace rounding with Swift for positive and negative half-ties by using an explicit nearest, ties-away-from-zero rule.
The Recovery score is unchanged; only trace formatting is affected. Mirrored tests also pin ordinary non-ties and score neutrality.
Type of change
How it was tested
cd Packages/StrandAnalytics && swift test --filter RecoveryScorerTraceTests— 6 tests passedcd android && ./gradlew :app:testFullDebugUnitTest --tests "com.noop.analytics.RecoveryScorerTraceTest" --no-daemon --max-workers=1 --no-parallel— 6 tests passedOnly the focused suites were run. No manual, device, or strap testing was performed; this is pure diagnostic formatting.
Checklist
android/— focused suite passed; full suite was not runStrandDesigntokens — not applicabledocs/CONTRIBUTING.mdRelated issues
Related: bhelm#38
Follow-up rounding bounds: bhelm#47