Type-checked matrix operations in Rust
jadpole.github.io
Type-checked matrix operations in Rust
1–10 of 20 posts
Re: Type-checked matrix operations in Rust
#2Lately I've been playing around with static dimensional analysis in Rust. The overall idea is similar: Use PhantomData to add a type parameter and define an empty struct for each unit. So you might end up with, say, Scalar or Vec3.
Dividing and multiplying units statically is where I've had trouble so far. I think I've found a way, but it would depend on negative trait bounds, as discussed here:
https://github.com/rust-lang/rfcs/issues/1053
Ideally, I'd like to be able to do something like this:
let a: Scalar = Scalar::new(2.0);
let b: Scalar = Scalar::new(3.0);
let c: Scalar = a / b;
// Watts is a type synonym for Over.
// Other derived units would use Times. E.g.:
type Pascals = Times>.Re: Type-checked matrix operations in Rust
#3For an example of a similar technique in Nim: https://github.com/unicredit/linear-algebra/
If I understand correctly the author remark about the lack of Rust support for value parameters, it seems that it should be equivalent to the Nim feature (static[int]) that has allowed me to write type-checked matrix operations there
Re: Type-checked matrix operations in Rust
#4For assorted type system/PhantomData madness, see also:
http://maniagnosis.crsr.net/2015/07/abstracted-algebra-in-ru...
http://maniagnosis.crsr.net/2015/07/more-abstracted-algebra-...
Re: Type-checked matrix operations in Rust
#5Lately I've been playing around with static dimensional analysis in Rust. The overall idea is similar: Use PhantomData to add a type parameter and define an empty struct for each unit. So you might end up with, say, Scalar or Vec3 . Dividing and multiplying units statically is where I've had trouble so far. I think I've found a way, but it would depend on negative trait bounds, as discussed here: https://github.com/r…
But what makes Times, Meter> the same as Times>?
Re: Type-checked matrix operations in Rust
#6Lately I've been playing around with static dimensional analysis in Rust. The overall idea is similar: Use PhantomData to add a type parameter and define an empty struct for each unit. So you might end up with, say, Scalar or Vec3 . Dividing and multiplying units statically is where I've had trouble so far. I think I've found a way, but it would depend on negative trait bounds, as discussed here: https://github.com/r…
But what makes Times , Meter> the same as Times >?
Canonicalization is tough, and requires you to define some common ordering on your units.
Systems will use an array of unit powers, so that if the array were defined as , then acceleration would be and watts would be . Addition and subtraction require that your arrays are equal, and multiplication and division are pairwise additive/subtractive.
Re: Type-checked matrix operations in Rust
#7Lately I've been playing around with static dimensional analysis in Rust. The overall idea is similar: Use PhantomData to add a type parameter and define an empty struct for each unit. So you might end up with, say, Scalar or Vec3 . Dividing and multiplying units statically is where I've had trouble so far. I think I've found a way, but it would depend on negative trait bounds, as discussed here: https://github.com/r…
But what makes Times , Meter> the same as Times >?
Great question. I believe each unit struct would need to implement PartialEq or something similar. That would define the canonical nesting order. Alphabetical would make sense.
We would to resolve the nesting during multiplication and division. For example:
let a: Scalar> = Scalar::new(10.0);
let b: Scalar>> = Scalar::new(5.0);
let c: Scalar>>> = a * b;
Re: Type-checked matrix operations in Rust
#8Earlier quoted context omitted.
But what makes Times , Meter> the same as Times >?
Canonicalization is tough, and requires you to define some common ordering on your units. Systems will use an array of unit powers, so that if the array were defined as , then acceleration would be and watts would be . Addition and subtraction require that your arrays are equal, and multiplication and division are pairwise additive/subtractive.
Will the Rust compiler ever understand numbers in types? I.e. will the numbers ever be more than just part of the string that is the type name? If not, then I don't know how possible powers will be. Maybe the solution would be to define some types for commonly-used powers, e.g. PowN4, PowN3, PowN2, PowN1, Pow2, Pow3, Pow4. Users who needed higher powers could define those types themselves, I guess.
Re: Type-checked matrix operations in Rust
#9Earlier quoted context omitted.
But what makes Times , Meter> the same as Times >?
Canonicalization is tough, and requires you to define some common ordering on your units. Systems will use an array of unit powers, so that if the array were defined as , then acceleration would be and watts would be . Addition and subtraction require that your arrays are equal, and multiplication and division are pairwise additive/subtractive.
Is it tough? There are only seven fundamental units. https://en.wikipedia.org/wiki/SI_base_unit
Just represent every unit in terms of them then it's good.
One problem with the array you came up is that the units are not orthogonal, since Joules = Newtons * Meters.
Re: Type-checked matrix operations in Rust
#10Ok this is seriously amazing (coming from a C++ guy). However, one thing I don't like with putting matrix dimensions in templates is that then you can't construct them at runtime. I do understand the obvious - that you can't have both static type checks on all operations and runtime-determined matrix sizes. Though I would kill for a language which would specialise my code at runtime and throw an exception for compilation errors. So you could write, e.g.
template
Matrix
mul(Matrix lhs, Matrix rhs)
{...impl...}
int m, n, k, l = ... read from file or whatever
Matrix m1 = ...;
Matrix m2 = ...;
try {
Matrix m3 = m1 * m2;
// ^ code compiled dynamically
// or loaded from cache, based on
// runtime types of m1 and m2.
// o and p set to the result
// of type inference.
// I could imagine even having
// specialised versions with inline
// assembly for specific dimensions.
} catch (DynamicCompilationException e) {
print("dimensions not compatible");
}
Or you could abuse the invoke dynamic feature - create specialised functions matrixMultiply$m$n$l and classes Matrix$m$n from some other templating language as needed, then do an invoke dynamic based on type. But this would be very cumbersome to use, I think.