Open tbetcke opened 1 year ago
Is ability to parse and implementing Rem
that onerous? C99 math.h
has remainder()
and I assume it can always be implemented (perhaps not efficiently). Is it worth making a trait that is not equivalent?
The Num trait also requires conversion from String. But agree. Maybe too little difference to design our own type. However, we will need a complex trait on top of this that can distinguish between real and complex numbers (cauchy
is a good package but does not have a separate trait for just real numbers, which makes. a lot of things cumbersome).
Hmm, I think you can ensure real only by restricting that S::Real
is the same as S::Complex
, which you can do via a trait bound. I don't know if that has side-effects versus creating an explicit Real
trait.
Checking for equality of real and complex type is a good idea. With respect to a scalar trait I have now added a proposal into #4.
How should we define the scalar trait? I'd like to keep it very general. It would be cool for example to support operators over finite fields, etc.
The
Num
create provides a fairly generic numerical trait: https://docs.rs/num-traits/latest/num_traits/trait.Num.html.However, this still requires a bit too much (e.g. it has string conversion and NumOps has remainder computations).
What do we minimally want to support for scalar fields? Initial suggestions:
Should we have less or more?
Also, it may be useful to have a separate complex trait that implements the above operations but whose real and imaginary parts are again numerical traits with the above property.