Forum Moderators: open
Heh, the Equator spins at only a thousand miles per hour; but we go about 2 million miles per day through space in our orbit around the Sun (93 million miles from Sun, one complete orbit every 365.25 days)!
What if they travel faster? would they be going back in time?
Your theory appeared in the film Superman! There the girl dies and Superman flies around the Earth to go back time. But this does not work in our world :(.
When you stay in any point on the Earth, the sun is not moving. You are moving with the Earth so your position from the Sun variates. Because of this, the position of Sun from you variates: then you see the Sun moving normally. If you counter Earth's rotation speed, then you won't be moving, so you will see the Sun stopped: its position from you does not vary. If you move faster, you will see the Sun going backwards, but time will still going forward.
But you can do it better: search something about Einstein's Relativity theories, and you will find that, if you move fast enough time will be deformed and pass slowerly. But your body would also be deformed, your mass would tend to positive infinity, etc. A bit difficult ;) Even better: there are some who believe that if you move faster than light, you will become energy.
Greetings,
Herenvardö
Woah, g1smd you're right...
so the length of earth's orbit according to the google calculator is:
2 * pi * 93,000,000 = 584,336,234 million miles
so in one day the earth travels:
584,336,234 / 365.25 = 1,599,825.42 million miles!
That's 66,659.3925 miles per hour!
trivial but interesting.
Difficult to fathom!
...btw 1 fathom = 1.8288 meters ha!, alright enough :-)
We are in an arm of our Galaxy which rotates about its centre. Apparently we rotate around the centre at 900,000 km/h.
But that is still nothing
Just think what speed the galaxy is moving relative to other galaxies. Double or triple that, and then the whole universe is expanding at a rediculous rate on top of the speed we are whizzing around.
What it boils down to is that we should all stop running around because we're moving fast enough even when we are standing still....going nowhere fast.
So the calculator is a nice tool, etc. but it has some lacks, of course.
Greetings,
Herenvardö
The calculator is cool, but I have to admit I haven't used it since I was first wowed by this thread.
Does it have any practical applications apart from a lookup table for scientific units? I would still prefer a speadsheet because I nearly always need to work further on the result of a calculation.
Apart of these uses, I think gcalc is of no more use. Any other needs should be solved with more specific tools.
Greetings,
Herenvardo
You can use the 3-letter currency code (like USD or JPY... note this is case-sensitive), the name of the country, like
10 USD -> Japan
Or, if you want to know the name of the currency used in a certain country, just use the question mark (which gives info on the specified unit):
?Singapore
Along with currency conversions, you can also do historical depreciations of the U.S. dollar and the British pound. I was just watching the movie "A Bronx Tale" (set in 1960) and somebody offered Robert DeNiro $150/week to run numbers. In Frink, that becomes:
150 dollars_1960
If you want to turn that into a yearly salary, converted to the buying power of modern dollars, use:
150 dollars_1960/week -> dollars/year
That comes out to about $48,000 per year in modern dollars.
Frink also allows you to set variables and define functions so you can actually repeat calculations with different numbers. I also mentioned that it's a full-fledged programming language, so you can do more complex calculations, read data from files, steal data from the web, etc.
I tried to install your application and Java gave me a warning:
This application is requesting unrestricted access to your local machine and network.
You'll never get people to install that, no matter how honourable your intentions are.
But I think that people realize that's true of any software download. I have lots of downloads, after all. :)
But you don't have to trust me at all. Below, I give lots of other options for using Frink that don't require any downloads.
As you may know, Java Web Start only gives you two options when packaging a file for distribution. No access at all to anything outside the most restrictive "sandbox", or "ask in advance for unrestricted access, 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 has tried to make (or may ever make) a request for any file or network access or anything else. (And Frink won't unless you, the user, explicitly use one of the four features listed below.) Java Web Start has just a sorta lame "all or none" security manager.
I agree that is a scary warning, though. :) It does make it sound like the program has tried to access something (or everything,) which isn't the case. 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. Some applet sandboxes do just this.
I chose not to package a crippled version; I guess I could make two Java Web Start packages, one crippled with the all-or-nothing access flag turned off, so you wouldn't get that warning, but would lack 4 features (listed below.) Would that be better?
Instead I've filed "requests for enhancements" for Java Web Start to give more fine-grained security control. Someday they'll have it, I hope, and warnings like this can go away until the program actually makes a request.
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 only required for the following four features:
* Language translations (HTTP)
* Currency/Exchange Rate conversions (HTTP)
* Historical British price data (HTTP)
* Historical values of the U.S. dollar (FTP)
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.)
You can use the applet version, 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.) Just follow the applet links (and please read the comments on that page.) 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 distinct advantage.) 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.
Enough distribution methods to please anyone, I should hope. It's just a matter of convenience which you choose to use.
By the way, your previous comment was interesting about wanting other live sources of information from the internet. The FAQ shows an example of fetching stock prices in real-time which can be done in about 2 lines of code. You can add your own sources to anything that interests you (let me know, and I might include it in the next release!)
Hope this helps! I'll add a discussion of that scary message to the FAQ! Thanks!
[futureboy.homeip.net...]
It's exactly the same jar file; I just removed one line from the .jnlp file.
That's exactly why I would like a toolbar to do the job. Each time I use Xe.com I need to type in URL (I know the URL to the Universal Currency Converter by heart), write in an amount and select currency.
Wouldn't it be easier to go to the toolbar and type "100 USD in EURO" or "sell 100 USD into EURO interbank"?
At the very least Google could tell me the competitive exchange rate which I could use to negotiate with my bank.
It would have been easy if we could have compared them thus (this is Frink notation; no, I didn't have Frink with me; it works on a wireless Palm or a WML- or HDML-enabled webphone, but my service doesn't work in Germany):
Germany:
.6545 EUR/liter -> dollars/gallon
(that's $2.69 / gallon)
U.S.:
44.1 cents/gallon -> EUR/liter
(that's .107 EUR/liter)
Why did you use "dollars" and assume US dollars? --> use USD instead.
And, in Europe those liters, are going to be litres. Likewise note metres.
Why did you use "dollars" and assume US dollars? --> use USD instead.
Oops! I should have used "USD" to make the example clearer. That was dumb on my part. As I noted before, Frink understands "USD" or any of the 3-letter ISO-4217 currency codes, along with many other synonyms for human readability, (especially in case you don't remember what some country's ISO code (or your own) may be!)
I do realize, of course, that more than one country uses the "dollar" as their currency. It used to be better, though, to just use the word "dollar".
The reason "why" is mostly historical. Before Frink did currency conversions, it didn't matter whose dollar you meant--someone from Canada or New Zealand could write "5 dollars/hour * 97 minutes" and the answer would just come out fine in dollars, never mind whose dollars, because a "dollar" was just a name with no relation to any other currency. It was everybody's dollar. (It still works this way for cases like this.) It actually worked better, for more countries, this way.
That's not always the case any more (if currency conversions are compiled in and used, the picture changes.) The word "dollar" has merely lingered as an arbitrary convenience for the people who never do currency conversions. If they use "dollar" in their input, they get "dollar" in their output and it doesn't matter whose dollar they mean... unless they try to convert to another currency. That's why my previous example was so dumb on my part--I should have made it explicit, it being a currency conversion and all. As an arbitrary choice, when I implemented currency conversions, the U.S. dollar was chosen as the thing you get when you just say "dollar". The choice was merely as convenience for me (I do get some perks, being the designer and all. :) )
Nobody else has to use "dollar"; you can and should use the 3-letter currency codes, or any synonym that you want to define. I do keep Frink as country-neutral as possible and "dollar" implying USD may go away someday. I may change the default unit to explicitly say "USD" on output so you know the implications immediately. I know I'll get complaints both ways.
But as it says in the documentation, the base currency (along with everything else) is fully customizable by editing your units file. Most people, after they've used Frink a bit, tend to change their defaults to be whatever they use the most, and make their own shorthand if they like. (You can also change your default display units without ever touching the units file.) I used to provide several units files with base currencies in Euros, GBP, etc., but then I found that some people liked to see "EUR", some liked to see "euro", some wanted the Euro symbol, some liked to see "Euro", some probably wanted the Greek orthography. Then people wanted to use their local term "cent", as 1/100 Euro, not 1/100 of whatever "dollar" was defined.
Best to let everyone customize their own, which is what I do now. Australians are free to define the term as
"dollar := AUD" in their units file which I know some have done. Personal choice, and *any* definition I make can be changed in your own copy of Frink.
Some people even rename the mass unit "pound" to something else so they can have their local currency called the "pound".
I just need to be clearer in public examples which include currency conversions! Thanks for the suggestion!
And, in Europe those liters, are going to be litres. Likewise note metres.
Of course, Frink understands both spellings and neither are preferred in any way. Most countries in Europe spell it yet differently!
Many people don't realize that the Système International d'Unités (SI), the International System of Units, which is the worldwide standard for what used to be called the "metric system", does not dictate the spelling of these names. They define only names, definitions, and symbols (like m, kg, s, and A,) and set rules for the use of these symbols. Frink follows these rules.
The "names," though, are allowed to be spelled however is acceptable by the spelling and pronunciation rules in any language, (say, German and Dutch use "meter" as it works with their pronunciation rules.) (You just can't call a meter a "foobar," as that's a different essential name.) So, the following are all acceptable:
I don't recognize all of these in Frink, though. (Maybe someday!) It would take too much time for me to put in every possible spelling of every unit of measure in every language (and it would create lots of collisions,) but I'd be glad if people supplied units files translated to their own languages, and with super-ultra-obscure local units of measure. (I probably already have all the super-obscure ones. :) Frink is Unicode, too, so you can write in Macedonian, Uyghur, Greek, Cherokee, whatever. (With some minor, unavoidable technical restrictions on allowed variable names as outlined in the documentation.)
All countries must, however, write it "m" if they're using the symbols. This is why you'll find the symbols (only) usage on most exported items. Just cheaper and easier to do it the one portable way, as there's only one way to write the symbols in all languages.
That's why Frink (by default) outputs all of its units of measure in terms of base SI symbols, by the way. Not to be cryptic, but to work for the largest possible number of countries and languages.
takagi:
I already said that with toolbar it's easier! Even so, I think you did well giving more details.
Greetings,
Herenvardö
# 2003-09-30 # - # 1969-08-19 # -> days There are more samples in the "Date/Time Handling" section of the documentation. Feel free to send me e-mail directly (e-mail address is on those pages) if you need more help.
The Google calculator doesn't handle dates at all.
I'm sure the Google Calculator will develop further.
So the way Frink handles dates is like in Access?
Cool that it is named after Professor John Frink in The Simpsons, and that was the thing that first came to mind even before it was confirmed by yourself. :-)
[EDIT : Added question]
As to the extensibility of the Google calculator, I dunno. From my experience in writing parsers and calculators of this sort, and developing programming languages, I think they've painted themselves into a bit of a corner with too much "do what I mean." That only works up to a certain point; if you want to make a multi-purpose powerful system, you need to have an unambiguous syntax.
It doesn't matter how good of a programmer you are; when there's ambiguity, there's ambiguity, and in some cases you'll do something very wrong if you try to "do what I mean" and guess incorrectly.
Google doesn't even follow normal mathematical precedence of operations; division, in some cases, is treated as being a lower precedence than multiplication, instead of the same, which is certainly unexpected. This is why the two following calculations in Google get wildly different results, not even having the same dimensions:
40/pi feet40/3.14159 feetNow that's certainly unexpected, and untrustable, and it is a result of trying to do too much "do what I mean." You can't even rely on the operators to do the same thing in the same place in a calculation. At some point, your parser simply becomes an inextensible mess of special-case rules. They'll have to change this if they want to go forward, and I don't know if they will.
I also doubt that you'd ever be able to set variables in the Google calculator and re-use the results of a calculation, other than by cut-n-paste or retyping results manually (which loses precision.) I doubt you'll ever be able to do arbitrary-precision math, nor define your own functions. All of these have a cost, and won't work easily with Google's stateless architecture.
If Google wanted to do date/time math like above, they'd have to have some way of distinguishing that ISO date format 2003-09-30 (the most commonly used date format in the world) from subtracting the number 2003 minus 9 minus 30. At some point, you can't try to do what the user means because it's completely ambiguous. I disambiguate by forcing pound signs around all dates. They'll need to do something similar.
Because of that, I think that the design decisions that were made for the Google calculator essentially limit what it'll ever be able to do.
At some point, you actually have to help your users learn what's ambiguous, learn normal mathematical precedence, and learn proper usage of terminology. That's always a better idea, anyway. Teach a man to fish, and all that...
100+20%+10 => 100 + (20%) + 10 = 110.2
Strange results.....
