Open
Description
at the moment, all the core arithmetic operations for Complex
require the Num
bound to be satisfied
https://docs.rs/num-complex/latest/num_complex/struct.Complex.html#impl-Add-for-Complex%3CT%3E
this is stronger than it needs to be, and implementing that can be difficult for new numerical types like qd::Double<f64>
, due to the Num::from_str_radix
being nontrivial to implement
would it be acceptable to relax the constraint to Add<Output = Self>
for addition, Sub<Output = Self>
for subtraction, and Mul<Output = Self> + Add<Output = Self> + Sub<Output = Self>
for multiplication?
Activity
cuviper commentedon Mar 11, 2024
I think we can do that safely, without any breaking change even, but I do worry about relaxing too far. Relaxing in one direction becomes a limitation in the other, that it leaves little room for making new implementation choices. Plus, a long list of constraints is more of a burden for both the reader and the maintainer.
Maybe we should just add a local trait like:
That is everything from
Num
except forfrom_str_radix
. The only place we actually use that method is when implementing it forComplex
itself. We might also want to split outNumOps
and dropRem
, since that's pretty weird forComplex
, and we only use it for our ownRem
and fordiv_trunc
.I think it's also fine if a type only implements
Num::from_str_radix
for "easy" radices at first, or even an unconditionalErr
if it's really too hard.redweasel commentedon Apr 12, 2025
please do this. I don't see, why addition is not allowed for types which e.g. don't implement division (because they are from a mathematical ring like exact integers).
Although one must be a bit careful to avoid recursive definitions, which appear quickly when doing this.