Support Complex number

[Axect]

Still peroxide supports only real number. But for many cases, complex number, vector & matrix should be required.

• Integrate num_complex::Complex<F>
• Complex vector
  • Re-design Vector traits
  • crate::traits::math::{Vector, Normed, InnerProduct, LinearOp, VectorProduct}
  • crate::traits::fp::FPVector
• Complex matrix
  • Implement almost all of Matrix
  • Integrates LAPACK complex subroutines

[GComitini]

Hi @Axect. I am interested in this feature. At the moment I am using a fork of peroxide for my research which supports complex integration (by which I mean integration of complex functions of a real variable). My implementation, though working, is trivial (I wrote it without giving it much thought), so I don't believe it is upstreamable, but I am willing to work on a more suitable implementation that I can submit to you if you give me directions on what you would expect. To abandon my fork I would need full support of complex numbers, but since - as I said - complex integration is all I am using at the moment, this would be a great starting point for me. Best.

[Axect]

Hi @GComitini. Thank you for your interest in the complex number support for Peroxide. I appreciate your willingness to contribute to the project.

Currently, Peroxide doesn't have any support for complex numbers, but I do have plans to add this feature in the future. For matrices and vectors, I'm considering implementing separate CMatrix and CVector types to handle complex numbers.

However, for other operations like root finding, solving differential equations, and numerical integration, I don't have a clear idea yet on how to best implement complex number support. I'm open to suggestions and ideas from the community.

One approach I'm considering is to create a separate complex module within Peroxide and implement all complex number-related functions and structs there. (e.g. src/complex/matrix.rs, src/complex/integral.rs, and etc.) This would provide a clear separation between real and complex number functionality, improve code organization, and allow users to opt-in to complex number support when needed.

As a first step, I plan to create the complex module and implement some basic complex number-related functions. It would be greatly appreciated if you could contribute by implementing the complex integration functionality you're currently using within this module, perhaps in a file named integral.rs.

Regarding the namespace, although I intend to keep it separate from fuga and prelude, it might be a good idea to differentiate the names slightly for potential compatibility reasons. For example, using names like CMatrix and cintegral. However, this is still in the conceptual stage, so if you have any better ideas, please feel free to share them.

Implementing complex number support incrementally, starting with the most essential functions and gradually expanding, would be a pragmatic approach. This would also allow for better testing and refinement of the complex number implementations.

I would be happy to collaborate with you and other interested contributors to design and implement complex number support in Peroxide. We can discuss ideas, share experiences, and work together to create a robust and user-friendly complex number module.

Please feel free to share your thoughts, suggestions, or any specific ideas you have in mind. I'm excited to work with the community to bring complex number support to Peroxide.

Best regards,
Axect

[GComitini]

Hi @Axect. I think creating a complex module within the main namespace of the crate is a good idea (I see you've already implemented it in the dev branch!). Something that needs to be sorted out, I think, is code duplication. For example, as you can see here, what I'm doing to compute complex integrals is basically copy-pasting real functions and changing their return type (an exception would be complex_newton_cotes_quadrature, where I need to compute the Lagrange polynomial twice, one for the real part of the integrand and one for its imaginary part). While this is not a problem in the context of my fork, I think duplicating code this way may soon become not so manageable within peroxide itself. If you're fine with having such a duplication (at least until a better solution is found) then I may already contribute with a src/complex/integral.rs. Otherwise I think we should first figure out some kind of generics, such as a common trait, so that functions are implemented once and for all when possible.

[Axect]

Hi @GComitini,

Thanks for suggesting the use of generics to reduce duplication in the complex number integration functions. I appreciate your input.

I've been considering how to make functions like newton_cotes_quadrature generic for both real and complex numbers. The main challenge I see is with the lagrange_polynomial function, which would need to support complex coefficients in the Polynomial struct. I'm not sure if this would be beneficial or if it could impact performance. What are your thoughts?

If there's a way to implement generics without major changes to existing structs, I would be open to that. It could be a good solution.

No definite decision has been made yet, and I'm always open to suggestions and discussions. Your ideas are highly valued and appreciated.

Thank you again for your contribution. I value your thoughts and look forward to continuing our discussion.