If the primary reason for putting this in std is the C ABI, could this start as a type in std::ffi::c_complex?
1 Like
I don't think that's the primary reason; the other reason is common vocabulary for Rust API.
2 Likes
I've implemented complex numbers myself for a Rust program, and have a word of caution: rounding is a difficult problem when operating on complex numbers, both in terms of getting the correct result and in terms of even specifying what the desirable behavior is (there is more than one reasonable way to define it). Modulo and gcd are particularly difficult to specify sensibly (modulo is connected to the way that division rounds, which is two-dimensional; and gcd has four possible signs for the result, and often none of them are "positive" which is what you'd usually want). This is probably fixable, but needs to be thought about in advance in order to avoid causing problems later.
Isn't that mostly for Gaussian integers? This RFC has been limited to floating points for now.
Modulo and GCD are both definable on floating-point numbers (but require reasoning about integers to define them), and modulo is supported by floating-point real numbers in Rust at the moment (so people would probably expect it to work on complex numbers too, although perhaps it could be left out of an initial implementation).
Rounding is also very relevant for floating-point numbers in general, anyway (including complex floats) – they're quantized in the same way that integers are (and in some ranges support only integer values).
Shouldn't there be two complex types also: cartesian and polar?
(Also, is the concept of integers in the complex plane even well defined? That will work differently between cartesian and polar. )
Polar isn't really useful for calculations, so I'd just expect to see functions abs and theta for calculating the polar form.
1 Like