Repository navigation
fix(core): round Decimal.doubleValue correctly - #1082
Merged
Merged
Conversation
`doubleValue` divided the mantissa by ten once per decimal digit, so 0.007 became 0.006999999999999999 and 0.000001 became 1.0000000000000002e-06. Android's `BigDecimal.toDouble()` rounds correctly, so the two apps could send different `native_amount` doubles in intent `client_exchange_data` for the same amount. Parse `description` with `Double(String)` instead. `NSDecimalNumber`'s `doubleValue` is no fix: over 200k sampled decimals it missed on exactly the same values as the loop, while the string parse missed none.
bmc08gt
added a commit
that referenced
this pull request
Oct 19, 2026
* origin/main: feat(chat): pick a new group's currency from a full-width row (#1084) fix(core): round Decimal.doubleValue correctly (#1082) feat(flipcash): adopt ocp 0.8.0 and flipcash2 0.20.0 contracts (#1078) chore: bump version to 2026.10.4 (#1086) chore: record 2026.10.3 as the production release (#1089) ci(release-manifest): record every TestFlight build when it processes (#1088) build: update release manifest test: stop four retry-only tests failing on a loaded runner (#1087) fix: clear the 2026.10.3 release test gate (#1085) build: update release manifest fix(chat): cap the attach card's corner radius at 40pt on iOS 26 (#1081) feat(update): check for an update every time the app returns from the background (#1080) build: update release manifest chore(chat): log where the inline photo picker flow stops (#1079) build: update release manifest fix(chat): open the author's profile from the avatar beside a photo (#1077) feat(chat): forward a message through the share sheet (#1076) feat(chat): draw message links as a message card (#1057) # Conflicts: # FlipcashCoreVectors/Tests/FlipcashCoreVectorsTests/MultiPaymentIntentVectorTests.swift
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.
Decimal.doubleValuedivided the mantissa by ten once per decimal digit, so it could land a few ulps off the nearest double. For example, 0.007 became 0.006999999999999999 and 0.000001 became 1.0000000000000002e-06. Android'sBigDecimal.toDouble()rounds correctly, so for the same amount the two apps could send differentnative_amountdoubles in intentclient_exchange_data.This parses
descriptionwithDouble(String)instead.NSDecimalNumber.doubleValueisn't a fix: across 200k sampled decimals it got the same values wrong as the old loop, and the string parse got none wrong.DecimalDoubleTestscovers the values above and the native amounts inmulti_payment_intent.json. The exact-equality change to the multi-payment vector test is stacked on #1078 in its own PR, because that test only exists on #1078's branch.