Documentation * What's New * Download * Frink Applet * Web Interface * Sample Programs * Frink Server Pages * Frink on Android * Donate
These are some questions which have been asked zero or more times about Frink. Please e-mail Alan Eliasen with questions, comments, or vituperation.
x/x not return 1?
x-x not return 0?
I periodically look at the calculations made through the web-based interface, and answer questions about Frink, and I find that the problem is most often one of the following:
If you do nothing else, please read and follow the SI capitalization rules for prefixes and units. (Links open in a new window.)
For example, by the rules of the SI:
Correct: kilometers, km, watts, W, gigawatts, GW
Incorrect: Kilometers, Km, KM, Watts, w, GigaWatts, Gigawatts, Gw
For non-SI units, Frink still uses specific capitalizations. For example,
the currency symbol for the U.S. dollar is
USD, not usd. If the case is incorrect, you
will tend to get messages like: usd (undefined symbol).
You can also access the built-in help by
entering a question mark and then part or all of the name of the unit you
want to find, for example: ?cubit lists all of the types of
cubits. ??cubit lists all of the types of
cubits and their sizes in the current display units. See the
Integrated Help section of the
documentation for more information.
Alternately, you can check the data file or lookup the unit by typing all or part of its name into the "Lookup" field here.
The Web Interface tries to give hints when a calculation goes wrong, but it won't correct mistakes implicitly and "do what I mean" because one of the goals of Frink is to not only help with calculations, but teach proper usage.
3 pounds multiplies the number
3 by a unit called pound.)
The most important implication of this is that everything on the
right-hand-side of a division often needs to be parenthesized. For
example, if you earn 400 dollars a week, and you want to find out how
much that is per day, you must write: 400 dollars/(7 days).
For more discussion of this, see the section below titled "Why do I have to put parentheses around
the right-hand side of a division?" If in doubt, parentheses never
hurt.
[ ], not parentheses.
sin[x] to find the sine of x.
This is necessary to distinguish between the implicit multiplication of
standard mathematical notation and a function call, say, in the case
x(x+1) (which is an implicit multiplication,
x*(x+1), not a function call.)
If all else fails, there's the obvious question "have you read the documentation?" In any case, please feel free to e-mail me. I'm always happy to help.
Well, one of the goals of Frink is to help people (including me) understand correct usage. It's a learning tool, after all. Frink tries to follow standards everywhere possible, including normal mathematical rules of precedence, International System of Units requirements for capitalization and style, ISO standards, authoritative and exact definitions of units, (I've checked most major units at least 5 times,) and more. I want to look good with my calculations, and in my writings and discussion with other people, and avoid ambiguity or incorrect usage, and Frink wants to help you look good too. If you enter an ambiguous or incorrect calculation, Frink tries to help you by guiding you toward more correct usage, and not giving you an answer that's possibly wrong without you knowing it. (That is, no magical conversion factors are silently slipped in.)
The Web Interface tries to give hints when a calculation goes wrong, and guide you toward proper usage, which is why it's the best way to start using Frink. I've spent innumerable hours poring over my web log files, identifying common confusions, and providing hints that will guide people toward better usage and understanding.
If you follow normal spelling, capitalization, and mathematical rules of precedence, Frink will usually understand it perfectly.
Probably. Type in all or part of the name of the unit in the "lookup" field on the web-based interface, or learn more by perusing the voluminous and fascinating data file for more examples of things you can do, and measurements that Frink knows about. And, as Bill Cosby used to say, "...if you're not careful, you may learn something before it's done! Hey Hey Hey!!!"
You can also use the built-in help by entering a question mark and then
part or all of the name of the unit you want to find, for example:
?cubit lists all of the types of cubits. With two question
marks, e.g. ??cubit lists all of the types of cubits
and their sizes. See the Integrated
Help section of the documentation for more information.
You can use the -u filename command-line switch to
specify a different units file than the default. This allows you to change
the fundamental dimensions that you like to use, or change my definitions
that you don't agree with. You can download my latest
data file
(normally included in the .jar file) and modify it to suit
your needs.
The default data file uses the International System of
Units (SI) recommendations. If you want something else, you can change
it. (See the previous question.) Before you do, you should know that it
usually doesn't matter, and you don't usually need to change your units
file. Frink can convert to whatever units of measure you want, just put it
on the right-hand side of the conversion operator ( -> ).
Alternately, you can define your own default display units. See the Setting Display Units section of the documentation for more information.
Well, in the United States, the pound has been officially defined to be a unit of mass since at least 1893 (by the Office of Standard Weights and Measures, and later by its successor, the National Bureau of Standards (NBS), which was formed in 1901. The National Bureau of Standards was renamed the National Institute of Standards and Technology (NIST) in 1988.) It has had its current value since 1959, defined as exactly 0.45359237 kilograms (also a unit of mass,) both by official notice in the Federal Register, giving it the effect of official U.S. policy, and as an official refinement by the National Bureau of Standards.
The latter document is very detailed and authoritative, and shows the very slightly different values it had in 1893 (then defined as 1/2.20462 kg, a mass), the value from 1894-1959 (then defined as 1/2.2062234 kg, also a mass, which only differs from the current exact value of 0.45359237 kg by about 1 part in 10 million.) All are quite unambiguous on this point. No standards body has, as far as I can tell, defined pound as a unit of anything other than mass, at least since 1893. (Legislation before that was ambiguous about the distinction between mass and weight.)
In the United Kingdom, the pound has been officially defined as a mass since the Weights and Measures Act of 1878, which defined it as having a very slightly smaller value (equal to approximately 0.453592338 kg.) The value of the pound was unified to its current value in all countries by 1960.
The "pound-force" or "lbf" is a measure of force, though. But that's not the pound.
If you want the pound-force in Frink, use lbf or pound
force (with no hyphen, which would be indistinguishable
from subtraction.) The unit force is a synonym for the unit
gravity, which is the standard acceleration of gravity,
defined to be exactly 9.80665 m/s2. The "pound-force" is
defined as the mass of a pound multiplied by the standard accleration of
gravity as defined above.
More details from the (U.S.) National Institute of Standards and Technology:
Official definitions from other countries:
Highly-regarded reference books like the CRC Handbook of Chemistry and Physics, 83rd Edition (2002-2003) has the definition given above in terms of the kilogram. The pound is, again, a mass and nothing else. (This is also true in the 1960 edition, but the 1960 edition has some non-self-consistent uses of "foot pound" as a unit of energy which has been corrected in later versions, which cite only "foot pound-force" as a measure of energy. Thanks to Bob Williams for the historical research.)
I was surprised too when I first started researching the pound. I had been told it was a unit of force by one engineering professor, and I believed it. It turns out he was wrong, I was wrong, and I realized I had better unlearn my mistakes and start using the right terminology before I made a big, costly blunder. If you don't believe it, please do your own research and it might help change your mind. You don't have to believe me, but I think you should believe your own country's standards bodies (and probably comply with your country's legislative definitions if you don't want to breach contracts!) After all, if you don't use the units properly when they're unambigously defined by both standards bodies and law, then you're the one with the liability.
If you can find any evidence that a standards body in the United States or any other country has ever defined pound as anything but mass (well, at least in the past century,) please send it to Alan Eliasen. Please, authoritative references only--not some individual's webpage or old confused textbook.
Yes, I have this discussion over and over again.
"I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives." --Leo Tolstoy
If you want the British currency, use GBP or
Britain_Pound, or, for the
historical buying power of
the pound in, say, the year 1752, try pound_1752.
Actually, Frink is exactly right, and it's important to know why it's right. Other converters get this wrong due to sloppy research.
The short answer is that the furlong (and league, acre, rod, statute mile, township, chain, etc.) are all defined in terms of the survey foot. The "survey foot" is the definition of the foot used in the U.S. up until July 1, 1959, when its value was slightly changed to the current value of the "international" foot as exactly 0.3048 meters. Previously, it was exactly 1200/3937 meters, which can't be represented as a finite decimal number. This is a change of a factor of exactly 499999/500000, or 2 parts in a million.
"When the United States adopted the international yard in 1959, the U.S. Coast and Geodetic Survey, mappers of the nation, objected that converting all their geodetic data to international feet would be a horrendous undertaking. They were authorized to continue to use the previous definition of the foot, that of the Mendenhall order (U.S. Coast and Geodetic Survey Bulletin 26, April 5, 1893), one foot = 1200/3937 meter." --https://www.sizes.com/units/foot.htm
Any time Frink gives you a result that is a multiple of the fraction 499999/500000 when working with lengths, it's a very good bet that the survey foot was involved.
If you use:
1 statutemile^2 -> acres
then you'll see that a square "statute mile" is equal to exactly 640 acres. But that's not the modern mile. The "statute mile" is the old mile using the outdated pre-1959 definition. The modern mile is just called the "mile" or sometimes the "international mile" if someone's making sure which mile is to be understood. Frink also uses the term "surveyfoot" if you want to use the old, outdated definition of the foot. All English-speaking countries standardized on the modern definition of the mile by 1960.
Surveyors still use the old definition, and the acre and other units listed above are officially defined in terms of the old "survey" foot, and if you want to be correct, (and I do,) you need to use the right base definitions for all the derived definitions. This is a common question, and people are often suprised to hear the history (unless they work in a geographic field, and then they run into it 50 times a day.)
See the authoritative NIST Special Publication 811 (See Section B.6) or NIST Handbook 133, Appendix E. (These documents and its predecessor, NIST Handbook 44, use italics or underlining to show the units that are defined in terms of the survey foot. Be warned that versions before 2007 may have lost the italics or underlining due to a change in the software they used to produce the documents in those years. I reported these to them and they acknowledged them all as errors to be fixed, and fixed them about 3 years after I first reported them for the 2004 edition.)
I really do scrupulously research these things (I've probably researched every major measure in Frink's data file at least 5 times, usually against the most authoritative references I can find--international standards bodies and the like) so if you see something unexpected, odds are there's a reason for it. I'm always surprised when I dig in and research some of these units. If you see a conversion that seems surprising, I'll bet all the money in my wallet that it's right, and there's a reason for it. As a corollary, I've found about as many errors in "authoritative" documents as about anybody out there, which is why everything is researched and re-verified many times.
Frink maintains exact conversions (as rational numbers) when the conversion is defined to be exact, so roundoff error is prevented and allows computations to be perfectly reversible.
I get this a lot. Frink is exactly correct in this case. You can't blame roundoff; you have to blame institutional inertia.
Summary: If another unit converter tells you that a square mile is anything but exactly 639.99744000256 acres, it is wrong. If it tells you that an acre is anything but the exact fraction 62726400000/15499969 m2 (or approximately 4046.872609874252 m2; it can't be represented as a finite decimal number,) it is wrong.
Round parentheses () are used for grouping and
setting precedence, (e.g. indicating that the addition should be
performed first in the expression x (x+1) ).
Square brackets [] are used for indicating
function calls (e.g. length[a] ) and
creating an array of values (e.g. [1, 2, 3,
4] ).
That is, why do I have to write:
30 miles / (2 hours)
to find my velocity?
Because I want to maintain the normal precedence of mathematical operators. Multiplication and division are at the same precedence and performed left to right. The space between "2" and "hours" implies multiplication.
Some may be expecting the behavior of the ubiquitous UNIX "units" program
which doesn't require the parentheses, but treats division as lower
precedence than multiplication (and thus only really expects one division
per equation, which is an unreasonable limitation, and this also implies
that you have to resort to convolutions like writing 1|2 foot (using that weird vertical pipe symbol)
when you mean half of a foot.) If I don't require the parentheses, this
becomes equal to 1/(2 foot), a unit of inverse length.
This is something I've struggled with since I started writing Frink. Unfortunately, I haven't been able to come up with a solution that doesn't violate my prime directives:
Number 1.) is absolutely crucial. I'm proud of the fact that mathematical equations can often be pasted directly into Frink without any alteration, and they'll run correctly.
In addition, I must always do the right thing for the people who completely understand normal mathematical precedence of operations. I don't want to assume that somebody who is completely right, and writes equations that follow age-old rules of mathematics, is wrong and try to "fix up" their calculations and silently make them wrong. I can't punish the people that are doing things right just because someone else might do it wrong.
For point 2.), other "do what I mean" systems try to fix this up for you, often to the point that you don't know what they'll do at all. Some give you nasty side-effects if you decide to, say, put a value into a variable. For example, in the Google calculator,
40/3.1416 feet
and
40/pi feet
give wildly different answers, not even having the same dimensions! The same is true for something like
pi / 1 foot
and
3.1416 / 1 foot.
You can't even trust an operator to do the same thing in the same place! If you have the exact same equation, but decide to put one number into a variable, it'd work totally differently! There's no way I'm going to make a language that untrustable.
Perhaps most bewildering and indefensible is the Google calculator's handling of the following, which produces units having completely different dimensions:
1/2 second
-1/2 second
or
1/2 minute in seconds
-1/2 minute in seconds
Augh! Why?
I've looked at lots of alternatives, including making whitespace significant. All of the "do what I mean" fixups do something very surprising, untrustable, and wrong in some cases. No solution will make everyone happy, but this way follows standard mathematical notation (which is very important,) and the International System of Units (SI) rules and style conventions (see rule 5) (which is a presumably a good thing too.)
I've sort of decided that "do what I mean" is impossible... I don't know what people mean. So I have to make them write things unambiguously. Sometimes that means being annoying and pedantic. But if someone actually learns something, and starts communicating better, and makes themselves look better by writing unambiguous notation, then I've done my job.
Yes, it's quite easy. It only takes a couple of lines of code to embed all of Frink's functionality in a Java program. If you're interested in using Frink in your system, please contact Alan Eliasen.
I have provided limited Javadocs describing Frink's integration methods (link opens in new window.)
These demonstrate how to embed a Frink parser in a Java program. Make sure
that frink.jar is in your
classpath.
As a case in point, Frink was integrated with a web server creating the fabulous Frink Server Pages (which brings all the power of Frink to your web applications) in a single evening.
Well, of course. Frink allows you to provide data in a lot of ways. You
can implement a simple Java interface to provide a dynamic source of units,
you can write Frink definitions like mybucket := 12
gallons, or you can write Frink functions to load data from files or
grab data from Web pages. For example, the following simple function grabs
stock prices from the web, given a ticker symbol:
stock[symbol] :=
{
url = "http://www.quicken.com/investments/quotes/?symbol=" + symbol
file = read[url]
if [price] = ( file =~ %r/Last Trade.*?<b>(\d+\.\d+)<\/b>/si )
return eval[price + " USD"]
}
Yes, that's all of it. Yes, I could have written that even more concisely
(but that would be showing off.) (Homework: Try doing it that
concisely in another language. Note that since the data is parsed into
Frink units with dimensions of currency, you can do real Frink calculations
with it, such as converting to different currencies, making adjustments for
inflation (by, say, converting to dollars_1989
if you bought the stock in 1989,) and generally making sure your equations
come out right.
Note: The following applies to specific versions of Java, notably the 1.4 series. With Java 1.5.0 beta 1, the warnings are different, and thankfully less scary.
That is, when you use install the full version of Frink using Java Web Start, why do you get the message, "This application is requesting unrestricted access to your local machine and network."?
I'll mention first that the most powerful way to use Frink is still the one outlined in Downloading Frink, which is what I'd recommend to power users and programmers. Java Web Start works okay if you only want to use Frink as a calculating tool, and not to write programs. (And Java Web Start will automatically update you with the latest version of Frink, which is nice.) Java Web Start is primarily intended to be more convenient for the casual user, but I give you several options for other limited Frink version below. Security issues still apply to any downloaded program, whether it's from me or someone else, and whether it's installed as a one-click or otherwise, so please read on.
As of 2005-04-28, if you're using Java Web Start 1.5 or later, you may get
asked if you want to "associate" files with the .frink file
extension and the text/frink MIME type with the Frink program
you just downloaded. This simply allows you to edit files with the .frink
file extension by double-clicking them. This will not run the
files, but simply open them in editing mode. Java Web Start will also
never change the MIME associations used by your browser... the
MIME associations are only made for the operating system. If you don't want
this behavior, choose "no" when prompted by Java Web Start. (You can also
prevent associations from ever being made by setting your Java Web Start
preferences wherever that may reside on your system. In Windows, It's in
the Control Panel.)
Okay, that aside, I agree that's a scary warning! As it should be--security is important! Actually, you probably realize that any time you download any software from the internet and install it on your machine, it has full access to your files and network. Unless, perhaps, it's written in a language where security was designed into the language, like Java. Java is better at giving you security options, and Java Web Start is just a bit more honorable about making that very, very clear. All programs should have such a warning to make people think twice. But if you think about it, you'll realize that's true of any software download or installer you load from the internet. Below, I give you alternate options for downloading limited versions of Frink, which have some features disabled and thus don't need to request any special permissions.
In addition, it may say something to the effect "failed to verify the authenticity of this certificate," or that it was issued by a company that was not "trusted." True. "Trusted" in this context means "a company who pays Verisign $400 every year." That's how much a "Java Signing Certificate" costs. The certificate is signed only by me, (which is free, but you need some certificate to transmit a signed Web Start application,) so you will see a warning to this effect. If you want to send me $400 every year to buy this certificate from VeriSign, I can remove this warning. But it'll work exactly the same as it does now, no more and no less, so I can hardly justify paying $400 for nothing. That's more expensive than the computer that's serving you these pages and running and compiling Frink and all of the software tools I've used to build Frink put together!
And if you think that you can trust VeriSign, you might want to read this article about how they granted a code signing certificate to some hacker with the company name "Click Yes To Continue".
The first "requesting unlimited access..." warning can't go away for any amount of money (unless you want a limited version of Frink; read below if that's the case.) You'll always see that and need to make a decision. Here's why it produces that warning. As you may know, Java Web Start only gives you two options when packaging a file for distribution: 1.) No access at all to anything outside the most restrictive security "sandbox" or 2.) ask in advance for unrestricted access to everything, whether you're going to use it or not.
That "application is requesting unrestricted access" warning is a bit poorly worded on Java's part; it doesn't actually mean that the program is trying to make (or may ever make) a request for any file or network access or anything else (but it sounds like that, doesn't it?) (And Frink won't unless you, the user, explicitly use one of the features listed below.) Java Web Start has just a sorta lame "all or none" security manager. That's too bad.
I agree that is a scary warning, though. The warning is poorly worded, in my opinion. It does make it sound like the program has tried to access something (or everything,) which isn't the case. Network access is not requested until you explicitly use one of the features listed below. And Frink doesn't access any files outside its own jar file at all, unless you explicitly request that. It would be better if it popped up that warning when the program actually made a request, and let you allow or deny that specific request. The Java language actually has a very nice, fine-grained security framework that allows this, but Java Web Start and the Java applet plug-in have only implemented the most basic, large-grained, ugly, binary version of security possible. All or none, and you have to ask in advance, not when you need it. Before they've even installed it, the user has to magically know if the application seems trustworthy, and whether they may need some feature down the road. Sun could ask, "do you want to open this specific network connection/file for reading/writing/whatever..." when the program actually requests it. This is supported in Java. Java Web Start just hasn't gotten there yet. They will, someday, hopefully, or everyone will be running scared of warnings just like this that actually are being more honest than the other technologies out there, and Java Web Start and signed applets won't fulfil their great promise, and will die a slow death, because they're unusable in the real world.
By the way, most of these objections apply to Android, too, which actually does a better job of being Java security than Java itself. On Android, before you first install an application, it informs you of the permissions that it's requesting, and allows you to make an informed decision to install or not at that point. Applications that try to use permissions they haven't requested are automatically blocked. That's good, but it could have been much, much better if they actually gave the user control over what it was doing at a granular level (as outlined in my paragraph above.)
But you don't have to trust me at all. That's one of the great features of Java. Below, I give lots of other options for using Frink that will run in a completely secure environment.
If you want to try Frink packaged as an intentionally-restricted version which Java Web Start will run in the most restrictive Java security sandbox (and thus has network- and file-based functions broken,) then follow these steps:
Of course, if you want real-time data, (like currency conversions,) any program has to be able to fetch it live from the internet. As noted in the documentation, Internet access is currently only required for the following four features:
If you don't use these features, you'll lose nothing by using the limited version of Frink (unless you explicitly try to read data from local files, or the internet, of course.)
In any case, there are lots of other ways to run Frink (as long as you're not trying to write full-blown programs, which of course requires reading at least the program from local files. If you're writing full-blown programs, you'll need to follow the steps listed in the Downloading Frink section of the documentation.)
Other ways to use Frink include the applet
version, which will present you with the option to allow or deny use of
these network features, or the pure HTML-only web
interface. (In the HTML-only interface, all features work because my
machine makes those network requests on your behalf.) The applet is
exactly the same code as the Java Web Start version, and it
optionally runs in the applet sandbox. Java will ask you if you want to
grant the signed applet permission to access anything outside the sandbox.
If you say no, Java clamps down full security, but the applet will still
run, because it normally doesn't use anything but what's in its own
.jar file. Everything but the four features listed above will
still work. If you try to use those features, you'll see a security
exception, because they need to make Internet connections to fetch their
data.
The Java Web Start version is only different from the applet in that you don't have to download the jar file each time you visit the applet (which is a huge advantage, especially if you're offline sometimes or on a slow connection.) The Java Web Start version just gives you the advantage of having a local copy that you can use even when you're offline (it should go without saying that the parts that require real-time data won't work if you're offline; currency conversions use a cached value) and it automatically checks for new versions if you want it to.
There are enough distribution methods to please anyone, I should hope. It's just a matter of convenience which you choose to use, and if you can live without network features, and if automatic update is useful to you.
It's good to understand security, and not an imagined, illusory security. We all need to think about the applications that don't warn you. If I had instead provided a nice shiny compiled executable installer for your operating system, would you install it? Why would you trust one method of installation and not another? Have you considered that any executable program has full access to your network and files? Java Web Start simply makes the security choice explicit, and makes you make that choice explicitly. And I've given you choices so you don't have to trust me at all; you can run code in Java's sandbox. (I guess you have to trust Sun Microsystems' ability to write said sandbox in that case, then, and Sun has to trust Microsoft, or Linus Torvalds, or Apple...)
Clever people will realize that the Frink jar file is actually exactly the same for all versions, including the Java Web Start version, the applet version, and the full-blown for-programmers version. No features were actually removed in the limited version; it's just the way that it's packaged (one line in the JNLP file) and thus the way your Java Virtual Machine runs it. You've already implicitly trusted Sun and Java's sandbox every time you've visited a web page that contains a Java applet. Maybe you didn't even know it.
Java Web Start, is, in the final analysis, just another installer, but one that makes you take security seriously and make security decisions explicitly. And, most important to me, one that works on more than one operating system, and one that allows automatic updates.
Now I hope I've made you reflect upon what comprises real security, and made you think twice about other people's unsecure, utterly untrustable compiled machine-code executables that you download and install without thinking, or the source code that you download and compile without auditing every single line! (Insert smiley face here.) Despite the warnings, I give you security options that actually mean something.
Alan's Unsolicited Ranting: The main things that significantly differentiate Java from other languages are this security, and the ability to run the same code on any Java Virtual Machine. Sun must make good on the promise of having flexible security so that end-users can decide exactly what they want to allow "untrusted" code to do on their system. (For example, at least allow "save this one file!") This is the main selling point of Java, and the reason it was developed to replace other languages in the first place! And yet Sun has only the most simplistic, useless, brutish, binary, all-or-nothing implementations of security in their flagship implementations (Java Web Start, Java Applets) for the web! This should have been the first thing introduced the first day Java was released! And it's still not there after seven-plus years! That would make Java unstoppable as a code delivery method! The great promise of all of Java's useful secure code distribution is rendered effectively useless for want of a tiny bit of user interface to make security fine-grained enough to be usable! That would eliminate the need for writing diatribes like this entire section, and prevent people from saying "unlimited access to my files and network? I better not even try to install this!" At the very least, Java Web Start should behave like the applet plug-in and allow you to say "no" in which case it would still let the program run, although in a restricted security sandbox, and simply cause any unallowed operations to fail. Do teams at Sun even communicate with each other? And I'm a Sun stockholder... fume... sputter. Now go do something like tell me how cool Frink is, and cheer me up, or I'll whine and pontificate some more.
Note: The warnings are yet again changed in Java 1.6, and are a bit less scary. But fine-grained security has still not been implemented.
Actually, it does now unless you're accessing it through an HDML-only
webphone. The old CGI version will direct you to the new version unless
you're on one of these devices. If the URL you're seeing contains
/fsp/, you're using the new version.
As of October 11, 2002, there's now a new wonderful capability called Frink Server Pages that can be used to embed the power of Frink into an HTML document which is processed by the server. This is much faster than the current web-based interfaces, and very easy to use. The current web-based interface will someday be replaced with a faster FSP-based interface.
First, have you tried the newer applet-based
interface? It runs on your system, making each calculation almost
instantaneous after the applet has loaded. It does maintain state
and allows you to set variables and define simple functions. It allows you
to easily repeat and refine interactive calculations. It runs Frink on
your computer instead of on mine. It's not intended for running
complex programs. For that, download the .jar file.
There is an interface at http://futureboy.us/frink/
that detects browser configurations and works differently whether it's
called from an WML- or HDML-based webphone, a normal web browser, a
wireless Palm VII, or in Netscape/Mozilla sidebar mode. This will reroute
to the latest possible interface for your device, probably implemented in
Frink Server Pages.
That is, why does an end-of-line indicate the end of a statement? (You can also specify the end of statement with a semicolon.) Well, I generally dislike line-based languages; in fact, I hate them. Languages like VBScript start looking awful once you have to wrap lines. So why did I do it? This was originally to support the ability to have an interactive session and a file parser without any change in the code. The interactive mode has since been rewritten (because Java, since its inception, had been unable to reliably read a single line from the console... they finally fixed this seven years after the language was introduced) so this is irrelevant. A language is usually much easier to implement with explicit terminators (but then you need to put in occasional parentheses and brackets where you don't have to now.) The current behavior may change. I don't know.
Actually, one of the original goals of Frink was to support multiple parsers that can have very different syntaxes, but still have all the power of the language. (So far, I've been successful in making this possible.) One syntax may be absolutely minimal for calculations, the other minimal for text processing. And one maybe utterly minimal syntax for use on my webphone or Palm VII. Maybe one syntax would look a lot like Perl, one like LISP, or BASIC, one that would accept reverse Polish notation, or whatever, and another like mathematical notation.
I'd like having the possibility of multiple parsers, and maybe it'll happen someday if there's a compelling reason. (This is why I try to keep my syntax unambiguously parseable by a straight LALR(1) grammar, and make the parser as dumb and minimal as possible... once the lexer and the parser and the optimizer/evaluation engine start talking between themselves to do neat tricks, (Perl does lots of this,) you can't really specify the language as an LALR(1) grammar, and you tend to lock yourself into one syntax.
Oh yeah. Polluted like a fox!
Honestly, though, it's a tradeoff. For quick calculations, you want all of your units to be available instantly without any namespacing or "include" statements or whatever. For complex programs, you may not. One of the primary goals of Frink is to keep the easy calculations just as easy to do as they are today.
If a local variable name is "hiding" a unit of measure you want to use, you
can access the unit of measure using the unit_ prefix. For
example, if you have a local variable m hiding the definition
of the meter, you can refer to the meter as unit_m
Well, I know other people can develop a programming language! I wanted to see if I could!
That may sound a bit flippant, and it's not entirely serious, but there's a lot of truth to it. I want to see what I'm capable of. Developing Frink has primarily been a learning exercise, although I believe strongly that it is a useful tool for just about everyone. I learn best by doing, and by struggling with the concepts myself. I want to learn all the reasons why not to do something one way because I've tried them. I want to hold everything in my head for a while. That's why I've held it to myself for now. I also want to be free to totally rewrite the internals when I feel like it, or learn something new, or find a more elegant solution. This has happened many times.
Designing Frink is also closer to true Art than anything I've ever done on a computer. There are an infinite number of ways to go at every turn. I try hard to make everything elegant and extensible, rather than something that just works. I take pride in my work, and relish the "joy of figuring things out." The thrill of discovery and the fun of solving problems is why I love programming.
Open Source is good. I'm sure that an open-source version of this would show immediate leaps in functionality in a lot of ways as people use it to solve their own problems, or add the pieces I haven't had time to implement.
Of course, I also like to eat. Especially sushi. I'd like to be able to continue work on Frink (or my other projects) so it wouldn't hurt to get money from it.
Also, if you've gotten referred to this section because you asked to get decades of work that you find valuable for free, you better just donate lots of money right now.
It's more like a "labor of love." I didn't expect Frink to be quite so useful, and I'm working hard to make it all it can be. Of all the things I've ever built in my life, I think this one is potentially of the most use to the most people, and I believe in it a lot, and I'd like to continue developing it.
If you find it useful, please feel free to donate to Frink's development.
I'll play along. "Why did you design a whole new tool? There are already lots of tools out there! I can divide a board in half using either a screwdriver or a claw hammer!" Yes, you make a good point. There is no such thing as a "right tool for the job."
I'm not exactly sure that this was originally intended to be a programming language. It was definitely intended to be a calculating tool. Of course, at the back of my mind, I realized that making it into a full-fledged programming language wasn't necessarily hard, and makes it infinitely more useful... so why not indeed?
It's a bit of a (lucky or unlucky) feature of our universe that making a programming language that is capable of universal computation is so easy. Alan Turing proved that something as ridiculously simple as a Turing Machine can calculate anything that any other computer or language could calculate. Even a bunch of NOR or NAND gates, wired together correctly, are capable of universal computation. So making a programming language is easy. But of the universe of possible programming languages, probably a vanishingly small percentage are languages that make your life easier.
Frink can't do anything that another language couldn't be made to do, and vice versa. I couldn't claim it does, and neither can any other language. But some languages have features that make it easier to do one thing or another. Frink is intended to be a very practical language for the problems you encounter most often.
Let's use an analogy. Go into a hardware store and ask the guy at the counter "why do people keep designing new tools? After all, there are already lots of tools available!" He may just stare at you, or, if he's patient, he may answer is that one tool is better for a certain task than another. You could drive nails into a board with a screwdriver, but it would be better to use a hammer. You could use a hammer to turn screws, but it would be better to use a screwdriver.
There is no such thing as one "best" tool. There is no such thing as one "best" programming language. Anyone who insists that one language is good at everything is someone you shouldn't listen to, any more than you should listen to a carpenter who tells you a bandsaw is the best tool available. They all make tradeoffs.
Similarly, Frink is really good at some things, and bad at some things. You can write programs in one line of Frink that would take you dozens or hundreds of lines in another language. You can do physical calculations that you wouldn't attempt otherwise, and it helps you get the answer right. In that, it truly does what computers were intended for--to really make it easy to figure things out.
The whole point of Frink is to help you better understand the world around you, make better decisions, and help you to understand others. It's intended to complement what you know, and to be the best possible bridge between the things that computers are good at and the things that people are good at. It's designed to help you access all kinds of data, understand it better, and do neat things with it. Frink does the hard work, and makes the mechanics easy. After a web search engine, it's the second-most used thing on my computer. I use it when figuring astronomy problems, or mixing drinks, or reading old books, or even watching "I Love Lucy." After all, I want to know why Ricky blew his top when Lucy bought a hat for $49.50.
One way to look at it is that if you do a calculation once, you just need a calculator. If you do the calculation more than once, you should write a program. Or at least a function. Yes, this is overly-simplistic, but you can simply think of a program as a series of calculations that need to be performed in a certain order. And perhaps adding an "input" function or reading data from a file will help you get the job done quicker.
Frink has evolved to where it sits now. It started out as a calculating tool that tracks units of measurement through all calculations to keep you from making mistakes. One day, I made a rather tricky calculation and I was thrilled to see how easy it was in Frink. I couldn't have done it as easily using any tool that I know of. I thought, "now if there was just a way to repeat that calculation a thousand times for all this data I have... and wouldn't it be nice if Frink could parse the data directly from this file? And then sort it, and have user interaction so people could query the data easily? I'd really have something useful then!" At that moment, Frink started to become a programming language. Almost all features have been added so I could solve some real-world problem.
It's a continual process, and it's very rewarding. I get lots of little victories every time I add something new, and I've learned a ton. The best part is that since this is an integrated language, every little tool and trick you add can be used to multiply the power of every other little tool and trick. Sometimes you realize that the little bit you just added can be combined with another little bit to do something amazing. And since Frink is also a library of software, I can embed all of the power of Frink into any Java program that I write. To quote Eric S. Raymond, "Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected."
I remember Stephen Wolfram visiting my university to give a talk about Mathematica. He admitted that Mathematica was a full-fledged programming language, but "there were already so many programming languages out there, that people would lynch me if I developed another one. So we refer to it as 'A System for Doing Mathematics by Computer.' " It got a good laugh.
I'll also note the words of Bjarne Stroustrup, the inventor of the C++ language who said: "I’ll just note that I consider the idea of one language, one programming tool, as the one and only best tool for everyone and for every problem infantile. If someone claims to have the perfect language he is either a fool or a salesman or both."
Frink is written in 100% Java. All of its code and data can be distributed in what is now a .jar file of about 700 kilobytes. In theory, the exact same jar file should work on any platform that supports Java 1.1 or later.
Most handheld devices (phones, PDAs) only run a very limited subset of Java. Most J2ME versions are missing several libraries that are needed to run Frink: math libraries, networking, GUI, and a few others, and will never be able to run Frink. (Some even don't have basic floating-point math!) Most J2ME virtual machines don't support more than 512 kB of memory, and Frink usually takes 3 or 4 megabytes on even the most efficient JVMs, so porting is probably impossible. I've pored through the Java specifications and it seems like it wouldn't work on a device that only supports MIDP 2.0 and CLDC 1.1. It looks like you'll need a device that supports CDC (that is Connected Device Configuration) and not CLDC (Connected LIMITED Device Configuration.) In addition, people have success running it on devices that support Java "Personal Profile", formerly known as PersonalJava. (Although PersonalJava has the latitude to implement or not implement several key libraries, so mileage may vary.)
Installers are available for some handheld devices.
I do use Frink on my Palm VII or my WML- or HDML-based webphone which both access it wirelessly through this web-based interface which detects which type of device it's talking to. The server does all the work. If you have a Palm VII, you can download the Palm Web Clipping file (PQA).
If you can get a Java Virtual Machine (JVM), version 1.1 or later, that runs on your device, then Frink may work on it as well. In theory, it's just a matter of installing and testing the JVM and then downloading the jar file from here and executing that. By default, this will run the text-based interface. There's also a GUI-based interface. (See the docs under the section "Running Frink")
I'm not sure which Java Virtual Machine might work on your device. There is some information on the JavaMobiles Site or you might try Sun's PersonalJava. Frink works with PersonalJava 1.1.1 if they implement the proper optional libraries.
The first problem you may run into is memory size. Although the jar file is rather small, it must be expanded and parsed into memory, and it can use a significant amount of memory, primarily from parsing its extensive data file into memory. (And because Java is inherently a memory pig.) I can't tell you how much memory it may actually require on your system--that's very dependent on the JVM. One tactic, if it uses too much memory, would be for us to cut down its data file, or to possibly hack out some of Frink's data sources, primarily the ones that require connection to the internet. You probably don't need all the esoterica that's in there.
I'd be very interested in seeing if Frink could be made to work on your device. I'll be willing to help you in any way that I can if you should care to attempt. Please contact me if you have questions or manage to get Frink working on a handheld device.
It's quite likely that I won't be providing installers for later
Symbian devices due to Symbian's insane "Symbian Signed" policy which
simply prevents developers from writing software for your phone. Even the
worst, most restrictive operating system monopoly companies aren't
nearly as restrictive as Symbian. Their packaging system is
broken and doesn't coexist properly with older versions of their own
software, scripts don't work if paths contain spaces, it requires
downloading and installing hundreds of megabytes of Windows-only software
to package a simple application, it takes weeks to go through the official
process, you can only submit freeware applications every few months, the
"testing" process is obviously a sham (they don't have access to your
source code, so they have no idea what it might be able to do, nor do they
test for things like memory leaks, and do you really believe that Symbian
will devise test cases to test all of Frink's functionality? What is
their "guarantee" worth, then?) etc. And the
ridiculous part is security and signing can already be handled by Java's
pre-existing security mechanisms. If you own a Symbian device, please let
your vendor know that their packaging and signing process is severely
harming the usefulness of their device. (Hint: Look at the Sharp Zaurus,
whose .ipk files are really just .tar.gz files, and can be
readily made in minutes with any operating system. And should I repeat that
Java already has its own signing and security mechanisms, and has for
years!) They are simply killing their own device by preventing
developers for writing software for it. I wouldn't consider buying a
Symbian device, knowing what I know about software availability. I'd
rather buy any other platform that's more open. I'm trying to be
diplomatic here, but Symbian's policies and utilities for packaging and
installing software are quite simply the worst I've ever seen.
x/x not return 1?Note: This question might be posed in a lot of different ways, such as:
x-x not return 0?Aha! You've discovered what is probably the most common question/problem in interval analysis. It's called the "dependence problem." The other most common question/problem is called "overestimation" and you see that here too. The two problems are closely related.
For a quick intro, see the Interval FAQ provided externally (link opens in a new window).
In short, if the same variable appears multiple times in an expression, the dependence problem may occur. This manifests itself as an overestimation of the size of the resulting interval. You'll note that when overestimation occurs, the correct values are contained in the intervals you get back, but the intervals are somewhat broader than you might want.
To quote one of the authoritative texts on interval arithmetic (Global Optimization using Interval Analysis by Hansen and Walster, section 2.4):
(In this case "sharp" means containing no more than the minimum interval necessary to contain the possible values.)"In general, each occurrence of a given variable in an interval computation is treated as a different variable. Thus
X-Xis computed as if it wereX-YwithYnumerically equal to, but independent ofX. This causes widening of computed intervals and makes it difficult to compute sharp numerical results of complicated expressions."
"This unwanted extra interval width is called the 'dependence problem' or simply 'dependence'. One should always be aware of this difficulty and, when possible, take steps to reduce its effect."
"Moore notes that if a particular interval variable occurs only once in a given form of a function, then it cannot give rise to excess width because of dependence."
Is there a way around this? Well, sometimes, and that's where human-level intelligence comes in. Frink tries to do the right things with intervals, but it won't restructure your equations to avoid dependence. (Actually, as of the 2009-07-19 and 2009-08-04 releases, this is no longer true. Read on.) This is left up to the mathematician doing the analysis to see if doing so is valid. Simplifying your expressions is almost always beneficial before doing interval calculations.
For example, doing an interval calculation on
x^2 + x
May yield narrower intervals than the equivalent:
x (x+1)
(Try evaluating it with x=new interval[-3,4] .)
It's thus left to the programmer to algebraically simplify their
expressions, when possible and reasonable, to minimize dependence.
Sometimes you can eliminate dependence entirely. For example,
(x-y)/(x+y) can be written as the form
1 - 2/(1 + x/y). Since each variable
occurs only once in the latter expression, dependence is eliminated and the
bounds will likely be narrower when doing interval calculations.
No environment or language will do this automatically for you; it's why thought still has to go into interval analysis to minimize overestimation.
Important Update: As of the 2009-07-19 and 2009-08-04 releases of Frink, some simplifying symbolic transformations are now performed on expressions, which may alter the output of programs that use intervals. These perform some of the symbolic simplifications noted above. The effect of these, if they have an effect on your program, will be to make interval bounds "tighter."
Note that there's a lot of difficulty and problems with doing symbolic
manipulation or automatic simplification of equations and doing
many of these types of numeric operations. For example, performing the
simplification x-x = 0 might be true for the real
numbers, but is not necessarily valid for intervals (think about replacing
both instances of x with the interval [1,2]). Or
even for numbers containing units of measure! Intervals are no longer
distributive. Quaternions are no longer commutative. So you have to know
the kind of numbers that may someday be contained in your
variables to do the right thing. Sigh.
Here are some very useful pointers about converting real-valued equations to use intervals:
The latter has very good practical advice:
"If you get narrow intervals, you know you are safe. If you get relatively wide intervals, you can decide how hard to work."
Interval arithmetic is subject, like quantum mechanics, to multiple, equally-valid "interpretations,". Understanding these various interpretations may make these odd rules more clear. You can think of an interval in two ways:
Again, interval analysis will give you an interval containing your answer,
but the interval may be overestimated. (Note, for example, that if you
perform x/x when x is an interval, the result
will contain the value 1.) The correct value will still
be contained in your intervals. If you look into simplifying your
equations and reducing the number of times a particular variable occurs in
an expression, you may be able to reduce or completely eliminate this
overestimation. You may want to try writing your expressions in a variety
of ways; it's not always clear which will give the tightest results for
given numbers. Again, this is fundamental to all interval
analysis and isn't anything unique to Frink. This is the topic of vast
textbooks and continual research, and rears its head in almost all interval
analysis.
Comments/questions to Alan Eliasen