Skip to content

fix: promote compact token units at rounding boundaries - #365

Merged
chattymin merged 1 commit into
chattymin:mainfrom
heli-os:fix/compact-token-unit-boundaries
Oct 5, 2026
Merged

chattymin merged 1 commit into
chattymin:mainfrom
heli-os:fix/compact-token-unit-boundaries

Conversation

@heli-os

@heli-os heli-os commented Sep 27, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Promote compact token counts when one-decimal rounding would produce 1000K or 1000M. For example, 999,950 now displays 1M, and 999,999,999 displays 1B. Existing precision, trimmed zeros, and negative signs are preserved; cost formatting is unchanged.

The unit was previously selected using the unrounded magnitude. Existing tests covered exact unit boundaries and ordinary values, but not values that round across a boundary. The new regression test covers immediately below/at the rounding thresholds, immediately below/at exact unit boundaries, and negative counterparts. A call-site sweep confirmed menu, usage, growth, and shop displays share this formatter; there is no duplicate token abbreviation implementation to update.

Rounding thresholds

K and M use one decimal place. The rollover therefore starts when the scaled value reaches 999.95, not when the raw token count reaches the next power of 1,000:

  • 999,949 / 1,000 = 999.949 → 999.9K.
  • 999,950 / 1,000 = 999.95 → 1000.0K → 1M.
  • 999,950,000 / 1,000,000 = 999.95 → 1000.0M → 1B.

Using 999,999 or 999,999,999 as the threshold would still leave earlier values displaying 1000K or 1000M. The fix keeps rounding; it does not truncate counts.

formatter-comparison

Comparison rendered from the actual Swift formatter outputs at the base and PR commits; this is a formatter-output table, not an app screenshot.

Type of change

  • Bug fix
  • New feature
  • Refactor / cleanup
  • Documentation
  • Other:

Validation

  • swift build passed locally.
  • Ran the actual formatter source in a standalone Swift harness: 30 checks, 8 failures before the fix and 0 after it.
  • Inspected instrumented llvm-cov show --show-regions output for the formatter with the same harness.
  • swift test --filter TokenFormatterTests and ./scripts/test-gate.sh were attempted, but this Mac has only Command Line Tools and cannot import XCTest. The standalone harness is not a substitute for the full test suite; CI should run the committed XCTest regression.
  • GitHub CI passed build-test and secret-scan: 1,381 tests executed, 14 skipped, 0 failures; logic-core line coverage 93.27%. The new boundary regression passed. Run: https://github.com/chattymin/PokeTokenBar/actions/runs/36311970875
  • git diff --check passed.

Checklist

  • swift build and swift test pass locally
  • PR title and description are written in English
  • No copyrighted assets, secrets, or private tooling references are committed
  • Tests were added or updated for this change

@chattymin
chattymin merged commit 4cab9f0 into chattymin:main Oct 5, 2026
2 checks passed
donky-ey pushed a commit to donky-ey/PokeDexBar that referenced this pull request Oct 15, 2026
…ttymin#365)

999,950 displayed as "1000.0K": the bucket was chosen from the raw
value while one-decimal rounding pushed it past the unit boundary.
Promote to the next unit at the rounded cutoff instead.
Strongorange added a commit to Strongorange/PokeTokenBar-windows that referenced this pull request Oct 19, 2026
Port macOS chattymin#365 and chattymin#418: compact K/M switch to the next unit when
rounding would display 1000.0 (999,950 shows as 1M, not 1000K), and
percent/cost tiers are picked from the rounded string instead of the
raw value (79.96 shows as 80%, 99.96 as \, 9,999.6 as \.0K).
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