Skip to content

Find a better way of representing complex numbers types in Rust #72

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

Closed
emilio opened this issue Oct 2, 2016 · 3 comments
Closed

Find a better way of representing complex numbers types in Rust #72

emilio opened this issue Oct 2, 2016 · 3 comments

Comments

@emilio
Copy link
Contributor

emilio commented Oct 2, 2016

I plan to land parsing and code generation support for complex types. My initial plan is landing it as a constant array of items, but that doesn't mean we can't do better.

We'd need to add a new TypeKind::Complex(ItemId), then use that to represent complex types. Then, at code generation, we can do something like what we do with unions, and conditionally prepend a prelude that might look like:

#[repr(C)]
#[derive(ABunchOfThings)]
struct __BindgenComplex<T> {
    real: T,
    imaginary: T,
};

With arithmetic operations on top of it.

@emilio
Copy link
Contributor Author

emilio commented Oct 2, 2016

The TypeKind::Complex differentiation will also be needed to correctly pass complex types by value to functions, since otherwise right now they'll get converted to pointers.

@jeanphilippeD
Copy link
Contributor

Hello,
Should we rely on num-complex if we want the arithmetic?
Then the prelude would be:

extern crate num_complex;
use num_complex::*;

Otherwise, we could also provide a compatible, dumb generic if we want to limit dependencies (the arithmetic seems quite involved). then the prelude would be:

#[derive(PartialEq, Copy, Clone, Hash, Debug, Default)]
pub struct __BindgenComplex<T> {
    pub re: T,
    pub im: T
}

Would that make sense?
Which option would be best?

I'd be interested in trying to add one option.
Thanks,
JP

@emilio
Copy link
Contributor Author

emilio commented Nov 6, 2016

I think avoid bindgen dependencies is nice, so I think I'd prefer the second option. Also, we can't rely on num_complex having the expected representation (the type needs to be repr(C)), and anybody that needs the arithmetic can do a straight-forward conversion from our representation to num_complex's.

So yeah, definitely the second option is preferred. If you need any help, please shout out, I'll be happy to help. Should be straight-forward (sort of what we do for union fields).

jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 8, 2016
C complex only exists for floating point types.
C Complex are built in types

The global variable and struct members have different path
to set saw_complex.
jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 8, 2016
C complex only exists for floating point types.
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72

The global variable and struct members have different path
to set saw_complex.
jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 10, 2016
C complex only exists for floating point types.
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72

Handle all the different way a complex can be present in
BindgenContext setting saw_complex.
jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 10, 2016
C complex only exists for floating point types.
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72

Handle all the different way a complex can be present in
BindgenContext setting saw_complex.
jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 10, 2016
C complex only exists for floating point types.
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72
We test global long double _Complex because it does not require
layout tests.

Handle all the different way a complex can be present in
BindgenContext setting saw_complex.
jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 11, 2016
C complex only exists for floating point types.
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72
We test global long double _Complex because it does not require
layout tests.

Handle all the different way a complex can be present in
BindgenContext calling generated_bindegen_complex to indicate
that __BindgenContext will need to be added.
jeanphilippeD added a commit to jeanphilippeD/rust-bindgen that referenced this issue Nov 11, 2016
C complex only exists for floating point types.
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72
We test global long double _Complex because it does not require
layout tests.

Handle all the different way a complex can be present in
BindgenContext calling generated_bindegen_complex to indicate
that __BindgenContext will need to be added.
bors-servo pushed a commit that referenced this issue Nov 11, 2016
Use __BindegenComplex for C Complex

 Fix #72

C complex only exists for floating point types
C Complex are built in types

long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72
We test global long double _Complex because it does not require
layout tests.

Handle all the different way a complex can be present in
BindgenContext calling generated_bindegen_complex to indicate
that __BindgenContext will need to be added.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants