Just in case anyone is confused by this: (maybe it's just me?)
// 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.
This is referring to using the practice of using the character "u" instead of "µ" as the SI prefix for micro-, presumably because it's easier to type 'u' or because a lot of stuff is still stored in ASCII. Notably, this appears to be the only SI prefix that uses a non-Latin character, thus the inherent problems when used in documents/systems that only support the Latin alphabet or otherwise make it difficult to use non-Latin characters.
Disclosure: Graduate of EE. Didn't know we were causing so many issues all this time with our rebellious use of microfarads :)
Speaking of questionable EE conventions, why do electrical engineers seem to never use nanofarads? 10 nF capacitors are usually labeled as 10,000 pF or 0.01 µF, for seemingly no good reason.
Also, the ohm symbol is frequently omitted from resistance specifications. 10 kΩ is written as 10 k (or worse, 10k).
Other EE annoyances: capacitors are often marked with their capacitance as, say, "100 MFD". No, it's not megafarad, it's not millifarad; it actually means microfarad! That's annoying in several ways, including really abusing the SI prefixes (milli is "m" and mega is "M") and because the symbol for farad is simply "F", not "FD".
In regards to the difference between American and European billion/trillion/etc:
// 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.
Huh? Admittedly I'm biased, being American, but how do the American definitions not 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.
I think the "making sense" refers to the fact that "billion" has "bi-" as a prefix, and "trillion" has "tri-" as a prefix. In American English, it's not clear what is "bi-", exactly, about a billion -- two of what?
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.
Aha, that actually makes a lot of sense. I was only thinking about which numbers should have unique names, not whether the names we've given them make sense for their positions. Thanks!
This looks like an older version of the file. I don't know where to find an easily-linkable online copy of the current one, but it's the "definitions.units" file included in GNU Units.
It overlaps with it a great deal, but it is not simply that file. Quoting:
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.
Ah, I see. Yes, I'd missed the editorializing -- which I do think is worth reading (especially about the candela), now that it's been pointed out (though I do think he's wrong about bits and Hertz). For what it's worth, though, it appears to be modified from an older version of the file; some of the editorializing would be out of date if it used an up-to-date version.
> > This means that, if you follow the rules of the SI, 1 Hz = 1/s = 1 radian/s
> 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.
Hehe. This is probably why the author of the document summarized the discussion of the Hz to say:
'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"
which of course should give the exact same numerical value as above, 6.283, but this time it gives 1!
* 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.
> * Everyone who follows the current rules of the SI blindly (as per JadeNB's analysis above) "knows" that a Hz is 1 radian/s.
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.
I always frowned upon the unit "radian". Radian is defined in terms of the ratio of two quantities both having length dimensions. So by this definition angle should be dimensionless. I really don't get radian.
Angle, like any other quantity that is fed to a pure mathematical function (like the sine or cosine function), must be dimensionless [0]; and indeed it is. 'Degree' (as in 30 degrees) is not really a unit, but the number π/180, representing π units of arc along a circle of radius 180 units. 'Radian' is also not a unit, but rather the number 1, representing 1 unit of arc along a circle of radius 1 unit.
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've always ribbed against my physics professors using the notation of rad/s. To be fair, they'd make it clear that the reason they used it was to remind the students that the quantities were angular (ie \omega not velocity).
If you work in the field of motor control, you need this. (Not only that, but you need to distinguish electrical rad/s and mechanical rad/s; motors with N pairs of magnetic poles undergo N electrical cycles for each mechanical cycle.)
Disclosure: Graduate of EE. Didn't know we were causing so many issues all this time with our rebellious use of microfarads :)