FWIW she probably wasn’t breaking any security protocols - basically as long as the kids can’t read well they are fine to be escorted without the red light.

I used to take my daughter into the SCIF when she was about 2 when needed, and there was a week where I was took my son into work at the Pentagon.

I working for Snake Clark at the time and people kept bringing him candies and treats. I think he was watching cartoons on Nick in the deputy’s office most of the day. He gets a kick out of that story now.

Great story, thank you for sharing!

Your mom was awesome :)

I have fond memories of playing the original Falcon on my Amiga 500. It felt like magic after years of playing F15 Strike Eagle on the Apple IIc. Hearing real sound effects kicking in the afterburner and getting too close to the ground ("Pull Up! Pull Up!") were all so satisfying.

I remember being so excited when Falcon 3.0 came out. But it just felt like a let down. The graphics were amazing for the time and it seemed so realistic, but for me the realism is what killed all the fun. As a kid, I didn't actually want to BE an expert F16 pilot. I just wanted to feel like I was. I didn't want to have to learn all the systems and controls.

Yeah the HIGH FIDELITY FLIGHT MODEL required that math co processor. When you turned it on it felt like you had tapped into the WOPR from Wargames!

Falcon 4.0 source code leak led to Falcon BMS, still actively developed today.

I remember the opposite also. We used to play a lot of Robotron on my roommate's 8086 PC clone. Then he was so excited to upgrade to a '286. Robotron became unplayable. My guess is that it was coded with a lot of busy loops because it was so insanely fast on the 286 that a human simply didn't have time to respond.

I guess they probably came up with a new version, dunno.

I did enjoy the maps that came with it.

Granted, I probably would've had an easier border crossing if I didn't have a flight map for Kuwaiti airspace, complete with markings for anti-air defenses in the backseat of my car that one time, but it was _still_ worth it :)

Falcon game still have a large following today.

