Skip to content
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

Conversion to and from static arrays #36

Closed
aepsil0n opened this issue Nov 21, 2014 · 6 comments

Comments

Projects
None yet
3 participants
@aepsil0n
Copy link
Collaborator

commented Nov 21, 2014

This is motivated mainly to allow a seamless interaction with piston libraries. Piston internally uses https://github.com/PistonDevelopers/vecmath, which are generic functions on static arrays ([T, ..n] or [[T, ..n], ..m]). Thus to interface with the libraries it is crucial to be able to convert vectors and matrices to and from static arrays seamlessly.

I don't know whether this warrants changing the internal representation to arrays. Transitioning from cgmath I find this a bit cumbersome to work around.

@sebcrozet

This comment has been minimized.

Copy link
Member

commented Nov 21, 2014

Yes, conversion to primitive rust types is something that should be added for the sake of interfacing with the others.

Currently conversion from/to immutable and mutable array references are supported by Mat{1..6}, Vec{1..6}, and Quat (see the methods .as_array[_mut] and .from_array_{ref,mut}).

This is not done for Rot{2..4}, Iso{2..4}, nor UnitQuat. It should be easy enough to add them without any structural change, though everything but their .as_array() method will be tagged as unsafe because an improper input, or the modification of a component, may break some invariant (e.g. the orthogonality of the rotation matrix).

@aepsil0n

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 22, 2014

Oh, I just found them in the source code. That's already very useful… Strangely they are not in the docs. It could indeed be extended to the other types. Should it be wrapped up in a trait?

@sebcrozet

This comment has been minimized.

Copy link
Member

commented Nov 22, 2014

Yes, the online doc seems to be a bit outdated.

I don't think we need to wrap this on a trait as this has no mathematical meaning and I fail to see any use-case for this. Because the shape of the array depends on the converted object, the trait would have to represent it as an abstract type parameter:

trait ArrayCast<A> { ... }

impl<N> ArrayCast<[N, ..3]> for Vec3<N> { ... }
impl<N> ArrayCast<[N, ..4]> for Vec4<N> { ... }

For this case, the exact type of A won't be known in generic code and I don't think you can expect the abstract type Ato be any more useful than the Self type here.

The only use I can think of is as a bridge between the dimension-generic world and the non-generic one, with a function like this:

fn doit<V: ArrayCast<[N, ..4]>, N>( ... ) { ... }

But here you are already assuming that V is a 4D something (Vec4 or Quat), so this does not seem any more useful than directly expecting the exact V type. Also 4D vectors and quaternions have so little in common from the semantic point of view, that it is very unlikely to do anything mathematically sound in a generic way by converting them to a [N, ..4]. For other usages, I guess the user can define himself a trait that holds more semantic than a simple conversion.

@tomjakubowski

This comment has been minimized.

Copy link

commented Aug 17, 2015

Maybe I'm missing something here, but isn't implementing From<[T; N]> and Into<[T; N]> for, say, VecN<T> sufficient?

@sebcrozet

This comment has been minimized.

Copy link
Member

commented Aug 19, 2015

You're correct, implementing those two traits is the way to go! They did not exist (and neither did DSTs) when this issue was created.

sebcrozet added a commit that referenced this issue Feb 18, 2017

sebcrozet added a commit that referenced this issue Feb 18, 2017

sebcrozet added a commit that referenced this issue Feb 18, 2017

@sebcrozet

This comment has been minimized.

Copy link
Member

commented Feb 18, 2017

Into and From are now implemented for matrices and vectors since v0.11.1. For other structures, the user can access their vector or matrix representations (and then use Into and From) if needed. Closing this.

@sebcrozet sebcrozet closed this Feb 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.