The Frink Is Good, the Unit Is Evil | Hacker News Reader

The Frink Is Good, the Unit Is Evil

hillelwayne.com

132 pointsweinzierl41 comments

In case you were wondering (as I was), what kind of fart joke could make someone angry enough to write a programming language, HN has discussed it before: https://news.ycombinator.com/item?id=1543428

Direct link: http://futureboy.homeip.net/frinkdocs/#FartJokes

Answering the important questions. Thanks for the links!

Following on that, here is something:

" Thus, a good estimate to the problem stated above is that a real (gassy) human would need to save their farts for:

12.5 kilotons TNT / ((methaneenergy + h2energy) / day) -> years 1.9379377133697419931e+7

or about 19 million years to make the equivalent of the energy in a (small) atomic bomb! So the estimate given in that e-mail is off by a factor of at least 2.8 million! "

Now Mexico City has around 19 millions souls, given or take, right? (metropolitan area). That means, given the Mexican food is quite spicy and as such it's kinda farty too, every year Mexico City is releasing a Hiroshima bomb in potential energy every year through farts :).

> In the UK, beer is measured using pints but its alcohol by volume is measured in SI.

Small nitpick here: unless I am mistaken, ABV is dimensionless, it's simply a ratio volume of pure alcohol per unit volume.

The UK labeling laws require alcohol is listed in "Units" which are equivilent to 10ml of pure ethanol.

I think what the author is referring to is that other than beer (and cider) the SI units are used to measure booze in the UK.

You don't even tend to buy beer (or cider) by the pint outside of somewhere "licensed to sell alcohol for consumption on the premises" (ie a bar, pub, some restaurants). You order a pint (or a half, or a third, of very strong beers or to taste test several beers) to drink now, but when buying cans or bottles of beer for consumption later they're labelled in SI units like any other beverage e.g. a 330ml can or a 500ml bottle are perfectly normal things to see.

In a licensed premises the stronger classes of booze are measured in SI units too but with a convenience factor for ordering and, for weird historical reasons, each place of business gets to choose one of two definitions. For example a glass of wine could be 150ml or 175ml. Customers might say "A glass of the house red" but there must be a notice posted defining this as either 150ml or 175ml. Or vodka may be sold with a shot being defined as 25ml or as 35ml (again a posted sign tells you which) so you might say "A double vodka" and that's defined as either 50ml or 70ml.

Though they're not technically required, many British licensed premises use "optics" which are a device that fastens to a liquor bottle, the bottle is then inverted and the optic displays to the customer that there's a fixed measure of product (e.g. 35ml of whisky) ready to dispense, then a single motion dispenses that product into the glass without need for the staff to measure, when the glass is removed the optic refills ready for the next.

Yeah I worked in a 35ml bar and we were supposed to clarify with every single customer who asked for a double that it was going to be 70ml, really tiresome

Note of minor disagreement: there are large classes of quantities with units that the article claims are unitless. It’s a question of ability to describe the units. You need more components to your unit algebra to describe ratios and percentages, this lets you ascribe units to (and check units of) statistical operations and much more sophisticated expressions.

You definitely need a way to describe counts of identities too, which takes you into the land of ontologies as well. Happy to discuss with anyone who geeks out on this stuff as well.

I make distinction between dimensionless and unit-less.

Radians are a unit, but are dimensionless. You'll end up in a world of trouble if you got rad/s and rpm mixed up.

I actually (embarrassingly) got tripped up by that a bit.

So, you're saying that radians/degrees _are_ a unit because we can use them to describe a count of something, but they're still in fact dimensionless?

Is that because 2*pi or degrees never refer to an actual physical length? I think that's what trips me up because I generally have thought of degrees and radians as essentially units of length around a circle. But I suppose that since we're working with circles of arbitrary rather than specified diameter, they're still unitless.

I think I got to it on my own at the end there ha but I'm happy to be corrected!

Correct, the arbitrary length is the reason they're dimensionless.

A singular mathematical point can still rotate, but the arc length will always be zero.

One way to think about radians is "feet (of perimeter) per feet (of radius)" -- the dimensional units cancel and you're left with a dimensionless unit.