Hi, author here.

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.

    public class AirDataComputer {
    /// <summary>
    /// Density at sea level in kg/m³ (standard atmosphere)
    /// </summary>
    public const float SeaLevelDensity = 1.225f;

    /// <summary>
    /// Max altitude in meters
    /// </summary>
    public const float MaxAltitude = 10668.0f; // ~35,000 ft in meters

    /// <summary>
    /// Calculates air data based on velocity and altitude using SI units
    /// </summary>
    /// <param name="velocity">Velocity in m/s</param>
    /// <param name="altitude">Altitude in meters</param>
    /// <returns>Air data</returns>
    public AirData CalculateAirData(float velocity, float altitude) {
        const float baseTemperature = 288.15f;        // Sea level temp in K (~15°C)
        const float minTemperature = 216.65f;         // Tropopause temp in K (~ -56.5°C)
        const float temperatureGradient = 0.0065f;    // Lapse rate in K/m

        const float gamma = 1.4f;                     // Ratio of specific heats
        const float gasConstant = 287.05f;            // J/(kg·K), specific gas constant for air
        const float densityPower = 4.14f;

        altitude = Mathf.Clamp(altitude, 0, MaxAltitude);

        // Calculate temperature in Kelvin using linear lapse rate model
        float temperatureFactor = 1.0f - (temperatureGradient * altitude / baseTemperature);
        float T = Mathf.Max(minTemperature, baseTemperature * temperatureFactor);

        // Speed of sound in m/s
        float speedOfSound = Mathf.Sqrt(gamma * gasConstant * T);
        float altitudeMach = velocity / speedOfSound;

        // Air density using barometric approximation
        float rho = SeaLevelDensity * Mathf.Pow(temperatureFactor, densityPower);

        // Dynamic pressure in Pascals (N/m²)
        float qBar = 0.5f * rho * velocity * velocity;

        return new AirData() {
            altitudeMach = altitudeMach,
            qBar = qBar
        };
    }

I was going to say this! Why not just convert all the constants and units once since the mathematical relationships are the same?

> 1 nautical mile equals to one minute in the 90 degrees hemisphere arc

The nautical mile is not an SI unit, so it is not defined by a single organization, Your definition used to be the common definition, but it seems like the relevant organizations has updated the definition to be exactly 1852 m. If the original definition of the meter applies, then it would have been 1851.85 or 15 cm shorter, but with newer measurement of the earth, it would have been more like 1855 m.

Seems too good of pun to not be deliberate.

Thats_the_joke.jpg

.......that's the joke

.NET supports this because [Visual] Basic supports it. This can be used from C# - and other languages - but there is no nice syntax supporting it.

  // This also supports multidimensional arrays, that is why the parameters are arrays.
  var array = Array.CreateInstance(elementType: typeof(Int32), lengths: [ 5 ], lowerBounds: [ -2 ]);

  // This does not compile, the type is Int32[*], not Int32[].
  // Console.WriteLine(array[0]);

  array.SetValue(value: 42, index: -2);

  Console.WriteLine(array.GetValue(-2));

Unfortunately, Fortran's implementation of this has some inconsistencies. Doing certain operations will convert from the custom indexing back to 1-based indexing.

https://github.com/sourceryinstitute/fidbits/blob/master/src...

https://fortran-lang.discourse.group/t/just-say-no-to-non-de...

Pascal (and Modula if I'm not mistaken) supports this too.

Lua actually has arbitrary indexing, it's just that some iterator functions in the standard library assume arrays begin at 1.

    You can start an array at index 0, 1, or any other value

The feature worked fine and was portable in Fortran ‘77, but its interactions with modern features are full of shocking pitfalls even when the compiler implements them correctly, which only two do, so it’s not really portable either.

I'd agree with 1-based indexing problems, but not 0-based, which seems very natural. And if you have -2-based, I'd argue that perhaps you don't want an array.

    arr: array[-2..10] of integer;

    pointer(@arr) == pointer(@arr[0])

not sure why would i want that.

Now to get the 3rd element from array, you have to know the start index, so another parameter to pass to function.

Hi author here, I have worked in the aerospace industry on flight control systems. I'm very familiar with knots as a unit.

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 :)

As someone who works in flight simulation I was also taken back hard by this. We are internally metric all the way, but even so the knot is not a weird unit in this space at all. I also never heard about those coordinate conventions.

>airspeed is generally measured in either knots or Mach

boatspeed is also measure in knots... but only very rarely in Mach (and not even primarily because the speed of sound in water is substantially higher than in air)

In practice, unit checking is almost never done on actual code, though it should be done. From what I recall, some Fortran folks have been trying to get unit checking into the Fortran standard itself since the 1970s without success.

I was able to coerce Fortran's type system into checking units, but it comes with quite a few downsides: https://fortran-lang.discourse.group/t/compile-time-unit-che...

An approach based on static analysis would not have the downsides I listed, but I personally would prefer being unable to compile the code at all if it had an error that could be detected.

Hi, author here.

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.

You actually need the altimeter to be capable of reading below 0 in the real world.

Aircraft altimeters are based on air pressure. The reference pressure is variable based on atmospheric conditions and is decided by controllers, or in the case of uncontrolled airspace, the matching the altimeter of the known altitude that you took off from.

All that is to say, on my home (uncontrolled) airport which is ~10 feet above sea level, I occasionally land at a negative altimeter value since the weather conditions have changed while I am in the air.

Assuming that an altimeter reading must be positive is a bad assumption.

I've seen a few libraries that attempt to put strong unit types into languages, to use the type system to ensure correctness.

In rust I'm familiar with https://docs.rs/uom/latest/uom/ and typescript I've seen safe-units https://jscheiny.github.io/safe-units/ used.

> altitude doesn't go below zero

Uhm...

https://www.c-130.net/forum/viewtopic.php?p=9974&sid=bb425b3...

My favorite "strange unit" is poronkusema:

"A Sami measurement of distance; the distance a reindeer can travel before needing to stop to urinate. Today used to describe something that is at a very obscure distance away" (approximately 7.5 km)

https://en.wikipedia.org/wiki/Obsolete_Finnish_units_of_meas...

The 'List of non-coherent units of measurement' [1] and 'List of humorous units of measurement' [2] pages are always a fun rabbit hole to go down.

[1] https://en.wikipedia.org/wiki/List_of_non-coherent_units_of_...

[2] https://en.wikipedia.org/wiki/List_of_humorous_units_of_meas...

The whole imperial/British side has tons of ugly and weird units of measure. Reading old engineering documentation will give you headaches and nightmares from all the inconsistent systems of units.

Completely NSFW, but I worked at a company where we frequently needed to measure distance in approximate meters. I don't know the full origin, but at some point, after a night of drinking, one of the managers discovered that an elephant penis was approximately one meter.

From then on, any estimated distance was done in EDs.

Math or engineering people do not have problems with short symbol names, that's it. Also our formulas are complex. If you wrote out many of our formulas with long descriptive variable names the structure and relation between the variables would no longer be readable, there would be many more mistakes.

We were educated doing these things on paper with pages and pages of math with these symbols.

20 years later I can still read just this fortran code and guess most of what's going on with no context needed.

I have problems reading "developer code" that boil down to "where the hell is the part of the code that actually does something?!" being perpetually lost in layer among layer of abstraction with the relevant connecting pieces far far apart.

Other "interesting" units include: shakes, barns and bans

https://en.wikipedia.org/wiki/Shake_(unit)

https://en.wikipedia.org/wiki/Barn_(unit)

https://en.wikipedia.org/wiki/Hartley_(unit)

The confusion between force and mass tends not to get appreciated by many folks outside of engineering. Particularly in aerospace when you slip the surly bonds of earth and your mass stops being so bound to the force your feet impart on the floor.

Author is at least partially reusing Unity physics engine instead of using physics integrator from original simulation. It is not a mechanical 1:1 translation of Fortran code to C#. Once you start mixing the two sims units and other constants matter. Also the unity physics engine is finetuned for operating at certain scale with certain units. You could operate it in different units, but that will potentially require readjusting not just major physics constants but also a bunch of poorly documented magic parameters designed to prevent Unity sim from exploding or wasting resources.

Gravity doesn't scale this way. Earth's gravitational pull (~10m/s^2) is a constant that ties distance to time, so if you want to observe the same gravitational effects in the same gravitational pull on a small dimensional scale, you need to adjust the time scale to compensate.

This is why scale model sets for practical VFX in cinema were always recorded at higher frame rates and then played back slower.

Physical units help modeling and review, it's much easier to sanity check values from just reading, and comparing constants. I've heard that for rendering/raytracing, a lot of people move to model light intensities by actual physical values which makes it much easier to author and compare - such as for example "oh I want a light here that is as bright as this old lightbulb I like so much, but there's sunlight also shining through the window". That's much easier than estimating it in arbitrary units, in particular as here human perception is non-linear. I assume this would be similar for other simulations.

They don't matter as long as the relative values and the relationships hold. For video games where you're making something arcadey you're often implementing the physical behavior in terms of regular old physics but the values used don't have to be real as long as you get the right results. It's just when you're simulating something real it's useful to have units that make intuitive sense and that's often real world units as we've built up a lot of understanding by using them already. In particular with a flight model based on look up tables from real world data it's already in a set of units.

In mechanics simulations we often change the units to avoid adding small and large floats.

They don‘t, but they have to be consistent. You wouldn‘t want to apply a hundred-fold torque because you mixed up your units.

Would you want to fly in an aircraft that's been modelled with pretend computer units? Or the one that was modelled correctly in a simulator? :)

I agree, this was a great read.