[HN Gopher] Sguaba: Hard-to-misuse rigid body transforms for eng...
___________________________________________________________________
Sguaba: Hard-to-misuse rigid body transforms for engineers
Author : lukastyrychtr
Score : 35 points
Date : 2025-05-31 20:27 UTC (2 hours ago)
(HTM) web link (blog.helsing.ai)
(TXT) w3m dump (blog.helsing.ai)
| fsloth wrote:
| 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.
|
| 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.
| keleftheriou wrote:
| Why not allow implicit conversions from your own defined types?
| fsloth wrote:
| Because you want to be explicit each time you change
| coordinate system. You want the code to be so obvious it
| looks dumb.
| lvh wrote:
| That doesn't really explain _why_ , you're just saying that
| the thin you claimed was desirable is desirable.
|
| (I don't disagree! I'm just saying: you haven't advanced
| your argument or answered GP's question.)
| bediger4000 wrote:
| If I may...
|
| Ex structures engineer, current programmer here.
|
| The technique described keeps you, as a programmer, from
| transposing coordinate variables by type system
| enforcement. You might have variables x1, y1, x2, y2. If
| y1 and y2 have a different type than x1 and x2, it's much
| harder to transpose them. Large flying vehicles often
| have many coordinate systems. Enforcing types will keep
| you from using stage 1 variables in a stage 2 context
| without type conversion.
| fc417fc802 wrote:
| Implicit conversions _in general_ are a very common source of
| bugs. C(++) implicit widening and narrowing and other such
| things have bitten me quite a few time. Instead of asking
| "why not allow" you should instead ask "why allow" and only
| implement such things when there is a compelling case for it.
| Animats wrote:
| Oh, no, another Rust vector and matrix library. There's already
| "glam" and "nalgebra".
|
| Having more than one vector and matrix library is as troublesome
| for geometry processing as multiple string types are for string
| processing.
|
| Usual hints for language designers on type basics that become a
| headache as the language progresses:
|
| - Have a "bool" type, and don't make it equivalent to an integer.
|
| - 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.
|
| - Support multidimensional arrays as a standard language feature.
| Don't get too fancy. Just do it at least as well as FORTRAN does.
|
| - Strings are checked UTF-8.
|
| - Provide some standard error type, or error hierarchy, from
| which all errors are derived.
|
| 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.
| isaacimagine wrote:
| The article is about using nalgebra to create an intuitive
| library for tranforming between Earth's various coordinate
| systems. Not "another Rust matrix library".
| kaibee wrote:
| 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.
|
| https://gist.github.com/mrkybe/efa70a9ddcba7b5bfe441dafce13e...
|
| It's been a huge time-saver.
___________________________________________________________________
(page generated 2025-05-31 23:00 UTC)