Unit Definitions
futureboy.us
futureboy.us
// Alan's notes:
// I'd like to put a mu in here for micro.
// Should we adopt the questionable Electrical Engineer policy of using
// "u" to indicate micro? I've added "uF" for microfarad later on to
// tackle the most common case.
Disclosure: Graduate of EE. Didn't know we were causing so many issues all this time with our rebellious use of microfarads :)
Also, the ohm symbol is frequently omitted from resistance specifications. 10 kΩ is written as 10 k (or worse, 10k).
// These number terms were described by N. Chuquet and De la Roche in the 16th
// century as being successive powers of a million. These definitions are
// still used in most European countries. The current US definitions for these
// numbers arose in the 17th century and don't make nearly as much sense.
By the time "billion" was defined by Chuquet and De la Roche, the concepts of "ten thousand" and "hundred thousand" were in widespread use. Those were followed by "million". So there's already a precedent for "we multiply things by a hundred before coming up with a new name". How does it make sense to change that to "but after a point, we multiply things by a thousand before coming up with a new name"?
I could see a couple systems that would arguably make more sense:
* ten, hundred, thousand, million, billion, trillion... (no multipliers)
* ten, hundred, ten hundred, thousand, ten thousand, hundred thousand, million, ten million, hundred million, thousand million, billion..., million billion, trillion... (use all previous multipliers before creating the next new name)
Admittedly, the US uses neither of those systems. But sticking with the precedent of "a hundred is the highest multiplier" makes sense.
If we had skipped "billion" and gone with "trillion" = 1e9, then it would be more natural, because then it would refer to the number of thousands; but then the more natural nomenclature would be "bi-sands" and "tri-sands" or something.
home page at https://www.gnu.org/software/units/
full source code at http://ftp.gnu.org/gnu/units/
This file is adapted, modified, and extended from the units database for use with GNU units, a units conversion program by Adrian Mariano adrian@cam.cornell.edu, who did a damn fine job collecting much of this.
I fail to see how this follows from the SI definition of either the hertz or the radian.
EDIT: [0] For example, one way of defining sin(x) is as the sum of the power series `x - x^3/6 + x^5/120 - …`; this cannot be dimensionally consistent unless x is dimensionless. Another is to define y(x) = sin(x) to be the solution of `d^2y/dx^2 = -y` satisfying certain initial conditions; but the units of `y` can only be equal to those of its second derivative if the argument of `y` is dimensionless.
EDIT 2: One easy way to fix the potential dimensional inconsistency is to replace `d^2y/dx^2 = -y` by `d^2y/dx^2 = -k^2 y`, where `k` is just a conversion factor for dimensional consistency (so that `[k] = [x]^{-1}`). Then a solution is `y = sin(k x)`; and, once again, the argument of the sine function is dimensionless.
Not sure how to explain the "zen" of radians; it's kind of the angular equivalent of "e" in natural logarithms. People who first learn logarithms say WTF, what is this "e" thing? why not just log10 everywhere? But when you get into calculus you find that "e" is the only log base that doesn't introduce extra baggage; if you take the derivative of a^x the result is ln a * a^x, and if you take the derivative of log_a x = ln x / ln a, you get 1/(x ln a). In both cases the "ln a" term is 1 only when a = e.
For radians, the functions sin wt and cos wt (w = "omega") have derivatives of w * cos wt and -w * sin wt when wt is measured in radians. Otherwise there is an additional constant of proportionality that depends on the angular "unit". (the term "unit" in quotes because it's still dimensionless but just related to radians by a dimensionless scaling factor, like 180/pi for radians <-> degrees or 1/(2*pi) for radians <-> revolutions.
> I fail to see how this follows from the SI definition of either the hertz or the radian.
The definition of 'Hertz' is 1/s. 'Radian' is not a unit, but a dimensionless number (the number 1, in fact, representing the ratio of arclength to radius where the arclength and radius happen to be the same), so that 1/s = radian/s.
'Use of "Hz" will cause communication problems, errors, and make one party or another look insane in the eyes of the other.' LOL.
* Every physicist or electrical engineer or high school physics student has "known" for the past 100 years that a Hz is 2 pi radians/s. And it was defined that way for a long time, as the document referenced shows, and almost everyone follows this convention.
* Everyone who follows the current rules of the SI exactly (as per JadeNB's analysis above) "knows" that a Hz is 1 radian/s. His analysis is not hard to follow. It's utterly unambiguous and machine-parseable. There is no possible other answer.
So, you can see there's a problem there. The document correctly traces the changes in the definition of the Hz and radian at different times that led to this situation. (e.g. the Hz used to be defined as "cycles/s")
The funny part is seeing what different units-aware software packages do to try and make themselves seem reasonable. :)
* Frink (the package from which this data file emanates.): Follow the currently-written rules of the SI (that is, 1 Hz = 1 radian/s) but rant about it in the data file. Also, if you read the data file closely, it allows you to switch between radians having their own dimensions or being dimensionless (but warns against the former.)
* GNU Units: Follow the currently-written rules of the SI (that is, 1 Hz = 1 radian/s) Not sure if there's a rant.
* Wolfram Alpha: This was an interesting one. At launch, they followed the currently-written rules of the SI but this evidently led to lots of bug reports and a current inconsistent state. They used to report that "1 Hz = 1 radian/s" but soon they hacked and patched around these in some inconsistent ways. For example, it would work differently if you put in "1 Hz in radians/s" and "1.0 Hz in radians/s".
Nowadays, if you do "1 Hz in radians/s" in Wolfram Alpha, it gives you the answer "6.283 rad/s" which is more acceptable (but wrong according to strict interpretation of the SI) but has a little disclaimer where it says below (in gray) "(using 1 Hz = 1 rps (revolution per second))"
A revolution meaning a rotation of 2 pi radians, I hope.
But it's a single-case kludgey workaround. You can see that their system is hacked and self-inconsistent, because if you divide both sides of that calculation by something else, say, seconds:
"1 Hz/s in radians/s/s"
* Wolfram Language / Mathematica: Follow the currently-written rules of the SI (that is, "Convert[Hertz, Radian/Second]" gives "Radian/Second") Note that seems to be a different result than Wolfram|Alpha.
* Google calculator: At the start, Google Calculator would follow the currently-written rules of the SI (that is, "1 Hz in radians/s") would return 1. But this caused lots of consternation and bug reports: http://productforums.google.com/forum/#!topic/websearch/kudd...
The funniest part about that nowadays is that Google Calculator utterly refuses to do anything with the Hz, even if you force it with a preceding equals sign. The interactive interface only lets you turn Hz into kHz, MHz, etc, and other multiples. LOL. I'm sure that other self-consistent environments wish they had this latitude. Like a politician, any question they don't like, they just pretend not to hear, and give you somebody else's search results instead. :)
This problem with the definition of the Hz is nothing new, and is well known in the literature. For example, see: M.P. Foster, Quantities, units and computing, Computer Standards & Interfaces (2013), http://dx.doi.org/10.1016/j.csi.2013.02.001
In short, the author of the rant might be messed up in the head from having to 1.) deal with these inconsistencies and 2.) try to look non-insane to two groups of people who are simultaneously both right and both wrong.
FTFY
In any non-brain-dead system, angular frequency (rad/s, degrees/s, rev/s, RPM) has to be accounted for differently than 1/time. This unfortunately won't prevent automated systems from accepting "sin ft" where f is in Hz (incorrect) rather than "sin wt" where w is in rad/s (correct), but there's really no way to handle this automatically.