Can verify. If you are doing production work with coordinate transforms strongly typing your points to their coord sys and _not_ allowing implicit conversion is a win.<p>I’ve not used this library (not Rust very much) but the principle is simple to implement and advisable to use whatever typed language you use. So; don’t store northing-easting pairs to vec2. Create a type for it. And call the other value northing, and the other easting. Implement all the algebra you need. I guarantee this will save you from so many headache causing bugs.
I've done something similar at $WORK for a small project in C++, and I found it extremely helpful in building trust in calculations. Once you do something like this it feels almost insane to do it the typical way where all the calculations are basically manually inlined. Working on robotic systems you're nearly guaranteed to run into a convention mismatch that causes a bug and strong typing it helps eliminate most classes of these bugs (except when you have dynamic frames, but then you can use a dynamic frame tree registry). I need to see if I can open source it.<p>Just using strong typing to separate the notion of a "position" (looks like it's Cooordinate in sguaba's parlance) from a "vector" alone saves a lot of headaches in making illegal operations like adding two positions.
This is awesome. I think a problem to wider adoption of this is going to be verification.<p>This would be very useful for the aerospace industry. However the reason they still use things like MATLAB is less about “the best software in terms of efficiency or modern code structures is the stability and backing of it. I’ve seen stacks that are matlab transcompiled to Fortran loaded onto aircraft…as late as 2015.<p>The other detail, and without reading the documentation fully, is variable accuracy in types would be something interesting to have as a controlled set of options.
Can confirm. Been working on a spaceship colony game still in prototype phase, the code isn't too clean to begin with. Ended up asking the AIs for typed Vector3 in C#, which gave me a starting point.<p><a href="https://gist.github.com/mrkybe/efa70a9ddcba7b5bfe441dafce13e43c" rel="nofollow">https://gist.github.com/mrkybe/efa70a9ddcba7b5bfe441dafce13e...</a><p>It's been a huge time-saver.
Oh, no, another Rust vector and matrix library. There's already "glam" and "nalgebra".<p>Having more than one vector and matrix library is as troublesome for geometry processing as multiple string types are for string processing.<p>Usual hints for language designers on type basics that become a headache as the language progresses:<p>- Have a "bool" type, and don't make it equivalent to an integer.<p>- Have types for vec2 through vec4, and mat2 through mat4. That covers the cases graphics people use constantly. Those are basic, and everyone agrees what they should do.<p>- Support multidimensional arrays as a standard language feature. Don't get too fancy. Just do it at least as well as FORTRAN does.<p>- Strings are checked UTF-8.<p>- Provide some standard error type, or error hierarchy, from which all errors are derived.<p>Get any of those wrong in the early days of a language and retrofits will become a time sink for users.
Rust got three of those five wrong, and had to be retrofitted to fix them.