For the bedroom example someone posted, here's the equivalent in pint:
import pint
# Possibly my least favorite thing about Pint is
# the verbose importing/instantiating dance
u = pint.UnitRegistry()
q = u.quantity()
# there are multiple ways of making <Quantity> objects:
volume = q('10 feet') * q(10, 'feet') * (10 * u.feet)
volume.to('gallons)
# How deep could you fill the room?
(q('2 tons') / (q('10 feet') * q('12 feet') * u.water/u.gravity)).to('feet')
Notes:
- Pint has far fewer material property entries in its database (though one can make arbitrary unit registries --- I'm wondering about an importer for the Frink ones... but https://frinklang.org/frinkdata/units.txt doesn't seem to have a license?)
- That said, I'm not wild about Frink's treatment of material properties: Why is the constant `butter` a density, but `eggwhite` a mass, and `naturalgas` a specific energy?
- Pint works (mostly) nicely with numpy and can (sometimes) drop into existing code, since <Quantity> objects quack like builtin numbers.
I haven't even tried the software yet, but that file is a great read. An excerpt (part of a rant about the definition of the candela):
// What really annoys me is that the official definitions
// don't come right out and say, "okay, we're sorry, this
// is obviously a useless definition for any other
// wavelength, and it doesn't even make sense for *that*
// wavelength. We know. It sucks. The guys at the 16th
// CGPM went out and got drunk the night before instead of
// working on the definition, and they all sheepishly passed
// this in in the morning, and went back to bed. They got
// fired later, make no doubt. It's on our list of bugs.
// We're sending in the Wolf to fix it directly.
// Here is the workaround, but we consider it broken
// and we're ashamed to have ever put it forth in this
// useless form and left it this way for 30 years.
// For now, here is one single draft standard equation to use
// for other wavelengths. Download it here. We promise
// that the link works and contains a computer-readable
// table (though we're too sloppy to actually create a good
// smooth polynomial fit that would be a lot cleaner and
// easier for everyone) and is not some PDF of a terrible
// unreadable old re-scan, stashed away somewhere, making
// you wonder if it's valid today, nor is it a ridiculous CIE
// document that you have to *pay* a hundred bucks for, when
// we could and absolutely need to distribute it for free.
Wow, I completely agree that file is a great read.
Also, for reference, the closing " is in the following paragraph, but I'm not quoting it because the 2 paragraphs after that one made opening the link worth my time.
That data is almost all taken from GNU Units, including the descriptions, which means it might be under the GPL. Frink itself doesn't seem to be open source at all?
I wrote a parser and interpreter [1] for the GNU units descriptions a while ago, you can see the parsed json here [2] (kg! are base unit definitions, "micro_" are prefixes)
A map is not copyrightable. It is just a diagram of facts. Mapmakers protect themselves by inserting fake data which they can then use to claim copyright.
>In Alexandria Drafting Co. v. Andrew H. Amsterdam dba Franklin Maps, the court ruled that "fictitious names may not be copyrighted" and "the existence, or non-existence, of a road is a non-copyrightable fact".
Maps are copyrightable (I think?), but the trap streets themselves aren't. They're only there to detect when someone is copying the map.
Heh, I actually learned about trap streets when talking to a cartographer who made the muni map of SF you find at all the bus stops (much like this one: http://www.mobilemaplets.com/thumbnails/261_thumbnail-1024.j...). He told me he added a small alleyway in the map named after his family that doesn't actually exist, and they catch people violating their copyright all the time with it.
As far as I know, facts and information can't be copyrighted, which means at the very least the raw data in units.txt can be used freely with flagrant disregard for licensing.
Let's say you wanted to fill your bedroom up with water. How much water would it take? Let's say your room measures 10 feet by 12 feet wide by 8 feet high.
10 feet 12 feet 8 feet -> gallons
552960/77 (approx. 7181.298701298701)
It would take approximately 7181 gallons to fill it. Note that you get both an exact fraction and an approximation. (If you don't want to see the fraction, put a decimal point in any of the numbers, like 10. or 10.0.) How much would that weigh, if you filled it with water? Frink has the unit "water" which stands for the density of water.
10. feet 12 feet 8 feet water -> pounds
59930.84215309883
So it would weigh almost 60,000 pounds. What if you knew that your floor could only support 2 tons? How deep could you fill the room with water?
2. tons / (10 feet 12 feet water) -> feet
0.5339487791320047
So you could only fill it about 0.53 feet deep. It'll be a pretty sad pool party.
This sits firmly in the "Neat, and now I'm sad I don't have a practical use case for this"
I'm not quite sure what this means, but your profile proves you're not a spam bot, so I guess I won't flag it... did you submit this in the wrong tab or am I missing something?
Programs reflect the character of those who wrote them.
That's why using GNU stuff is such a pain (for me, at least.) They are the most fastidious, unforgiving, unhelping pieces of software to ever be written.
Indeed. The most singularly maddening thing to read in a man page is undoubtedly "The full documentation for foo is maintained as a Texinfo manual. If the info and foo programs are properly installed at your site, the command info foo should give you access to the complete manual."
Yes, that is some next level BS. Why should I learn to use an arcane thing like info just to read a manual page, when 99% of the software on the same computer uses man? It's not just laziness. GNU software is usually good, but it has a strong hint of forcing your way onto other people, that I really dislike.
There are some great notes in there and also things that you will almost certainly not know already.
Beware the SI's broken definition of Hz. You should treat the radian as being correct, as a fundamental dimensionless property of the universe that falls out of pure math like the Taylor series for sin[x], and you should treat the Hz as being a fundamental property of incompetence by committee.
[...]
Either way, if I ever develop a time machine, I'm going to go back and knock both groups' heads together. At a frequency of about 1 Hz. Or better yet, strap them to a wheel and tell them I'm going to spin one group at a frequency of 1 Hz, and the other at 1 radian/s and let them try to figure out which one of those stupid inconsistent definitions means what. Hint: It'll depend on which time period I do it in, I guess, thanks to their useless inconsistent definition changes.
The rest of the diatribe on Hz ends up amusingly spittle flecked with some decent frothing in evidence. I always knew that the kilo was bollocks (lump in a jar) but that barely gets a nod here. I had no idea about the state of some of the other units (like Hz)
Hmm, I guess it would have worked if a radian was defined as 1/(2pi) instead of 1. On the downside, you'd have to redefine things like `sin` to take multiples of "whole rotations" to make `sin(2pi radians)` (i.e., `sin(1.0)`) do the right thing.
It has a clear and fixed definition, but that definition isn't the numeric constant 1. Associating it with a numeric value is a convenience, and different choices give different conveniences.
In physics "c" is a constant. In some circumstances it's most convenient to define it as 1, and in others we define it as 3e8m/s.
You can argue that 1 is more convenient for radians than 1/2pi because of identities with natural logs and derivatives of other transcendental functions, but that's an aesthetic call -- you can still get similar identities, just with different scaling factors. More to the point, the derivative of `sin(x radians)` will still be the derivative of `cos(x radians)`, so I'm not actually sure that argument holds water -- another way of saying "you have these scaling factors" is to say "you have to use the right units."
Maybe that's still too big a pill to swallow, but I'd be wary of the endowment effect here.
I think you're wrong. Let's investigate the trigonometric functions from the point of view of differential operators. Those are essentially functions that take in functions and spit out functions. The operators we'll look at are made up of derivative operators like d/dx. Let's say we have a differential operator D. We might want to find properties about it. One good place to start is to find its kernel (all functions u such that Du = 0) and find it's eigenpairs (all pairs (k, u) such that Du = ku for k a constant. We'll focus on the latter problem
Let's look at the simplest D, that is D = d/dx. What function satisfies du/dx = ku? An exponential, of course, because functions of the type u = a^x have derivative u' = ka^x for some k. What'e the most fundamental such function? Well, it's the one where du/dx = u, i.e. k = 1. This is none other than the exponential function e^x with e as currently defined. Every other choice of a "fundamental" exponential function will run into a lot of inconveniences later on.
What about another example. Let's look at D = d^2/dx^2. It's simple enough. What functions satisfy d^2u/dx^2 = ku. It appears the solution depends on whether k > 0 or k < 0. If k > 0, we can show that the hyperbolic trigonometric functions do the trick, so we can rehash the discussion above. If k < 0, however, we get into the usual trigonometric functions, namely what we now know as sin(rx) and cos(rx) for some choice of r, since for both u'' = -r^2u and you can find r from there. Again which r is the most fundamental? r = 1 of course, and this leads to the usual trigonometric functions.
If you choose r to be something else, we'd have a problem as we'll no longer have the nice property that sin'(x) = cos'(x) and so on. Also, these two examples are really the same example since e^(ix) = cos(x) + i*sin(x).
As a side note that should really be the main note...aesthetic calls are very important in mathematics. No one likes scaling factors to their identities. We like using fewer symbols to talk about common concepts. If we could make e = 1 or pi = 1 without inserting the opposite problem of complicating almost every single identity in mathematics needlessly, we would have done it a long time ago.
I think the reason c = 1 works in physics is because you can change a few other constants around (usually to 1) and things works out well. I fail to see how we can do the same in mathematics where things need to work on many many different layers. Also, if you look at any "Natural units" systems, they all have pi in them. Why didn't they get rid of it? Because it's even more fundamental than c!
> No one likes scaling factors to their identities.
Sure, I totally agree. Doing things this way would make some things more intuitive (Hz would "work right") and some thing harder. As you point out, the identity
e^(ix) = cos(x) + i*sin(x)
would need to be rewritten
e^(ix) = cos(x/2pi) + i*sin(x/2pi)
or equivalently
e^(ix) = cos(x radians) + i*sin(x radians)
if we redefined `sin` and `cos` to take "revolutions" instead of radians. It's obviously worse in that regard -- it's longer to write, less intuitive, more difficult to work with etc.
It's probably a horrible idea. It's not wrong, though. It even has some nice properties:
Frink is really great as a sophisticated calculator (it is also quite powerful and nice programming language, but I've never used it's full potential). It helped me with cosmology classes assignments (very convenient unit conversions and built-in all physical constants I could wish for) . I just wish it had a better ide. I would love Frink Jupiter kernel with nice latex formula display. I emailed the author about that, but he wasn't interested. Maybe some skilled person from HN would take the challenge? Frink deserves more love, the amount of details included there is amazing and it's one man job. Very impressive.
I've actually built a similar language directly inspired by this one. It's been left to sit for a long time due to some issues with the implementation and language itself.
I originally built it because I wanted an easier to integrate version into an IRC bot, the java implementation of Frink was hard to integrate safely (keep it from running too long, max memory usage, etc.) at the time and having a native perl version made handling a lot of that easier.
Language wise, the problems I ran into were that, at least in my implementation, it began to get very difficult to parse a lot of things unambiguously and I couldn't solve them without a larger redesign of the language. In particular handling arrays and making user defined types easier to use and make (you can emulate that right now with currying and closures to make function calls simpler). I never got it past that step because I didn't want to do a complete redesign of the language and break all compatibility, right now about 80% of all Frink programs will probably just work fine in Farnsworth, and 90% with some minor tweaks.
I think that is the joke, it's a reference to a Monty Python sketch about a (deliberately?) wrong Hungarian phrasebook. "I will not buy this record, it is scratched" is one of the examples in the sketch.
Frink has been around for a long, long time, and the author has had a great sense of humour about some of the units he's thrown in. While I rarely need the tool, it's great to know that I can deal with cubits whenever I need to.
I'm surprised the site died. It looks like a static website, and even a small webserver in a default configuration can serve thousands of files per second.
It's much more likely to have reached maximum concurrency than maximum throughput. When the site is accessed by a general audience, many will access it through a 3G connection or worse, and their slow speeds will cause the number of concurrent connections to balloon. This website uses Apache, which sometimes defaults to a maximum of 10 concurrent workers.
For the bedroom example someone posted, here's the equivalent in pint:
Notes:- Pint has far fewer material property entries in its database (though one can make arbitrary unit registries --- I'm wondering about an importer for the Frink ones... but https://frinklang.org/frinkdata/units.txt doesn't seem to have a license?)
- That said, I'm not wild about Frink's treatment of material properties: Why is the constant `butter` a density, but `eggwhite` a mass, and `naturalgas` a specific energy?
- Pint works (mostly) nicely with numpy and can (sometimes) drop into existing code, since <Quantity> objects quack like builtin numbers.