Skip to content

Fix charge driver skin temperature formatting - #1440

Merged
ryanbr merged 1 commit into
ryanbr:mainfrom
bhelm:fix/charge-driver-skin-format
Aug 19, 2026
Merged

ryanbr merged 1 commit into
ryanbr:mainfrom
bhelm:fix/charge-driver-skin-format

Conversation

@bhelm

@bhelm bhelm commented Aug 19, 2026

Copy link
Copy Markdown

What this PR does

Makes the Swift Charge-driver skin-temperature text use an explicit en_US_POSIX formatting contract matching Kotlin Locale.US. This fixes byte drift at decimal half-ties and preserves the IEEE sign for negative zero. The existing respiration row now uses the same explicit Swift locale without changing its text.

Mirrored native tests pin exact skin-temperature text for -0.35, +0.35, both adjacent non-tie sides, and signed zero. They also pin existing respiration text and unchanged driver semantics.

Type of change

  • Bug fix
  • New feature
  • Refactor / cleanup
  • Documentation
  • CI / tooling

How it was tested

  • Swift focused ChargeDriversTests formatting test: passed, 1 test / 0 failures.
  • Android focused RecoveryDriversTest formatting test: passed, 1 test / 0 failures under JDK 17, one worker, no parallel Gradle, and the in-process Kotlin compiler.
  • The Swift test was observed RED before the production fix for -0.35, +0.35, and negative zero.
  • Independent delta review found no P0/P1 issues.

Checklist

  • Swift package tests pass for any package I touched (focused StrandAnalytics test passed)
  • Android unit tests pass if I touched android/ (focused testFullDebugUnitTest passed)
  • No new build warnings introduced
  • UI changes use only StrandDesign tokens — no UI change
  • No hardcoded hex frame bytes; protocol facts live in the schema / decoders
  • Follows the conventions in docs/CONTRIBUTING.md
  • I did not commit generated output or any secrets/keystores

Related issues

Related: bhelm#52

@ryanbr
ryanbr merged commit 3c0adc0 into ryanbr:main Aug 19, 2026
14 checks passed
ryanbr added a commit that referenced this pull request Aug 19, 2026
Third pass on my own comment. Correcting #1440's claim, I asserted that `%+.1f` cannot
distinguish the two zeroes for the "+0.0" case. That is also false: C printf and Java's
Formatter both render -0.0 as "-0.0" and 0.0 as "+0.0", checked directly. So the explicit
zero branch is redundant on the formatters we have actually verified.

The comment now says that, and gives the honest reason the branch stays: it pins the edge so the
two zeroes cannot drift from the Kotlin twin on a Foundation whose formatter has not been
checked. The bug the branch replaced is unchanged and correctly described - a sign built from
`dev >= 0`, which is TRUE for -0.0, prepending "+" to a value already formatting as "-0.0".
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.
@bhelm
bhelm deleted the fix/charge-driver-skin-format branch September 15, 2026 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants