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.
