-
-
Notifications
You must be signed in to change notification settings - Fork 484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complex number support #503
Comments
At least that method should work with any Adding The |
Hey! Sorry for the late answer. I've not read this issue in-depth yet but I just wanted to tell that we agree this is an issue and that this is necessary for improving support of complex number in nalgebra. I will start studying the subject more closely next month. |
@sebcrozet Thank you! I have done some preliminary work on drafting reorganized number traits (eg. a trait for absolute value and a trait for addition, that way you do not need the entire |
Any progress with this? Complex number support would be huge for a lot of linear algebra applications (in my case, for simulating quantum systems). |
@kbarros Yes, I've started worked on it (see also dimforge/alga#57 (comment)). I'll probably have something operational within a couple of weeks. |
@Coder-256 , @kbarros I'm almost done adding full complex number support to nalgebra in #567. This will be merged and released before this month ends. |
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 theReal
trait also apply to complex numbers. It seems to me that many, many parts of nalgebra rely onN
beingReal
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 ofReal
. The same goes for a number of other operations: theReal
trait is overkill and overly restrictive. The solution to this seems to be mainly a change insidealga
: separatingReal
into multiple traits and only requiring the needed traits inimpl
blocks. For example, if the traits were separated intoReal
, whereComplex
is 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_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 theClosedAdd
andClosedMul
traits, whichnum_complex::Complex
doesn't implement.The text was updated successfully, but these errors were encountered: