-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support fraction multiply floor/ceil #1566
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💪
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can probably avoid the need for the second macro argument
At the moment, there are two blockers for implementing this macro for Uint512's: 1 - It does not implement
Any thoughts on the Uint512 case? |
Yes, sorry I forgot to mention explicitely. Forget about that one. The only purpose for Uint512 is being the full_mul result of Uint256. If we don't stop there, the chain goes on endlessly. The implementations that matter are Uint64. Uint128 and Uint256. |
Any thoughts on extending this to also support dividing?
The implementation would simply be |
Why do you think so? None here represents the only possible error case (div by zero). This is what the Rust standard library math does as well. However, in our case we often use Results as well because there are multiple error cases. It's a bit inconsistent right now. |
Sounds straight forward. This has not been requested yet but why not. |
Dividing support added. Turns out we cannot just do
I'd say that's treating an Option as if it were a Result. The Result struct is quite good and has built in support for the kinds of handling you'd need to do if it were to raise. On tests: Also, it is bad that mul_floor/mul_ceil/div_floor/div_ceil is reserved for fraction math? Could this pose a problem later? Should it be instead something like |
Good point
I like that take. It's a good way to do things differently than what the standard library does. It also comes with the following advantages:
Yeah, right. I got used to it. I think a big advantage of having them in the same file is being able to test private function. I'd keep it that way for now.
I think this is fine. All same type arithmetic can go into operator overloading. And if we really need something else later, we can reconsider. |
Think we are feature complete with this PR. Let me know if there's anything else or if we need a second reviewer or can merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff, thanks a lot. Great test coverage ❤️
What I see missing is:
- A basic rust doc for each new function in the macro
- A changelog entry to the Unreleased section
- The implementation suggestion mentioned inline
If we can finalize this PR this week, it can be shipped as part of CosmWasm 1.2. I'll prioritize it accordingly.
8925d4e
to
9199c53
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎖
9199c53
to
3cf3c67
Compare
Oh shoot, tried to sync the fork to fix the merge conflict. Will fix now. |
bec0330
to
d8c52e5
Compare
PR to implement thoughts from: #1485 (Uint * Fraction arithmetic)