Use rust-lang/num instead of stainless-steel/complex?

[astraw]

Hi,

It seems that the num crate is quite heavily used, with >100k downloads over all time and thousands in the past weeks alone. In comparison, the complex crate has less than 1.5k downloads over all time. Therefore it seems to me that num is the de-facto standard for complex numbers and another module is likely going to lead to unnecessary code bloat and casting.

Are there any compelling reasons to stick with complex rather than switching to num? I'm not aware of any, but neither have I looked particularly deeply at the issue. Otherwise, I would propose moving to the num create. If there are features missing from num, I suppose the devs would welcome implementation of those missing features.

Another point is that, because num defines their Complex type as a generic for type T, it would be easier to implement support for different types as suggested in #6.

/// A complex number in Cartesian form.
#[derive(PartialEq, Copy, Clone, Hash, Debug)]
#[cfg_attr(feature = "rustc-serialize", derive(RustcEncodable, RustcDecodable))]
pub struct Complex<T> {
    /// Real portion of the complex number
    pub re: T,
    /// Imaginary portion of the complex number
    pub im: T
}

Finally, for maintaining compatibility in client code that uses complex::c32 and complex::c64, the following functions or similar could be used to implement the relevant cast:

extern crate num;
extern crate complex;
use std::mem::transmute;

#[inline]
fn to_complex_c32(x: & mut [num::Complex<f32>]) -> & mut [complex::c32] {
    unsafe { transmute(x) }
}

#[inline]
fn to_complex_c64(x: & mut [num::Complex<f64>]) -> & mut [complex::c64] {
    unsafe { transmute(x) }
}

[IvanUkhov]

Hi,

I knew this issue would come up one day) I originally didn’t want to bring in such a heavy package as num for such a small thing as complex numbers; it seemed heavy, and it was pulling in a lot of unrelated dependencies. I guess I have no choice but acquiesce. num is a de facto standard, as you mentioned, and it indeed makes sense to leverage what has already been widely adopted instead of inventing something that people won’t use anyway.

How about this patch for blas and a similar one for lapack?

Regards,
Ivan

[astraw]

This is great - it simplifies my code a lot to only support one implementation.

[IvanUkhov]

Published. Thanks!