It's quite amusing that they used the incorrect, lowercase abbreviation for "nautical mile" which means something else ("nanometer") in an article about a major issue caused by two things sharing the same abbreviation.
I was wondering; it seemed like if the to airports were 36000 angstroms apart (3600 nanometers), it'd be reasonable to give them the same airport code since they'd be pretty much on top of each other.
I've also seen "DANGER!! 12000000 μVolts!!!" on tiny little model railroad signs.
Yes, the nautical mile is actually les arbitrary than the 'normal' mile.
> Originally 1 meter was one ten-millionth of the distance over the surface of the earth from the equator to the pole.
Even more originally, they wanted to use the length of a pendulum that takes one second to swing. But they discovered that this varies from place to place. So they came up with the newer definition based on the size of the earth. And just like with all the subsequent redefinitions (like the one based on the speed of light etc), the new length of the metre matches the old length of the metre:
> [The] length of the string will be approximately 993.6 millimetres, i.e. less than a centimetre short of one metre everywhere on Earth. This is because the value of g, expressed in m/s^2, is very close to π^2.
The definitions matching is by design, not an accident.
They were. The difference is one is part of a standard system of units with sensible relations between different units in the system, and the other isn't; the specifics aren't what's important, the relations are.
1 foot is allllllllmost the distance light travels in a nanosecond. If we’d just adjusted the length a tiny bit it would be an excellent unit of measurement
Indeed. There are plenty of things in aviation where they care so much about compatibility that something survives decades after it should reasonably be obsolete and replaced.
Inches of mercury, magnetic bearings (the magnetic poles move! but they put up with that) and gallons of fuel, all just accepted.
Got a safety-of-life emergency on an ocean liner, oil tanker or whatever? Everywhere in the entire world mandates GMDSS which includes Digital Selective Calling, the boring but complicated problems with radio communication are solved by a machine, you just need to know who you want to talk to (for Mayday calls it's everyone) and what you want to tell them (where you are, that you need urgent assistance and maybe the nature of the emergency)
On an big plane? Well good luck, they only have analogue radio and it's your problem to cope with the extensive troubles as a result.
I'm actually impressed that COSPAS/SARSAT wasn't obliged to keep the analogue plane transmitters working, despite obsoleting (and no longer providing rescue for) analogue boat or personal transmitters. But on that, at least, they were able to say no, if you don't want to spend a few grand on the upgrade for your million dollar plane we don't plan to spend billions of dollars to maintain the satellites just so you can keep your worse system limping along.
> Inches of mercury, magnetic bearings (the magnetic poles move! but they put up with that) and gallons of fuel, all just accepted.
Here in Europe we use hectopascals for pressure, as does pretty much everywhere else. It’s important to have a magnetic bearing in case your glass dies and you’re reliant on a paper map and compass, if you didn’t plan with magnetic bearings you’d be screwed if this happened in an area of high magnetic variation.
Air pressure is reported in hectopascals and fuel quantity in kilograms (or tons). It's only in America where this isn't the case. We're still using feet for altitude in most places though (it's mainly Russia that uses metres).
We better get this sorted out before open source manned Mars missions.
That all programming languages, down to statically typed assembly, don’t support something as simple to validate as unit consistency says something strange about how the science of replacing unreliable manual processes with automated systems is really bad at the practice of replacing its own risky manual processes with automated systems.
If numeric types just required a given unit, without even supporting automated conversions, it would make incorrectly unit-ed/scaled literals vastly less likely.
> That all programming languages, down to statically typed assembly, don’t support something as simple to validate as unit consistency [...]
Many programming languages are flexible and strong enough support this. We just don't do it by default, and you'd need libraries.
Btw, units by themselves are useful, but not enough. Eg angular momentum and energy have the same units of Newton * metre, but adding them up is not recommended.
> Eg angular momentum and energy have the same units of Newton * metre, but adding them up is not recommended.
The unit of angular momentum is kg.m^2.s^-1, you're thinking of torque. Although even then we distinguish the Newton meter (Nm) from the Joule (J) even if they have the same dimensionality.
I don't think it would be too difficult for a computer to handle. We already deal with situations like float(1) = int(1), it doesn't seem any harder to handle torque(1) = energy(1).
The problem is that you want torque not being equal to energy.
Specifically you have:
torque = force * distance
energy = force * distance
The only difference being that in the former the farce is perpendicular to the distance, and in the latter it's in line with the distance.
A vector based system could distinguish the two, but you don't always want to deal with vectors in your computations. (And I'm fairly sure there are problems where even using vectors ain't enough to avoid this problem.)
I agree no sexy languages have it, and almost all languages have terrible support or anti-support for correctness in numerical programming. It's very strange.
(By anti-support I mean things that waste your time and make it harder. For instance, a lot of languages think "static typing" means they need to prevent you from doing `int a,b; short c = a * b;` even if this is totally well-defined.)
`short c = a * b` can be both well-defined and a serious bug if (a * b) is greater than `sizeof(short)`. Whether it _is_ a bug depends on what you're doing.
Swift has units as part of the standard library. In the sense that matters here, Rust and C++ could also have units. It requires a level of expressiveness in the type system that most modern languages do have, if you put it to use.
It can be a serious bug if it overflows and you didn't intend it to happen or you expected overflow behavior to do something different. But that's also true of `int c = a*b`, and yet that's not a compiler error.
int/short should be thought of as storage size optimizations for memory. They're very bad ways to specify the correct range of values for a variable.
Whenever it's vague, I include the units as part of the parameter name (eg. delay_ms). Not perfect, but for practical purposes it helps. It's simple and I'm not sure why there aren't more people/libraries doing this.
Yeah, I went into the article thinking this because I expected someone had created waypoints right on top of each other and in the process also somehow generating the same code for them.
No one is using nanometers in aviation navigation. Quite a few aviation systems are case insensitive or all caps only so you can't always make a distinction.
In fact, if you say "miles", you mean nautical miles. You have to use "sm" to mean statute miles if you're using that unit, which is often used for measuring visibility.
Sure but I could imagine some kind of software failure caused by trying to divide by a distance that rounded two zero because the same location was listed in two databases that were almost but not exactly the same location. In fact I did when I first read the headline, then realized that it was probably nautical miles.
That would be roughly consistent with the title and not a totally absurd thing to happen in the world.
Indeed, having locations internally represented in software with a resolution of nanometers is as ridiculous as having your calendar's internal times represented as milliseconds since some arbitrary moment more than fifty years ago!
Wow, I read this article because I could not understand how two labeled points on an air path could be 3600 nanometers apart. Never occurred to me that someone would use 'nm' to mean nautical miles.
We all need to stop using abbreviations, in my opinion.
EDIT: I mean the point of abbreviations is to facilitate communication. However with the world wide web connecting multiple countries, languages and fields of endeavour there are simply too many (for example) three letter acronyms in use. There are too many sources of ambiguity and confusion. Better to embrace long-form writing.
Sorry no. One interpretation, especially on this site, is that the problem was some kind of database bug, maybe where the same location was entered twice and a tiny location error ended up creating two locations.
I expect that out of any random sample 500 million literate and mentally healthy English speakers, more than 450 million of them are totally unaccustomed to thinking about nautical miles ever. Even people in science, or even who might have dealt with nanometers in school do not typically think about nautical miles unless they are sailors or airplane pilots.
I assumed the post title meant nanometers. Why? Floating-point rounding bugs. A nanometer is about 9e-15 degrees of latitude, which is right about where a double-precision floating point number runs out of digits. So, if a piece of software uses exact `==` equality, it could easily have a bug where two positions 3600 nanometers apart are seen as being different, even though they should be treated as the same.
Thank you. People can be very bad about judging which scenarios are truly implausible.
Here’s a previous thread where someone thought it was absurd that there could exist native English speakers who don’t regularly go shopping, and treated that supposed impossibility as a huge “checkmate”!
I too first read it as nanometers. Perhaps it's just those with engineering/science backgrounds who have far more experience with nanometers than nautical miles?
I've never had cause to see the abbreviated form of nautical miles, but I know nanometers. Also, given purely the title I could see it being some kind of data collision due to precision errors between to locations that should be the same airport but perhaps two different sensors.
I used to work on military boats combat systems. I scanned the title, read it nanometers, thought it was weird, mentally corrected to nautical miles being familiar with the context and cursed the person who wrote the title for the incorrect capitalisation.
So, yes, people who have worked in a related field get it. Still annoying though.
And how many would assume that the incorrect unit abbreviation would mean something else? If I said Kbps and KBps, it's an entirely different unit of measure. NM and nm are VASTLY different, and unless you are already familiar with measurements in Aviation and know it's Nautical Miles, your first instinct is gonna be to read it as the unit it's supposed to be.
The article title is talking about location data and computers, I've seen many people forget floating point precision when comparing and getting bit by tiny differences at the 10^-9 or smaller. That seems just as obvious on the outset as non-unique location designations in what the average person would assume to be a dataset that's intentionally unique and unambiguous.
> In aviation? Literally everyone. Context clues should make it obvious.
But this is Hacker News, not Aviation News, and there are plenty of people, like me, who might find this interesting but aren't in aviation. I also thought it meant nanometers.
> In aviation? You know how big an aircraft is right?
Exactly, which makes the headline particularly intriguing—how could a 3600 nanometer difference matter? The standard resolution, which I pursued, is to read the article to find out, but it doesn't mention the distance at all.
