4 ms·

Does anyone know if type parameters in Rust can be integers so that you could write vec<3> and get an optimized unrolled implementation of three dimensional vec

Does anyone know if type parameters in Rust can be integers so that you could write vec<3> and get an optimized unrolled implementation of three dimensional vectors without having to hard-code as in vec2, vec3 and vec4, etc? [1] http://static.rust-lang.org/doc/rust.html#type-parameters http://static.rust-lang.org/doc/rust.html#type-parameters [2] https://github.com/Jeaye/q3/blob/master/src/math/vec2.rs https://github.com/Jeaye/q3/blob/master/src/math/vec2.rs [3] https://github.com/Jeaye/q3/blob/master/src/math/vec3.rs https://github.com/Jeaye/q3/blob/master/src/math/vec3.rs [4] https://github.com/Jeaye/q3/blob/master/src/math/vec4.rs https://github.com/Jeaye/q3/blob/master/src/math/vec4.rs

erickt 14y ago
There is not support for this at the moment, but one of core developers mentions one approach for starting to address this need in: http://smallcultfollowing.com/babysteps/blog/2013/04/02/associated-items/ http://smallcultfollowing.com/babysteps/blog/2013/04/02/asso...
AaronFriel 14y ago
What you're actually asking for is dependent types, where instead of passing in a type argument you're passing in a value you're asking to have lifted to the type system. C++ implements this in their templates because templates are rather more dumb than what a "proper" type system would do, because templates are essentially what C++ uses as a powerful macro system. A "Vec<3>" in C++ then is instantiated as a separate class/struct. A "Vector<Int>", if allowed to do it is separately compiled from a "Vector<Double>"[1] and this is what has given templates an uncanny power in C++ as a method of doing very powerful transformations of code, as used by libraries like Eigen to unroll very complex multiple-pass algorithms into a single fast loop. Very neat stuff. I would be a little surprised, actually, to see Rust implement the same feature because the way C++ has done it is by a rather curious and roundabout[2] and it was just happenstance that made it one the first widely used implementations of dependent types. It's strange to think about, but templates are one way C++'s type system is more expressive than Haskell's. (Wow, that felt strange to write.) The associated constant idea is kind of neat, but the implementation of associated constants wildly differs from associated functions[3] and I find it difficult to imagine the way they operate having anything, anything at all to do with one another. If they do implement their associated constants proposal, it'd definitely be something worth following from a type systems perspective because, well, dependent types are one of those things that are curiously difficult to implement, and if they implement it as part of a general type system, it could even be undecidable[4]. [1] This may not be the case now, but it certainly was the case in the past. So this statement is only true to the extent of "very simple C++ compilers" and may not be true of more optimized compilation strategies. I'm not sure what the state of the art is here. [2] And theoretically unsound, in that the macro/template language is be Turing complete. That's not really very desirable from the perspective of being able to share code or doing "compiler as a service" execution where someone could upload infinite loops or non-terminating templated types. http://ubietylab.net/ubigraph/content/Papers/pdf/CppTuring.pdf http://ubietylab.net/ubigraph/content/Papers/pdf/CppTuring.p... [3] In C#, they're called Extension Methods, and they're an instance of the compiler simply being smart enough to find functions that say they can work just like a method of a type, but only depend on an already public API. Extension methods are great because they let you turn regular C# generic types into Monads by adding implementations for Select, SelectMany, and so on and so forth. http://ericlippert.com/category/monads/ http://ericlippert.com/category/monads/ [4] Apologies for the link to wikipedia, but it's the most terse source on it that I can find. It should be noted that just because it's undecidable in some systems doesn't mean it's undecidable in all systems. Let us not make here the mistake of applying Gödel's Incompleteness Theorem to the reals. http://en.wikipedia.org/wiki/Type_system#Dependent_types http://en.wikipedia.org/wiki/Type_system#Dependent_types
- carterschonwald 14y ago
  With ghc 7.4 onwards you can have that style of static dependent types very easily, and it's even nicer still in ghc 7.6 onwards. That particular flavor of dependent types is singleton types. I'm actually leaning on the singleton types and type class machinery in ghc very very hard to write some numerical libraries with both a high level API and very strong code specialization guarantees. A lot of the same stuff could be done with cpp Template programming, but I'd have to worry about a lot more code bloat, a much more inscrutable set of type error messages, and no hope of end users getting good type Inference. There are a rich space of decidable type systems out there leverage some or all of dependent types. The work on idris is very exciting in my novice opinion.
dougk16 14y ago
There would still have to be different hardcoded signatures and implementations for cross-product, transformations and "angleTo"-type methods that you would have to worry about, depending on how complicated your vector class gets. I don't know if there's really a good way to handle those cases generically. So keeping the classes separate might still make sense, even with that feature.
- onedognight 14y ago
  > There would still have to be different hardcoded signatures and implementations for cross-product, transformations and "angleTo"-type methods You are right, those are great test cases for Rust. The cross-product takes n-1 n-vectors are returns an n-vector (orthogonal to the n-1 inputs). The transformations are easy to generalize as affine or homogeneous transformations. A nice features of Rust is that it has macros, so once it has dependent types creating these function with different signatures should be straight forward! I'd hope that like C++, you would be able to add in any extra functions you'd need for specific dimensions.
