Frink
frinklang.org236 points by lisper a month ago
236 points by lisper a month ago
This is interesting, but I doubt anything will ever come up in my lifetime that is even close to replacing Emacs Calc for me. I still consider it to be the best scientific calculator ever written. It's crazy that many Emacs users aren't even aware that it exists. It comes with an almost ridiculously extensive manual, complete with exercises and everything:
https://www.gnu.org/software/emacs/manual/html_mono/calc.htm...
It's probably overkill for most people, and I'm sad that I don't get to use it as much as when I was a student, but it's still a beautiful rabbit hole to fall into. And it works in a terminal just fine. :-)
Thanks, Deng! I'm one of those Emacs users who has been using Emacs for years, and I didn't know Emacs Calc existed.
Reading the manual now...
Allow me to recommend Andrew Hyatt's tutorials: https://github.com/ahyatt/emacs-calc-tutorials
I present you, if you're into this sort of thing, one of the snarkiest files on the internet.
https://frinklang.org/frinkdata/units.txt
Alan's editorializing on the nature of radians and hertz is my favorite thing.
// 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.
This is gold.
> In other words, if you use the Hz in the way it's currently defined by the SI, as equivalent to 1 radian/s, you can point to the SI definitions and prove that you follow their definitions precisely. And your physics teacher will still fail you and your clients will think you're completely incompetent because 1 Hz = 2 pi radians/s. And it has for centuries. You are both simultaneously both right and both wrong. You cannot win. You are perfectly right. You are perfectly wrong. You look dumb and unreasonable. The person arguing the opposite looks dumb and unreasonable.
Huh? Seems this quote confuses correspondence and equivalence. A frequency f = 1 Hz = 1 s^-1 (aka cycle/s != rad/s) corresponds to an angular frequency ω = 2π rad/s (ω = 2π f) but they're distinct concepts and quantities. The Hz was introduced in SI with all those considered. Basically both statements "1 Hz = 1 rad/s" and "1 Hz = 2π rad/s" are wrong. The only dumb is this quote tbh.
The point being made in that file is really that, if you take the SI definitions literally, 'cycles' and 'radians' end up both being dimensionless and equal to 1, which is stupid.
There are other contenders if you like your snark on the ranty side.
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
> // I dislike having a prefixed unit as the base reference. What a horrible decision. Why don't you just have it go to ten and make ten a little louder?
Really delightful.
That question (regarding the unit of mass, not the volume control) does apparently have an answer[1,2], and the answer (if true) is really funny: this was in fact the original plan, and the proposed unit was called the grave[3] (pronounced “grahv”). Then the French Revolution came and that name’s similarity to the word grave (count, the noble title, from German; cf. English margrave) led to it being superseded by the gram.
I don’t like the reference I have, though, so take this whole story with a grain of salt.
[1] https://phys.libretexts.org/Courses/Prince_Georges_Community...
Haha, wow. And he really has it in for the candela too. Thanks for pointing to this, I would never have thought to look here, but it's an excellent read.
// Alan's editorializing:
// I think the candela is a scam, and I am completely
// opposed to it. Some good-for-nothing lighting "engineers"
// or psychologists probably got this perceptually-rigged
// abomination into the whole otherwise scientific endeavor.
//
// What an unbelievably useless and stupid unit. Is light
// at 540.00000001 x 10^12 Hz (or any other frequency) zero
// candela? Is this expected to be an impulse function at
// this frequency? Oh, wait, the Heisenberg Uncertainty
// Principle makes this impossible. No mention for
// correction (ideally along the blackbody curve) for other
// wavelengths? Damn you, 16th CGPM! Damn you all to hell!
//Interesting project. I use command line Qalculate [1] for this (has a very similar feature set to Frink AFAICT) and Pint [2] for scripting. I feel like unit-aware calculators are hugely underused by physical engineers, it's the same idea and benefit as type safety but they're virtually unheard of, everyone just uses excel. Having guaranteed dimensional correctness is so great for the early design stage, it makes it a lot easier to explore the problem space.
[1] https://qalculate.github.io/ [2] https://pint.readthedocs.io/en/stable/
I use the gem 'ruby-units' with "irb" on the command line. It's an exceptionally useful library.
Talking about Frink alternatives.. Back when I was using Windows I really liked SpeQ[1]. The cool thing about that one was that you could define values and functions and modify any part and it would immediately recalculate everything.
Unfortunately it seems to be abandoned (last release was from 2010).
Is this still true if you're using metric?
Just curious, as the Frink examples were all imperial. And examples like `10 feet 12 feet 8 feet -> gallons` are much less compelling in metric (eg, 3 metres x 4 metres x 2 metres in cubic metres is, uh, 24 cubic metres...)
>Just curious, as the Frink examples were all imperial.
Fortunately Frink converts with zero loss of precision, because the language supports exact rational numbers. The unit definitions are all given in exact rationals, since they are (legally) defined as exact multipliers. For readability Frink introduces the "ee" ('exact exponent') notation, so for instance the standard acceleration due to gravity can be given as:
9.80665ee0 m/s^2
196133/20000 m s^-2
IMO dimensional analysis is still useful even if unit conversions are more compatible.
I agree with this sentiment, and in fact have always thought of it as analogous to type-checking (which must programmers benefit from to some extent).
If you use something with a sufficiently flexible type system you can combine these benefits, for example Haskell will let you mix physical units into the type system and have them statically checked: https://wiki.haskell.org/Physical_units
There's lots of metric units that aren't obvious when multiplied. For example, watts = ohms * amps^2 (very important if you want to calculate how much heat a mosfet is going to dissipate.)
Dunno about Frink but both qalc and pint allow any units and mixing and matching, in qalc you can do something like `1in^2 * 1m to gal` or `1 ly / fortnight to mph` and get as complex as you want. I use metric except when converting to vendor units for component speccing.
Oddly enough, this comparison (incorrectly) lists Frink as having no available web interface, when in reality Frink has both an online REPL version[0] and a Java Applet version.[1]
It also docks Frink with an 'X' because it doesn't have "Physical Dimensions," when in reality that's a core feature of Frink.
In Numbat you write:
dimension Length
length =!= m // meter set as default unit for dimension length
this is 100% proprietary and the source code for this isn't available: https://frinklang.org/faq.html#OpenSource
i'm open to non-FOSS licenses (and advocate for and use a class of them), but in this case 1. afaict, the license offers zero rights to the user 2. for me personally, i want more rights for a language than for an app, eg mongo
My new go-to language for any calculations is https://numbat.dev.
It’s a statically typed programming language for scientific computations with first class support for physical dimensions and units.
Great ergonomics and a pleasure to use!
A little bit of a tangent: I love the homepage. It includes everything I need to know about the language in a single page. Features, documentation with code examples and links between sections. And everything is one ctrl+f away.
Funny, I'm the exact opposite. It's driving me mad.
Why do I have to scroll down 95% of the way to see some simple examples, when that's the first thing I'm interested in?
Why does it start with a list of "features" of like 25 unorganized bullet points?
Surely the long quotation about European kings belongs in some "history" or "origin" section, rather than the first thing I need to read, when I'm just trying to figure out if this is a) open-source, b) for which operating systems, c) actively maintained, and d) for quick calculations or complicated modeling?
Why do I have to scroll down a couple of page lengths just to get to the table of contents?
This is basically one of the worst landing pages for a project I've ever seen. It completely violates the basic principles of putting the most important information at the top, of organizing content hierarchically (don't ever just put 25 bullets in a row), and trying to show rather than tell whenever possible.
Looking at the sample calculations, isn’t the first example missing the temperature of the water?
units.txt defines `water` like this:
water := gram / cm^3 // Standard density of water (defined)
(Or at least, that used to be true by definition. Using the current definition of the kilogram, and the latest measurements of water density, the maximum density is actually closer to 0.99997 g/cm^3.)
This subsection looks like the key to understanding Frink:
https://frinklang.org/#HowFrinkIsDifferent
(That, and we warmly welcome Frink to the club of computer programming languages! (as we once did for Perl, Java, PHP, Rust, Clojure, Go, Zig, Nim, Python, etc. etc.!))
Name collision - there is an unrelated "Frink" at https://catless.ncl.ac.uk/Programs/Frink/ which is a formatter and checker for the Tcl language.
I wonder if there's a similar CLI tool? Nothing against GUI-based tool, but easily usable on terminal is plus point.
Rink: https://github.com/tiffany352/rink-rs/ Is an Open Source CLI implementation
Frink is a CLI tool.
The website/GUI is just there for convenience and/or for people to get a taste.
I use Java with manifold-units[1] for this. Some examples:
>
// commonly used unit abbreviations e.g., m, ft, hr, mph, etc.
import static manifold.science.util.UnitConstants.*;
...
Length l = 5m; // 5 meters
Length height = 5 ft + 9.5 in;
Length distance = 80 mph * 2.3 hr;
Force force = 5kg * 9.807 m/s/s; // 49.035 Newtons
Force f = 49.035 kg m/s/s;
force == f // true
force == 49.035 N // true
1. https://github.com/manifold-systems/manifold/tree/master/man...*