Frink is a full-fledged programming language, so you can read data from files, write functions, access web-based data, repeat calculations, process text, create data structures, etc.
In short, it is a Turing-complete system. Soulver isn't, and that's a huge difference.
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.
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".
Thanks for the report, but this shouldn't be considered a bug. That unit is defined so that you can write "1 gram energy" or the like to find the energy content in that particular amount of mass. It's actually shorter (on a reasonable keyboard) to type "c^2" though, so this may not really be necessary. I may remove it from the data file.
The author's talk on Finch was indeed awesome. He was very funny and modest and self-deprecating, but it was obvious to everyone that he was really smart. And his talk had some of the most quotable bits in the whole conference.
"I'm writing a recursive descent parser by hand because I keep it real." LOL
His listings of the things his language couldn't do were hilarious too.
In response to a question from the audience, he discussed how he designed a programming language for the first time, which was really edifying and an interesting discussion of the mental journey. His answer was really good and I can't do it justice, but it talked about how he solved the problems by working in little stages. He knew that he could break up a text file into tokens, and that's how he built a lexer. Next, he realized that a parser was a lot like a lexer, and recognized groups of tokens, so he could build a parser. So he then had a tree, and he found that he could walk that tree. As he walked the tree, he realized he could emit bytecode. It was a really good description, and better than any single lecture in an entire semester of my college Compiler Construction class.
The fact that the author didn't even know he was going to be able to speak until the day of the presentation, and came up with a very polished and professional and engaging presentation says volumes about his ability. I think everyone really enjoyed his talk, and it really had a sense of joy and fun and discovery about it. And it was funny as hell. There is no doubt that we'll be seeing much more from him.
You can look up units or functions in Frink by just typing part of the name preceded by a question mark, or 2 question marks for more verbose output. For example,
?saturn
or
??saturn
will list the units that contain that substring. (The second example lists the units AND their values.) Typing
?barrel -> gallons
will list all the barrel sizes it knows and their volume in gallons. Cool!
Yeah, Frink is a Turing-complete programming language. That's a provably huge difference. You can have loops, maintain state, store results in variables and use them later, and define your own functions, so your calculations are repeatable and can be more than one line. Can't do those things with Wolfram Alpha. Frink has an unambiguous, documented syntax, rather than a bunch of tricky and finicky hard-coded rules that try to parse English sentences.
In short, it is a Turing-complete system. Soulver isn't, and that's a huge difference.