-
Notifications
You must be signed in to change notification settings - Fork 16
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 remaining arithmetic operations #32
Comments
as a starting point, here's a list of methods currently implemented for checked versions of existing operations
unchecked versions of existing operations
wrapping versions of existing operations
overflowing versions of existing operations
saturating versions of existing operations
carrying versions of existing operations
neg
rem
rem_euclid
add_signed
div_euclid
ilog
pow
next_multiple_of
power_of_two
other unimplemented operations
|
Thanks a lot for collecting those! |
@danlehmann I can implement some of these if that's okay with you. on that note, is there a reason why |
Yes of course, happy to take patches for those! I have been thinking about those a bit, so I wanted to write down my thoughts. For many operations we can defer to the underlying type, e.g. wrapping_add should be straight-forward: just add and apply the MASK. wrapping_xxx likely needs a two-step process though: 1. Do the wrapping_xxx instruction of the underlying type and b) do a try_new and - if error - consider that a wrap as well. But I think for some things we can do better:
|
Just an oversight
I put in whatever was needed at the time. At some point the Number trait simplified things somewhat though, so maybe some of those aren't needed any longer. If you find any unnecessary ones, removing should be safe from an api stability viewpoint |
I implemented a good chunk of them: Mul, MulAssign, Div, DivAssign as well as all wrapping_xxx and saturating_xxx: For each instruction there are some interesting optimizations: E.g. u4 * u4 can never overflow the underlying u8, where u5*u5 can. I tried to implement those (which are compiler checked) whenever reasonable. Will do overflowing_xxx and checked_xxx soon as well. |
Skipping unchecked_xxx. They are all unstable for now. In the patch I just referenced I also implemented checked_xxx and overflowing_xxx. Once that's in, the list of missing operations should be a lot smaller |
* Implement Mul, MulAssign, Div, DivAssign Small step towards #32 * Implement wrapping_xxx; fix Shl/Shr semantics in debug builds - Implement `wrapping_add`, `wrapping_sub`, `wrapping_mul`, `wrapping_div`, `wrapping_shl`, `wrapping_shr` - In debug builds, `<<` (`Shl`, `ShlAssign`) and `>>` (`Shr`, `ShrAssign`) now bounds-check the shift amount using the same semantics as built-in shifts. For example, shifting a u5 by 5 or more bits will now panic as expected. * Add saturating_xxx * Addressed comments * Fix build in debug mode * Add checked_xxx and overflowing_xxx * List all new methods
Landed #39. This leaves the following: unchecked versions of existing operations
carrying versions of existing operations
neg
rem
rem_euclid
add_signed
div_euclid
ilog
pow
next_multiple_of
power_of_two
other unimplemented operations
|
Basic types like u32 have plenty more operations, like:
And plenty more. All of those should be supported.
Some of that is already supported through num_traits, but a) not everyone might want that dependency and b) that is only a subset of the functionality.
The text was updated successfully, but these errors were encountered: