Complex numbers #3892
Complex numbers #3892
Conversation
ehuss
added
the
T-libs-api
joshtriplett
added
the
T-lang
|
Labeling this T-lang because the desire to make this FFI-compatible is a lang matter. |
joshtriplett
added
the
I-libs-api-nominated
text/3892-complex-numbers.md
Outdated
| ```rust | ||
| let y = Complex::from_array([3, 4]); | ||
| ``` | ||
| or as a tuple: | ||
| ```rust | ||
| let z = Complex::from_tuple((3, 4)); | ||
| ``` |
There was a problem hiding this comment.
i think impl<T> From<(T, T)> for Complex<T> and impl<T> From<[T; 2]> for Complex<T> would be sufficient. it's like there is no SocketAddr::from_tuple.
There was a problem hiding this comment.
This still exists. @scimind2460 please make sure you adequately address review concerns before marking topics as resolved, or leave them open for the the commenter to mark resolved themselves. If you're not sure, leave a comment.
|
It's worth pointing out another big issue with this is that the canonical In particular, while I'm not super compelled by the argument that C supports this, therefore the standard library needs to support this. I think that guaranteeing a |
I think that polar form almost always is the more optimal form, at least in my experience. But the ABIs do use rectangular, e.g. from x86:
so it makes sense that an interchange type matches that, and users can translate to/from a polar repr at the FFI boundary if needed. But this reasoning is definitely something to have in the RFC's rationale & alternatives. |
|
Right: I guess my main clarification here was that due to the polar-orthogonal discrepancy, it shouldn't be a canonical Rust type (e.g. |
|
Thanks everyone for the feedback! I have incorporated as much as I can into the RFC. |
text/3892-complex-numbers.md
Outdated
| impl Complex<f64> { | ||
| fn angle(self) { | ||
| f32::atan2(self.re(), self.im()) | ||
| } | ||
| fn from_polar(modulus: f32, angle: f32) -> Complex<f32> { | ||
| Complex::new(modulus * f32::cos(angle), modulus * f32::sin(angle)) | ||
| } | ||
| } |
There was a problem hiding this comment.
Probably want to return something here? And not use the f32 types for f64
That being said: I think polar conversions should be put into "future possibilities" since they aren't needed for basic support.
There was a problem hiding this comment.
I was trying to write something to help with @clarfonthey's polar proposal, but if they are fine with this becoming a future possibility, then OK!
There was a problem hiding this comment.
Agreed that they should be moved to "future possibilities" for now.
Clarify future support for Gaussian integers and floating point types in the RFC.
Co-authored-by: Kevin Reid <[email protected]>
Clarified the rationale for a unified API for complex numbers and addressed compatibility issues with C libraries. Updated examples and alternatives to improve understanding of complex number implementations.
Co-authored-by: Kevin Reid <[email protected]>
|
I would like @cuviper (as the author of num-complex) to review the proposed API here. |
Refactor Complex struct to have public fields and update methods for real and imaginary parts. Added notes on future considerations for polar conversions and arithmetic implementations.
Co-authored-by: Josh Triplett <[email protected]>
cuviper
left a comment
cuviper
left a comment
There was a problem hiding this comment.
I apologise in advance to
num-complex
No worries! There are definitely things that a compiler-integrated implementation can do better, especially with ABI as you've highlighted. A lot of the num-complex API is also limited by trying to be so generic, whereas the standard library can choose to keep all the implementation flexibility for itself.
Co-authored-by: Jacob Lifshay <[email protected]>
text/3892-complex-numbers.md
Outdated
| ```rust | ||
| let y = Complex::from_array([3, 4]); | ||
| ``` | ||
| or as a tuple: | ||
| ```rust | ||
| let z = Complex::from_tuple((3, 4)); | ||
| ``` |
There was a problem hiding this comment.
This still exists. @scimind2460 please make sure you adequately address review concerns before marking topics as resolved, or leave them open for the the commenter to mark resolved themselves. If you're not sure, leave a comment.
text/3892-complex-numbers.md
Outdated
| You can even calculate the complex sine, cosine and more: | ||
| ```rust | ||
| let val = Complex::new(3.0, 4.0); | ||
| let sine_cmplx = csin(val); // 3.8537380379 - 27.016813258i | ||
| ``` |
There was a problem hiding this comment.
Delete this, mention trig and further functions in future possibilities instead. We wouldn't have a freestanding csin function anyway.
text/3892-complex-numbers.md
Outdated
| fn div(self, other: Self) -> Self::Output; | ||
| } | ||
| ``` | ||
| The floating point numbers shall have sine and cosine and tangent functions, their inverses, their hyperbolic variants, and their inverses defined as per the C standard and with Infinity and NaN values defined as per the C standard. |
There was a problem hiding this comment.
Move this to future possibilities.
|
I'd love to see an FCP kicked off for this, as soon as the open comments are addressed on the RFC (extra functions that need to move to future possibilities, and the inaccurate background information on nalgebra). |
Co-authored-by: Trevor Gross <[email protected]>
Co-authored-by: Trevor Gross <[email protected]>
Removed redundant statement about overhead from libgcc calls and clarified the purpose of the Complex type.
|
Hopefully I've cleared up everything to satisfaction. I suppose it's broadly reasonable to FCP? |
19 participants
This RFC proposes FFI-compatible complex numbers to help scientific computing library authors use non-indirected complexes.
I apologise in advance to
num-complexRendered