rust-num
Implement ops for primitives + Ratios; ops for BigRational + primitives
Before this I was not able to use a primitive as the left-hand side of a core::ops::{Add, Sub, Mul, Div} method where the right-hand side was a Ratio of some type; this implements those. Also, I was not able to use a BigRational on the LHS and a primitive on the RHS of a core::ops::{Add, Sub, Mul, Div} method; this implements those as well (although I'm not sure I'm doing it in the most efficient code). I'm hoping these changes are welcome; I'm pretty new to the num crates and feel like I may have been missing something that should've been obvious.
Initially I'd manually implemented most of this stuff (not using generics), leading me to write a bunch of tests for all of the combinations of types, then refactored to use generics. Thus there's a bunch of tests that should cover all of the cases (hopefully not too many!). In doing so, it really started to feel like maybe some of the ops code could live in a separate file (mainly due to all of the tests), but since I'm not too familiar with this repo I decided to not rock the boat too much.
I've also done very little Rust work with others, so I may be missing some conventions--sorry about that! Please do let me know so I can tidy up accordingly.
Ok, I've got all builds except for the 1.15.0 one passing; I'm not sure how to deal with those {i,u}128 failures though. Any tips would be quite helpful.
When guarding code, please use #[cfg(has_i128)] instead of by feature, so it's still enabled by the build-script detection. For integer literals like 0u128, even guarded code becomes a problem since it still has to parse by the old compiler. You can let type inference handle it in some cases, like if calling fn foo(x: u128) then foo(0) is fine. In other cases you might have to assign a local first, let x: u128 = 0, which still parses on the old compiler even though it doesn't know that type.
Ah, thank you @cuviper, that was super helpful (and makes total sense). Fixed all of those.
The other failures seem to have to do with isize::from() not being implemented for u8 and i16 until 1.26.0. I'm not really sure how to fix those tests (they seem relevant for current versions) so I've just commented them out (don't really like doing that) and left a TODO. I can remove these or whatever seems preferable, just let me know.
Are there any problems with this PR? Just wondering as I have some other changes I'm curious about making, but they sort of build on the changes here and I don't want to get too far along there if there are problems here. TIA
No problems AFAIK -- I was just on vacation and haven't come back to look at this again. I'll try to review it soon!
@cuviper oh, nice! I mostly just wanted to give it a bump so it doesn't die. Thanks!
@cuviper thanks for the review! I hope to get to responding to all the things in the new few days. 🍻
I just remembered this PR and wanted to pop in and say that I had to backlog the work I was doing that depended on these changes. That work is still in my (day job) backlog but I’m not sure when I’ll get time to pick it back up.
Just wanted to give this a bump as I noticed the lack of primitive support as well. I have been creating Ratios from the integers to to the the math, but I don't think it's a great solution. If it would help, I might be able to take a look at the requested changes for this PR and see what I can do.
