Slashdot Mirror

http://futureboy.us/frinkdocs/

Not really. cgs or kgs? Bq or Ci? Sv or rem? WTF is a candela when you're measuring any frequency other than 540 x 10^12Hz? What about time and angles and solid angles where the official units are less common than the traditional ones in most uses? Metric still has plenty of weird constants, it isn't natural units. (of which there are various systems, each with some inconveniences) Not to mention economic measurements, a little area the metric system completely ignores.

Converting isn't that hard any more. Use Frink. It will handle practically any unit out there, and if it isn't in http://futureboy.us/frinkdata/units.txt (well worth a read), you can add it.

Not really. cgs or kgs? Bq or Ci? Sv or rem? WTF is a candela when you're measuring any frequency other than 540 x 10^12Hz? What about time and angles and solid angles where the official units are less common than the traditional ones in most uses? Metric still has plenty of weird constants, it isn't natural units. (of which there are various systems, each with some inconveniences) Not to mention economic measurements, a little area the metric system completely ignores.

Converting isn't that hard any more. Use Frink. It will handle practically any unit out there, and if it isn't in http://futureboy.us/frinkdata/units.txt (well worth a read), you can add it.

It's really a 2-D search problem. Rather than mess around with steradians, which nobody understands anyway, I figured how much area the full moon takes up in the sky, which is about pi*(0.25degree)^2. So using Frink, sphere/(pi(0.25degree)^2) gives 210099.6 and change. Coincidentally the moon is about the same size as the foveal area of a human's vision, so it would take over 210,000 people to look in all directions at once.

With telescopes, of course, it would be an even bigger problem. Figuring that a decent low-end professional scope is about 20 inches with a theoretical resolution of 0.3 arcseconds, and assuming square pixels, that's nearly 6E12 pixels to cover a full sphere. (In the real world there are lots of complicating factors, but that's the right order of magnitude.) To make it a little more concrete, if the sensors have 5micron pixel pitch, that would be 148.5m^2 of sensors, or in American, the equivalent of a square sensor 40ft on a side.

