shailesh1729
commented
9 years ago Actually, Rust standard library (especially traits related to numbers) had been undergoing massive changes during last few months. My code always used to break down. Hence, I put in some traits for keeping the things stable. My new plan is to have a complete hierarchy of traits for groups rings and fields. Then complex and integer types will be implemented as fields. Matrices will be built on any type which is an algebraic structure (say field or ring). Rust's library design has gone towards simplification for numeric traits. Their view is that the standard library doesn't need to address computer algebra thoroughly.
There are some issues for tying against std Num. It presumes that Division is supported. It presumes that values are signed. Suppose I wish to maintain a matrix of unsigned numbers. It won't be possible to do. Suppose I also wish to maintain a matrix of strings. It won't be possible to do. The way I wish to structure the library is that Core Matrix struct supports basic operations of working with a matrix (storage and access of entries in the matrix). Additional operations like addition, subtraction, matrix inverse etc. require additional trait bounds on the type of entries inside the matrix.
I think that this design is more flexible. And since traits give zero cost abstractions, I estimate no loss in the performance either.
Hope this explains.
dovahcrow
http://doc.rust-lang.org/num/num/traits/trait.Num.html would be much better, in my opinion.
and you can impl Num trait for your complex type