Points out how you should use vector coordinates in navigation, instead of trig. All those pesky divides happen in one place, are obvious, and handling them is trivial.

But cos(90°) = 0 too, unless they thought to check for one case but they did check for the other, or something more complex is happening.

I mean, it's probably more complex than what I postulated.

It was just the first thing that came to mind, since 270° is zero in a few trigonometric functions/identities.

Next week un elreg : HN fixes 20 years old bug in Boeing 737

That would also cause a divide by zero at a 90 degree heading

Which are the exact same runways when approached from the opposite end.

Wind generally goes west to east though.

Likewise cos 90° (all runways designated 27 are also designated 9) but those haven't reported these problems, have they?

angle = arctan(dy/dx) where dx=0.

I guarantee this is the mistake they made.

In some languages you can use Math.atan2(dy,dx) to easily avoid this.

>cos(270°) = 0 (parent)

I don't know of a language (but I don't know many) which trigonometric functions use degrees and not radians. In radians and finite precision, "cos(x) = 0" is false for all x (unless your cos is wrong), thanks to Pi being irrational (for example, cos(Pi_in_f64) is about 6.123233995736766E-17). You have "sin(0) = 0" though.

>angle = arctan(dy/dx) where dx=0.

If dy != 0, dy/0.0 is +-Infinity (if following IEEE754), so angle is +-Pi/2.

Coordinates/physics is among the things I see developers get wrong the most (even excluding units issues), along with threading/locks and instances_ownership/pooling.

Data races and deadlocks issues can be rare, and leaks get fixed by a restart, but these coordinates issues can introduce constant errors and biases often overlooked by tests (in addition to almost systematically unhandled cornercases like these).

In any code base an arctan function called with a single argument should be considered a bug until proven otherwise.

Arctan, yes; division by zero, no.

Boeing engineers probably were skilled enough to account for zero division errors in their software, considering that the software works for eastward-pointing reciprocals. It's the sign function returning an unexpected value for zero and causing problems down the pipeline.

My guess is that it's not just any old "Runway 27", but it's runways where the coordinates of the endpoints of the runways have precisely the same latitude down to whatever precision is in the database. It's probably quite rare to have a runway that's this perfectly east-west.

Looking at the coordinates of the runways in the FAA database, they are all perfectly east/west within about 2 feet of deviation N/S. This would round to zero if the calculations were done as lat/long as single precision numbers.

Are there other runways that are so dead-on?

Runway 27 just means a runway that runs east-west and you're approaching from the west. Landing the other way it would be Runway 9, it's a neat little system that gives pilots everywhere a surprising amount of information in a single name.

I doubt even the military would want the risk of a humongous plane landing blind on their runway, no matter how many secrets they had nearby.

> the blanking of 5 displays is probably not a bug

If it’s not in the manual, it’s a bug.

Most likely, but manuals have bugs too like typos and missing information.

Then that is also a bug.

Unless the argument you’re making is “two bugs make a bug intended behaviour”

I don't disagree, but I think it sort of illustrates the fact that using the term "bug" for documentation mistakes is a bit too non-standard, even though I used it myself.

Why are you so sure the blanking is not caused by a bug? “On error clear screen” seems like a pretty good way of making it very clear to the pilot that something has gone wrong and they need to fall back to manual procedures (rather than looking at displays that may have gone stale or be showing bad information).

I don't know a single airplane that does that and I've flown quite a few types.

It's normal to have error detection and the way to show it is to cross out (red lines, black background) the failed information on the screen. Not blank the whole thing.

The units are fairly independent in a modern system, communicating via data buses. So this sounds like a case where the bug made a unit emit something really bad on that bus to make them all go blank.

Ah, that makes sense. Thanks for the detail!

I had this fleeting thought as well but, the list of affected airports are all very benign. There's nothing of note in Wayne County, OH.

This can't be the case -- the bug only affects specific runways at these airports, not all the runways.

NOTAMs are safer, cheaper, and more effective for this purpose than blanking aircraft instrument displays without explanation.

And if you have an emergency you’re going to put the bird down wherever there is a runway, even if it’s area51. You may be asked to call the phone number when you land tho :/

Exactly. The bug doesn't prevent landing, just shuts down some automation: effective ways to prevent landings include missiles, not obscure bugs.