p0nce 14y ago
I had the very same question. Why is the matrix type hard-coded 4x4 32-bit float?

erickt 14y ago

There is not support for this at the moment, but one of core developers mentions one approach for starting to address this need in: http://smallcultfollowing.com/babysteps/blog/2013/04/02/associated-items/ http://smallcultfollowing.com/babysteps/blog/2013/04/02/asso...

AaronFriel 14y ago

What you're actually asking for is dependent types, where instead of passing in a type argument you're passing in a value you're asking to have lifted to the type system. C++ implements this in their templates because templates are rather more dumb than what a "proper" type system would do, because templates are essentially what C++ uses as a powerful macro system. A "Vec<3>" in C++ then is instantiated as a separate class/struct. A "Vector<Int>", if allowed to do it is separately compiled from a "Vector<Double>"[1] and this is what has given templates an uncanny power in C++ as a method of doing very powerful transformations of code, as used by libraries like Eigen to unroll very complex multiple-pass algorithms into a single fast loop. Very neat stuff. I would be a little surprised, actually, to see Rust implement the same feature because the way C++ has done it is by a rather curious and roundabout[2] and it was just happenstance that made it one the first widely used implementations of dependent types. It's strange to think about, but templates are one way C++'s type system is more expressive than Haskell's. (Wow, that felt strange to write.) The associated constant idea is kind of neat, but the implementation of associated constants wildly differs from associated functions[3] and I find it difficult to imagine the way they operate having anything, anything at all to do with one another. If they do implement their associated constants proposal, it'd definitely be something worth following from a type systems perspective because, well, dependent types are one of those things that are curiously difficult to implement, and if they implement it as part of a general type system, it could even be undecidable[4]. [1] This may not be the case now, but it certainly was the case in the past. So this statement is only true to the extent of "very simple C++ compilers" and may not be true of more optimized compilation strategies. I'm not sure what the state of the art is here. [2] And theoretically unsound, in that the macro/template language is be Turing complete. That's not really very desirable from the perspective of being able to share code or doing "compiler as a service" execution where someone could upload infinite loops or non-terminating templated types. http://ubietylab.net/ubigraph/content/Papers/pdf/CppTuring.pdf http://ubietylab.net/ubigraph/content/Papers/pdf/CppTuring.p... [3] In C#, they're called Extension Methods, and they're an instance of the compiler simply being smart enough to find functions that say they can work just like a method of a type, but only depend on an already public API. Extension methods are great because they let you turn regular C# generic types into Monads by adding implementations for Select, SelectMany, and so on and so forth. http://ericlippert.com/category/monads/ http://ericlippert.com/category/monads/ [4] Apologies for the link to wikipedia, but it's the most terse source on it that I can find. It should be noted that just because it's undecidable in some systems doesn't mean it's undecidable in all systems. Let us not make here the mistake of applying Gödel's Incompleteness Theorem to the reals. http://en.wikipedia.org/wiki/Type_system#Dependent_types http://en.wikipedia.org/wiki/Type_system#Dependent_types

carterschonwald 14y ago
With ghc 7.4 onwards you can have that style of static dependent types very easily, and it's even nicer still in ghc 7.6 onwards. That particular flavor of dependent types is singleton types. I'm actually leaning on the singleton types and type class machinery in ghc very very hard to write some numerical libraries with both a high level API and very strong code specialization guarantees. A lot of the same stuff could be done with cpp Template programming, but I'd have to worry about a lot more code bloat, a much more inscrutable set of type error messages, and no hope of end users getting good type Inference. There are a rich space of decidable type systems out there leverage some or all of dependent types. The work on idris is very exciting in my novice opinion.

dougk16 14y ago

There would still have to be different hardcoded signatures and implementations for cross-product, transformations and "angleTo"-type methods that you would have to worry about, depending on how complicated your vector class gets. I don't know if there's really a good way to handle those cases generically. So keeping the classes separate might still make sense, even with that feature.

onedognight 14y ago
> There would still have to be different hardcoded signatures and implementations for cross-product, transformations and "angleTo"-type methods You are right, those are great test cases for Rust. The cross-product takes n-1 n-vectors are returns an n-vector (orthogonal to the n-1 inputs). The transformations are easy to generalize as affine or homogeneous transformations. A nice features of Rust is that it has macros, so once it has dependent types creating these function with different signatures should be straight forward! I'd hope that like C++, you would be able to add in any extra functions you'd need for specific dimensions.

p0nce 14y ago

I had the very same question. Why is the matrix type hard-coded 4x4 32-bit float?