Taxes are a familiar dimensionless unit -- dollar owed to the government, per dollar spent on snacks. The dollars cancel and you're left with a raw percentage. (actually, to convert to a percentage you multiply by 100 percent per whole; another dimensionless conversion)

If they are truly dimensionless, when is it meaningful to multiply a non-currency value by them? There’s still a semantic that attaches the rate to dollars obtained in a transaction.

So we can discuss precisely: how do you define dimensionless? There are well-accepted definitions, I’m just asking you to lay it out so we can refer to it specifically.

Ratios in which the numerator and the denominator have the same unit are only dimensionless if you decide to apply the division and cancel the common unit. If you do this cancellation, and you forget/hide the semantic role of numerator and denominator, you will indeed get mistakes.

Part of the issue is being able to capture enough semantic role to be useful. That’s usually ignored in units discussions.

Since both are angle per time duration, which aspect causes the trouble?

I'd certainly be interested to hear how quantities where dimensions would normally divide out should be modelled and some concrete statistical examples how this really helps avoiding likely errors.

I spent some time a while back looking at it from an algebra point of view, and I would like to make connections to specific analyses. The challenge for me is finding mistakes.

One example area is percentages, which seem dimensionless. Grams per gram yield a percentage. Like grams of sodium per gram of cheese. Or grams of potassium per gram of cheese. I can sum these percentages to get grams of alkali per gram of cheese ONLY if these come from the same or “sufficiently similar” sample.

Looking only at the unit of the measurement, without also looking at the set of measurements, can quickly go awry. “Dimensionless” values can be used as multipliers/scalars only when the context makes sense.

Here’s a subtle one: let’s say I have an additive quantity that I’m measuring, like gallons of paint in various buckets. What are the units for the total paint across all buckets, and what’s the units for the mean quantity of paint per bucket? If these truly have the same units, I could sum averages and sums together. Heck, we could meaningfully sum averages alone. But we know that’s not the case.

How do you propose to encode the additional information that is needed to detect these mistakes though?

The unit expressions need more information. Some of it is simply extending with more operator: For example, logarithms and exponents can be carried through and track that the units resulting from log(e, height in cm) are log(e, height in cm) by allowing the log() function to be used in a unit expression. This allows validation that if we add log(x) to log(y) and we raise the base to the power later we expect units of x * y.

For sums vs means, we need to include count of samples in the mean. If we forget it and it becomes a free variable N, we lose the ability to combine by addition, but other operations may still hold. The unit expression for a sum of count quantities is therefore different from the unit expression for average. You can derive unit expressions for std. deviation and other expressions as well.

Ultimately you also need a subjective ontology as well. Your usual unit system says it’s fine to add mass to mass and mass per volume to mass per volume. That misses the semantics of mass of what per volume of what? Mass of sodium per liter of water and mass of potassium per liter of water, maybe. Mass of sodium per liter of water and mass of hydrogen per km3 of star, I don’t think so.

Unit tracking is all about validation of the sensibility of performing math, and the more detail you need the closer the unit expressions become to a signature for the math + objects being quantified.

Time permitting from my day job, I’ve been trying to flesh this out for a while and could use interested parties to poke at it, give me a spur to flesh out and refine more. Counts of objects, linear measurements and rational combinations work out pretty well in this, plus stats and transforms like log and exp. Angular units are a TBD, I think they’ll be tractable, just a little different than conventionally expected.

Frink the language looks fantastic for all sorts of casual and even some advanced use cases. How cool would it be if it would be possible to embed Frink in, say, any markdown document, and render and solve it from any host language? (specially JavaScript). I think the fact that the language is proprietary and closed source is holding it back.

Is the source of Frinklang available? I couldn't see it in a few minutes of searching.

No it isn't. See "Why isn't this open source?" here: https://frinklang.org/faq.html

Units are supported by a few python packages:

* https://pypi.org/project/units/

* https://pint.readthedocs.io/en/stable/

* https://docs.astropy.org/en/stable/units/

SymPy's units module is excellent, and the best I've found in Python.[0]

[0] https://docs.sympy.org/latest/modules/physics/units/index.ht...