Try Frink. It has no trouble with that sort of thing. Over 58K of plain-text units.
(Typical section of the latter:
siegbahn := xunit // of X-rays. It is defined to be // 1/3029.45 of the spacing of calcite // planes at 18 degC. It was intended // to be exactly 1e-13 m, but was // later found to be off slightly.
fermi := 1ee-15 m // Convenient for describing nuclear sizes // Nuclear radius is from 1 to 10 fermis
barn := 1ee-28 m^2 // Used to measure cross section for // particle physics collision, said to // have originated in the phrase "big as // a barn".
shed := 1ee-24 barn// Defined to be a smaller companion to the // barn, but it's too small to be of // much use.
(Please pardon the fucking Slashdot idiot-designed piece-of-shit worse than TI-994/A FORTRAN formatting .)

Try Frink. It has no trouble with that sort of thing. Over 58K of plain-text units.
(Typical section of the latter:
siegbahn := xunit // of X-rays. It is defined to be // 1/3029.45 of the spacing of calcite // planes at 18 degC. It was intended // to be exactly 1e-13 m, but was // later found to be off slightly.
fermi := 1ee-15 m // Convenient for describing nuclear sizes // Nuclear radius is from 1 to 10 fermis
barn := 1ee-28 m^2 // Used to measure cross section for // particle physics collision, said to // have originated in the phrase "big as // a barn".
shed := 1ee-24 barn// Defined to be a smaller companion to the // barn, but it's too small to be of // much use.
(Please pardon the fucking Slashdot idiot-designed piece-of-shit worse than TI-994/A FORTRAN formatting .)

Or you could just use Frink, which is so cool in so many ways that even the highlights would be too long to list here. It will deal with pretty much any unit of measure or abbreviation, and additional temporary or permanent units can be added with minimum effort.

Silly examples:
cubic hectofurlongs / tropicalyear -> exascotswheatlippies / plutoyear
0.89894198315626957388

microgreatgross gilbert crocodile -> hp
1.8440377432226315066

If I select show "All add-ons" and disable all 4 Sun entries, when I visit here:

http://futureboy.us/frinkdocs/FrinkApplet.html

I get an alert that an add-on is disabled.

(I restarted after disabling them, just to be sure).

"...about the only units that I convert between on a regular basis is ... time, "

You might want to try Frink, which specializes in units conversion, including some very sophisticated time functions and unusual units. (Search in the latter link for "Astronomical time measurements"). It handles UTC, Dynamical Time, International Atomic Time (TAI), GPS time, leap seconds, can do correct date arithmetic even across the 1BC -1AD and Julian-Gregorian gaps, and can do time-zone conversions across the date line, e.g.:

now[]
AD 2011-06-28 PM 04:37:05.787 (Tue) Eastern Daylight Time

now[] -> Guam
AD 2011-06-29 AM 06:37:14.543 (Wed) Chamorro Standard Time

"...about the only units that I convert between on a regular basis is ... time, "

You might want to try Frink, which specializes in units conversion, including some very sophisticated time functions and unusual units. (Search in the latter link for "Astronomical time measurements"). It handles UTC, Dynamical Time, International Atomic Time (TAI), GPS time, leap seconds, can do correct date arithmetic even across the 1BC -1AD and Julian-Gregorian gaps, and can do time-zone conversions across the date line, e.g.:

now[]
AD 2011-06-28 PM 04:37:05.787 (Tue) Eastern Daylight Time

now[] -> Guam
AD 2011-06-29 AM 06:37:14.543 (Wed) Chamorro Standard Time

"...about the only units that I convert between on a regular basis is ... time, "

You might want to try Frink, which specializes in units conversion, including some very sophisticated time functions and unusual units. (Search in the latter link for "Astronomical time measurements"). It handles UTC, Dynamical Time, International Atomic Time (TAI), GPS time, leap seconds, can do correct date arithmetic even across the 1BC -1AD and Julian-Gregorian gaps, and can do time-zone conversions across the date line, e.g.:

now[]
AD 2011-06-28 PM 04:37:05.787 (Tue) Eastern Daylight Time

now[] -> Guam
AD 2011-06-29 AM 06:37:14.543 (Wed) Chamorro Standard Time

Frink really does have nearly every unit ever. Here is the Frink units file It's quite a fun and informative read, and you'll find out things you didn't know that you didn't know.

Proce55ing (JVM front-end, so it runs anywhere, easy, clean, concise, designed for beginners but still powerful lots of graphics capabilities, Arduino microcontroller programming is based on it)

Frink (the ultimate desktop calculator - JVM-based, runs on anything including phones, 1-click install or web interface, terminal or text-editor interface, can write self-modifying code (eval, 1st-class functions), allows converting nearly any combination of physical units that has ever been used, has obsessively exact date/time arithmetic, number theory functions, default rational arithmetic, arbitrary precision arithmetic, symbolic computation, interval arithmetic, physically dimensioned graphics, animation, natural language translation, currency and inflation-adjusted monetary conversions, Java introspection and embeddability in Java programs ...

And it's really easy to use, for example, type at the command line:
        teaspoon water c^2 -> gallons gasoline
it returns:
        3164209.862836101
Which is the mass-energy equivalent of a teaspoon of water expressed as US gallons of gasoline.

And we're nowhere near that limit. Using Frink:
535lbs gravity 5000ft -> gal gasoline = 0.0259...
Even assuming 25% efficiency, it's still about 1/10 of a US gallon of gas. (the 200hp Martin engine burns 10gal/hr, so it could be as much as 38% efficient, but the transmission, fans and est.90% throttle pull that figure down.) The actual gas burned, though, to get to 5000 ft was likely about an order of magnitude greater. (~4000ft/800fpm=5min; 10gph*1/12hr=5/6gal)

The energy mostly goes not to lifting the craft from one height to another but rather to accelerating air simply to maintain altitude.

They found this site, and didn't want it to go to waste.

The only issue with Python is that it is awkward to use decimals. Sure, floats are good enough most of the time, but not all of the time.

I use frink when I don't want to think about representation problems:

http://futureboy.us/frinkdocs/

The support for units isn't nearly as cheesy a feature as you would think.

The following comes from this page:

http://futureboy.us/frinkdocs/#MCO

The last part, from Norvig, suggests that the issues were more subtle than that.

Saving Hundreds of Millions of Dollars

"The MCO [Mars Climate Orbiter] MIB [Mishap Investigation Board] has determined that the root cause for the loss of the MCO spacecraft was the failure to use metric units in the coding of a ground software file, "Small Forces," used in trajectory models. Specifically, thruster performance data in English units instead of metric units was used in the software application code titled SM_FORCES (small forces)."
--Mars Climate Orbiter Mishap Investigation Board, Phase I Report

This is not to take away from the designers of a wonderfully complex spacecraft that can travel to Mars; that's an incredibly difficult problem, and I couldn't do it. However, this is just the type of error that Frink was designed to help avoid, and because I make these type of errors a lot, I've designed this tool to help me. Frink tracks units through all calculations and makes conversions between them transparent. This is why I'm working toward making Frink a feasible solution for calculations of this type.

Update: I received the following from Peter Norvig:

"I ran across Frink, and as a member of the MCO review board, I appreciate your efforts. Note, however that more than just language support is necessary. First, you'd have to have conventions on data I/O -- the misinterpreted data was from a file, not from another function in the program. Also, there was an issue of software reuse -- the errant portion of the system had been used before on a previous mission, and in that case it was used in a non-critical, non-navigational way. It was not properly reviewed because the team did not realize that in MCO it became critical."

I have the book and it's entertaining. I would have preferred more equations and numbers and worked-out examples; the author seemed to be following Stephen Hawking's rule that every equation in a book cuts the readership in half.

This sounds like a reasonable prototyping/porting approach, really. I do much the same thing. For several years, I've been working on a programming language/calculating tool called Frink, and when I'm trying to write new code that may eventually be part of Frink, say, efficiently calculating the Riemann Zeta function, or factoring large numbers, I'll usually first write the prototype function in the Frink language itself, and get it working. It's much less effort, and usually far more legible, to write it in Frink, as opposed to, say, Java or C++. Later, I may port the algorithm to Java for some speed gain.

Frink and Matlab tend to try to preserve normal mathematical notation, which will make your mathematics people happy, and which be easier to read. When I need to refresh my memory about how an algorithm works, it's easier to go back and read the Frink code, not the Java code.

My advice is to try and maintain the algorithms both in Matlab format and C++ format, so that each accurately reflects what the other is doing. Yes, it's more work, but the code in one language will generally be a lot simpler than the other, so it shouldn't take much time. This will make it easier to prototype and test. The Matlab code will generally be more transparent for mathematical algorithms, and you'll be able to see, test, and fix bugs in the Matlab implementation more easily, whether you originally found the bug in the C++ version or the Matlab version. And you can share test suites and validate them against each other.

I don't agree with the people who think that the mathematicians can do all the high-level work in Matlab, and then just hand the work off to lower-level programmers to transliterate into C++. It's very common that an innocuous function in Matlab has huge amounts of very complex code behind it which you'll have to reproduce in C++. This often takes deep mathematical knowledge. For example, you might be using a Matlab function to factor numbers, but do you really know how to factor big numbers fast? Lots of work and user testing has been put into making sure the Matlab functions return the right results. Can you say the same about your C++ code?

There's lots of low-level understanding necessary for this transliteration, and of course the common annoyances where all of your expressions like 1/2 magically become zero when you port to C++!