vazgriz
I'm just annoyed that so many educational resources and even flight code still use customary units for everything. I believe that metric should be used for all internal calculations and knots should only exist at the UI layer for the pilot.
When I play flight games though, I only have intuition for speed in terms of knots. Like 150 kts is takeoff speed and 400 kts is the corner speed.
I just think that the pilot letting out a spool of knotted rope from their plane is a very silly practice to defend :)
In my experience in both the aerospace industry and the video game industry, there are no tools like this in use. In aerospace specifically, errors like that are caught by manual human review, including third-party validation companies. Unit tests are used to sanity check every calculation. And finally, everything is run in a flight simulator before ever going onto a real aircraft.
In video games however, it's the wild west. Math errors there are funny, not deadly.
I wanted to keep the data tables exactly the same in the C# translation. While formulas can be converted to metric easily, the data tables do not actually have units defined for any of them, so translating them to metric is non-trivial. And the way data is mixed from multiple tables is very complex. So verifying that the calculations have equivalent results in metric is well beyond my ability.
Or rather, the best way to verify it would be to write a flight model that uses customary units (what I describe in the article), and then use that to verify that the metric flight model is equivalent.
At the end of the day, only the inputs and outputs of the flight model need to be converted, which is just handful of multiplication operations. The flight model is very cheap to run, even with conversions at runtime.
Consider this C++ code:
Foo bar();
fn bar() -> Foo;
var bar : Foo;
> in fact, they are isomorphic
> The change is simple and the code remains almost the same, but the understanding grows a lot.
Does that mean you could rename 'class Quaternion' to 'class Rotor' and be done? I watched the video on rotors and some other videos on quaternions and I found them exactly as unintuitive as each other. I don't really see any advantage to using rotors and I'm quite happy to continue treating quaternions as black boxes.
The article says that rotors are better since they can be generalized to any number of dimensions, unlike quaternions which only work in 3D. But that only seems useful to one person: Marc ten Bosch, the guy who writes games in 4D.