Frink
frinklang.org
frinklang.org
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')
- 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.
This is just a list of facts, no? You can't really copyright such a thing.
Why not ask if there is a license for this file?
Edit: And as I see in this thread there is gnu-units (https://en.wikipedia.org/wiki/GNU_Units) probably there is something with a license.
https://en.wikipedia.org/wiki/Trap_street#Legal_issues
>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.
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)
[1] https://github.com/phiresky/qalc-react
[2] https://github.com/phiresky/qalc-react/blob/master/data/gnu-...
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.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.
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.
3 m 4 m 3 m -> liters
36000
3 m 4 m 3 m water -> kg
36000
2 metricton / (3 m 4 m water) -> m
1/6That'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.
How much air in your room weighs?
What power do you need to transfer energy at the same rate as when you fill tank of gasoline?
> In short, candela = EPIC FAIL.
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)
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.
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!
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)
e^(ix) = cos(x/2pi) + i*sin(x/2pi)
e^(ix) = cos(x radians) + i*sin(x radians)
It's probably a horrible idea. It's not wrong, though. It even has some nice properties:
sin(x) = -sin(x + 0.5)
sin(x) = sin(x + 1)
Hz == 1 revolution / sec
revolution == 2 Pi radians
The problem of not having the revolution as the conversion unit is the massive oversight.
https://metacpan.org/pod/Language::Farnsworth
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.
Huh. I don't know why, but I never thought I'd see a Perl project anywhere in HackerNews. There might literally be dozens of us.
>"I will not buy this record; it is scratched." -> Spanish >No compraré este expediente; se rasguña.
is wrong x).
Frinky's not loading so good right now, HN.