Currently, the Real trait pops up 846 times in a search. In the vast majority of those cases, there is no reason why a complex number would not work. Certain operations such as floor/ceil, inequalities, etc. only make sense on real numbers, but the vast majority of functions defined by the Real trait also apply to complex numbers. It seems to me that many, many parts of nalgebra rely on N being Real despite only relying on functions that also make sense for complex numbers. For example, it is impossible to get the norm of a matrix with complex numbers, which is almost a deal breaker for me for the entire library:
https://github.com/rustsim/nalgebra/blob/0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2/src/base/matrix.rs#L1265-L1283
(As a workaround, I am currently just copy-pasting the above code into my project, which works just fine even for complex numbers).
This operation does not require a real number at all, nevertheless all of the numerous requirements of the Real trait, including the 'static lifetime. If I understand correctly, this means that any number put into a matrix will be leaked and never deallocated; and this is just one requirement of Real. The same goes for a number of other operations: the Real trait is overkill and overly restrictive. The solution to this seems to be mainly a change inside alga: separating Real into multiple traits and only requiring the needed traits in impl blocks. For example, if the traits were separated into Real, where Complex is the supertrait of Real, then taking the norm of a matrix would be constrained to Complex, allowing for both real and complex numbers. This would seem to fix #281 and a number of other problems with complex numbers.
This is no small task as it would require manually going through much of the library and updating trait constraints, but I believe that it is an important and necessary change. I think that this should at least be an RFC, both for whether making this change is important or not, and what exactly the new traits would be.
EDIT: That was a bad example, I just saw the rusty_machine branch and c531a34 in #499 😄. However this is still an issue until that is merged, and for many other algorithms and operations. But don't let this issue block #499 because this might require some discussion and work to implement for any changes that are agreed on.
EDIT 2: Actually, it's still not fixed on the rusty_machine branch, and now for some reason copy-pasting the code doesn't work with that branch because the dot product now requires the ClosedAdd and ClosedMul traits, which num_complex::Complex doesn't implement.
Currently, the
Realtrait pops up 846 times in a search. In the vast majority of those cases, there is no reason why a complex number would not work. Certain operations such as floor/ceil, inequalities, etc. only make sense on real numbers, but the vast majority of functions defined by theRealtrait also apply to complex numbers. It seems to me that many, many parts of nalgebra rely onNbeingRealdespite only relying on functions that also make sense for complex numbers. For example, it is impossible to get the norm of a matrix with complex numbers, which is almost a deal breaker for me for the entire library:https://github.com/rustsim/nalgebra/blob/0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2/src/base/matrix.rs#L1265-L1283
(As a workaround, I am currently just copy-pasting the above code into my project, which works just fine even for complex numbers).
This operation does not require a real number at all, nevertheless all of the numerous requirements of the
Realtrait, including the'staticlifetime. If I understand correctly, this means that any number put into a matrix will be leaked and never deallocated; and this is just one requirement ofReal. The same goes for a number of other operations: theRealtrait is overkill and overly restrictive. The solution to this seems to be mainly a change insidealga: separatingRealinto multiple traits and only requiring the needed traits inimplblocks. For example, if the traits were separated intoReal, whereComplexis the supertrait ofReal, then taking the norm of a matrix would be constrained toComplex, allowing for both real and complex numbers. This would seem to fix #281 and a number of other problems with complex numbers.This is no small task as it would require manually going through much of the library and updating trait constraints, but I believe that it is an important and necessary change. I think that this should at least be an RFC, both for whether making this change is important or not, and what exactly the new traits would be.
EDIT: That was a bad example, I just saw the
rusty_machinebranch and c531a34 in #499 😄. However this is still an issue until that is merged, and for many other algorithms and operations. But don't let this issue block #499 because this might require some discussion and work to implement for any changes that are agreed on.EDIT 2: Actually, it's still not fixed on the
rusty_machinebranch, and now for some reason copy-pasting the code doesn't work with that branch because the dot product now requires theClosedAddandClosedMultraits, whichnum_complex::Complexdoesn't implement.