The note on timestamps – that they can be subtracted but not added to any reasonable definition – is more generally an affine version of a unit. In this case, time is affine because it has a reference point to which it is relative.

Temperature is another obvious affine unit, due to a constant reference point. You could argue contextual measurements (eg voltage) may be affine in circumstance, but that’s covered better by experimental technique than a unit definition.

Was surprised the author didn’t bash Celsius degrees - because of their non-zero affine constant they don’t work in a system where units are supposed to multiply. (And so I would imagine they pose problems for Frink).

Ask any high school chemistry student struggling with PV=nRT. You stick Celsius degrees in there and you lose. And unlike other SI units, conversion requires an addition, not a multiplication.

Celsius isn't an ISO base unit. Just use Kelvin everywhere, you can get used to it pretty easily. It's almost 300K here right now, which is too hot for my liking.

Sure it’s not an ISO base unit, but then again neither are most of the things in Frink.

+1 to the idea that real scientists use Kelvin for everyday life.

I'm not a scientist, it was just easier once I got used to it. Also I don't like heat and in Kelvin my main argument in support of this (what should be entirely a personal matter of taste but it's fun to argue about matters of personal taste like which is the best movie) is more obvious than in a system like Celsius with an arbitrary zero.

The coldest it is possible for anything to be is 0K. That is indeed too cold, but only about 280K less than the inside of my refrigerator or a glass of Coke. You can wear gloves to (carefully) handle something at almost zero and colder is not possible.

On the other hand things get way hotter, there is an essentially unlimited amount too hot that things might be. Boiling water is too hot (not even 400K), a pizza oven is even hotter (700K plus for a good one) but lava is much hotter than that, yet lava is a naturally occurring substance, it's just right there in our environment whereas there's no chance of stumbling onto anything at 0K.

C++ has standard support for chronological measurements and there is an effort to extend this to other units for C++23. Compile time or runtime.

"Units can have different historical values. A foot is defined as exactly 0.3048 meters. Before 1959, though, it was 0.3048006 meters. This is means that all historical documents have a different measurement of foot. And there was a period of time where we used both definitions in different places!"

In the US, different definitions of a foot are still used in different states today. The plan is to standardize on 0.3048 meters at the end of 2022.

https://www.sco.wisc.edu/2019/10/18/us-survey-foot-to-be-dep...

C++ can do an excellent job of catching unit mismatches at compile time. We have developed classes that support this:

    cInches in1, in2, in3;  // basically 'floats'
    cCm cm1;   // floats
    void foo(cInches);

    in1 = in2 + in3;  // OK
    in1 = in2 + cm1;  // compile error
    in1 = in2 * in3;  // compile error: square inches are not inches
    in1 = in2 / in3;  // compile error
    float x = in2 / in3;  // OK
    foo(in1);  // OK
    foo(cm1);  // compile error

Classes like these have made the code much more readable, maintainable and reduce errors.

Has everyone forgotten /usr/bin/units ?

    $ units furlong/fortnight c
            * 5.5474886e-13
            / 1.8026175e+12

It's been there since the 1970s...

> What’s 20° + 1 radian? They’re both unitless quantities that have compatible dimensions.

How are they unitless if you add ° behind one and "radian" behind the other?

They're not unitless, they're dimensionless, see https://math.stackexchange.com/questions/803955/why-radian-i.... I think the author made a mistake.

https://en.wikipedia.org/wiki/Radian

> the SI unit for measuring angles

> defined in the SI as being a dimensionless value

Relevant wikipedia article: https://en.wikipedia.org/wiki/Dimensionless_quantity

Radians and degrees are both ratios where the units cancel out - ie. m/m. The point that is made is that adding degrees to radians without any conversions is technically fine from a dimensional analysis perspective, but it's often a bug in programming that we might want to prevent.

You can define 1 meter as ratio between the measured length and a known length. Both of these have the same units so they cancel out, just like with degrees/radians.

The only difference is that full circle is a little less arbitrary than Earth circumference.

This is cool. I have generally pulled out my TI-89 or HP-50 to do dimensional calculations.

Calca is way more natural for me. We could use an open implementation.

About the Frink programming language

Reply on news.ycombinator.com