The advantage of the "old" control systems approach is that it's not a black box; you can reason about its behavior across the state space and make assertions about its frequency response and stability conditions.

(Is a neural network really different from a very large cascade of nonlinear filter elements?)

It pretty much is the case.

Part of it is that predictability is a desirable feature in these systems, but also that problems like the one described in the article you don't really need things like ML. The majority of control problems like this are surprisingly straightforward. They might be complex, in the sense of having a lot of variables, but the physics involved is well understood and can be modelled using traditional techniques.

The progress of self-driving cars is a good example of this. I can remember seeing expeimental self driving cars many years ago, but always going round mostly empty test tracks. Driving a car isn't that difficult for a computer system, what's hard is driving in highly complex urban environments with many other cars around that you need to predict.

Planes, in contrast, have a rather simple environment. The number of objects they have to avoid is massively lower, and their freedom of movement is higher, with established rules for how to behave, there are no traffic signs to interpret. This means that all you are really doing is object detection with radar, and collision avoidance.

In addition, modern combat planes are effectively flown by a computer all the time anyway, with the pilot providing the instructions. A number of fighter planes, especially the most modern, are essentially unflyable without computers due to their aerodynamics. Most are inherently unstable around at least one axis, which makes them more manouverable, but means they will not fly stably in the way a 747 will.

Algorithms that don't use machine learning aren't dumb. The point of machine learning is you need to implement some function, can't derive it directly from first principles, but have lots of examples of correct inputs and outputs and can use that build a function estimator instead. But in a whole lot of quite sophisticated and intelligent applications, you can derive the functions from first principles. Not easily. One of the projects I spent the first few years of my career working on was the common image formation processing for spy satellite collections, and you need to take into account special relativity, orbital mechanics, curvature and velocity both of earth and of the arrays, midnight crossover in time keeping, temperature calibration and the impact on reported voltage detection of each sensor cell, parallax effects of rapid altitude changes, polarization of light. There's a ton that goes into it, but we know the physics and don't have to use statistics to make educated guesses. We can compute "given voltage levels x1, x2, ..., xn on sensor cells y1, y2, ..., yn at times t1, t2, ..., tn, that is what we were looking at" exactly.

Mind you, I'm talking basic level 1 transformation of raw data streams to human-intelligible images. Once you get into automated object recognition, that's when we start to use machine learning, but the algorithms upstream of that are still plenty smart.

> the sheer amount of tech in a modern missile

"Old", reliable tech is prevalent there, too.

Sqlite in missiles is a good example.

Coming from a game development background, the easy part is to make the perfect opponent. The hardest part is to let the opponent feel human.

I'm guessing pointing a missile to the right direction has more to do with fast feedback loops and less about training neural networks.

Yes, in fact many static code analyzers and metrics will flag a piece of code as too complex if it has too many nested ifs.

But it does sound a lot less glamorous, doesn't it?

I have a very rudimentary knowledge of ML. But decision trees basically is if else statements, isn't it? The "ML" part is coming up with the tree.

Assuming there are only “if” and no “else”, then there would be 51 code paths (Presuming other preconditions like: the condition is code or there is some code within each if; the code cannot throw exceptions; there is no return statement; etcetera).

You could perhaps have only two code paths: the 50 ifs are true and something happens, or any one of the ifs are false and something doesn’t happen... although that could be written as a single if statement with “and”s.

The 2^50 case would be more code than we can store (unless using techniques that reduce the complexity i.e. not 2^50).

Fighters sometimes fly close to the ground on purpose. Building a system that will allow extreme maneuvers near the ground without a false alarm trigger was hard. The Swedish air force was the first to use this system, and they routinely fly "close to the rock", through mountain passes. That's the hardest part of the problem, deciding when to initiate the recovery while not impeding what fighter pilots consider normal flight. The threshold is something like 0.3 secs before it's too late to correct. That requires a very good trajectory predictor for figuring out when it's going to be too late.

Next is getting the aircraft into a wings-level condition, no matter what direction it's pointing. For fighters, extreme attitudes are normal. Auto-GCAS will make violent maneuvers to do this. "At that instant, the Auto-GCAS commands some of the most aggressive, eye-watering maneuvers this ex-USAF flight test engineer and civil pilot has ever experienced. If inverted (bank angle greater than 90 deg.) and somewhat nose-down, a negative 1g push throws the pilot "up" into his shoulder straps and lap belt to get the aircraft's nose headed skyward. Immediately, a 180-deg./sec. roll is commanded, bringing the aircraft to wings-level, right-side-up."

Only then can the system command a climb: "Somewhere after passing the 90-deg.-bank point, a 5g pull-up is initiated at an approximately 4g/sec. rate. The system commands a maximum angle-of-attack recovery, if flight conditions will not sustain a 5g pull-up."

The F18 literally has a switch labeled "Spin Recover". One of the things it does is to take the computer out of the equation and allow the pilot to fully command the airplane rather than processing stick and rudder inputs.[1] General procedure though is take your hands and feet off the controls to start with. The full procedure is in the link a few pages in. Notably, it ends with "if passing 10,000ft AGL with no indication of recovery, eject.

1 - https://apps.dtic.mil/dtic/tr/fulltext/u2/a256522.pdf

Sales guy here- turns out programming’s easier than I thought!