rename Amount::saturating_div into saturating_ratio #4972
Merged
Conversation
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
…mount::saturating_div for scalars
afck
approved these changes
Nov 16, 2025
afck
reviewed
Nov 16, 2025
Co-authored-by: Andreas Fackler <[email protected]> Signed-off-by: Mathieu Baudet <[email protected]>
ma2bd
added a commit
that referenced
this pull request
Nov 17, 2025
## Motivation
The `Amount` can be multiplied by `u128` using `saturating_mul` but we
don't have an inverse operation. The existing `saturating_div` compute a
`u128` ratio between two amounts.
## Proposal
* rename `Amount::saturating_div` into `saturating_ratio`
* create a new `Amount::saturating_div` that takes a u128 similar to
`saturating_mul`
## Test Plan
CI
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
---------
Signed-off-by: Mathieu Baudet <[email protected]>
Co-authored-by: Andreas Fackler <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 18, 2025
## Motivation * Fixes #841 * Demonstrate how to embed parameters in the "extra" field of `View`s to help with code structure. (I mentioned this possibility to @kikakkz once but we had no example to show.) ## Proposal Allow creators of a market to specify a fixed decimal precision for prices. * The amount to be paid for an order is: `amount = quantity * price/10^precision`. * If `quantity` (expressed in "attos", the lowest precision for `Amount`) is not a multiple of 10^precision, then the order is simply invalid. We modify the code in several steps: * add application parameters to storage context * nit: rename `next_order_number` into `next_order_id` * rename "amount" into "quantity" + add integration tests * reorganize the code (moving methods closer to their main object) * finally, add the notion of "price decimals" Discussion: * AFAICT it is very standard for market prices to have fixed precision. Eventually, `Amount`s should probably have a configurable (reduced) precision as well. * Parameters being immutable, copying them in the `extra` field is pretty harmless. One could also embed the entire runtime using `Arc<Mutex<ContractRuntime<MyContractState>>` but this is arguably a tradeoff (e.g. any view can now schedule outgoing messages). stacked with #4971 and #4972 ## Test Plan CI ## Release Plan - These changes should be backported to the latest `testnet` branch, then - be released in a new SDK,
ma2bd
added a commit
to ma2bd/linera-protocol
that referenced
this pull request
Nov 18, 2025
* Fixes linera-io#841 * Demonstrate how to embed parameters in the "extra" field of `View`s to help with code structure. (I mentioned this possibility to @kikakkz once but we had no example to show.) Allow creators of a market to specify a fixed decimal precision for prices. * The amount to be paid for an order is: `amount = quantity * price/10^precision`. * If `quantity` (expressed in "attos", the lowest precision for `Amount`) is not a multiple of 10^precision, then the order is simply invalid. We modify the code in several steps: * add application parameters to storage context * nit: rename `next_order_number` into `next_order_id` * rename "amount" into "quantity" + add integration tests * reorganize the code (moving methods closer to their main object) * finally, add the notion of "price decimals" Discussion: * AFAICT it is very standard for market prices to have fixed precision. Eventually, `Amount`s should probably have a configurable (reduced) precision as well. * Parameters being immutable, copying them in the `extra` field is pretty harmless. One could also embed the entire runtime using `Arc<Mutex<ContractRuntime<MyContractState>>` but this is arguably a tradeoff (e.g. any view can now schedule outgoing messages). stacked with linera-io#4971 and linera-io#4972 CI - These changes should be backported to the latest `testnet` branch, then - be released in a new SDK,
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Motivation
The
Amountcan be multiplied byu128usingsaturating_mulbut we don't have an inverse operation. The existingsaturating_divcompute au128ratio between two amounts.Proposal
Amount::saturating_divintosaturating_ratioAmount::saturating_divthat takes a u128 similar tosaturating_mulTest Plan
CI
Release Plan
testnetbranch, then