Hacker News Reader

Comment by mrbonner | Hacker News Reader

I haven’t looked at the code for this but somehow I think the conversion problem is very similar to a graph search. If you build a graph in which the vertices are the units and the edges are compatible convert scales, you can use this graph with say, BFS to find the right traversal path. Multiplying the scales would get you the result converting from a unit to another. Or, dividing would give you the reversed conversion. I used to think we could use a hash table for this kind of stuff. It is faster of course but you need to account for all sort of conversion, even the crazy ones like Lightyear to feet’s, for instant. With the graph, I think I could just throw everything in it. No matter how crazy the conversion is, if there is a path, you will get it!

How does GNU unit get the conversion tables to bootstrap, does anybody know?

View on HN

no dude you're seriously overcomplicating the problem

it's just a finite-dimensional vector space over ℚ

https://en.wikipedia.org/wiki/Dimensional_analysis#Mathemati...

the conversion tables are in /usr/share/units/definitions.units (or previously /usr/share/misc/units.dat)

they are the result of many years of careful scholarship by adrian mariano

It's more like a 2-level situation for most things with a little more structure than you might realize. There are "physical kinds" or meta types like "energy" and then different concrete units those can be which allow conversion.

The physical kind is a point in an N-dimensional rational space of exponents of base units, such as Mass * Distance ^2 * Time^-2 or (1,2,-2) for energy (maybe with some carry over ^0s for unused slots of a >3D meta-type space). Additive (like add, subtract, compare, and convert) are only meaningful at the same point in that lattice. If you are interested in learning more, this is all a part of dimensional analysis: https://en.wikipedia.org/wiki/Dimensional_analysis .

Even the dimensionality of that rational exponent space (the "unit system", if you will) is more of convenience / convention than fundamental. https://en.wikipedia.org/wiki/Planck_units clobber most things away leaving only 1 dimension (and a tendency for complex rational exponents). Meanwhile, the SI unit system is very "dimension promiscuous" (mass, length, time, electric current, temperature, amount of substance, luminous intensity) [1] to avoid non-integer exponents (but you cannot really forever since as soon as some formula has some square some solution of it has some root that probably gets you a 1/2 exponent).

There are some situations with not purely "conversion factor" scale offsets like thermal units (e.g. Celsius to Fahrenheit) that people often describe in math-ese as "affine conversions". Something like GNU Units attends these things, but they are kind of "conversion only" orphan step-children more than "real" types which "compose better". In physics formulae one will often only care about delta-Temperature, not levels, for example.

EDIT: The implicit creation of a potentially brand new type any time you multiply | divide two extant things is, incidentally, why you need either a dynamic or a very powerful static type system to express these things.

[1] https://en.wikipedia.org/wiki/International_System_of_Units

Wouldn't the most sensible option just be too have the SI units at the center and everything else heaving a conversion edge to that? While intriguing, there is probably no need to make that graph any denser.

Then how do you deal with non-SI units, like money?

Just pick a unit as the "standard" for that type of quantity.

Notice how money isn't handled (at least per the examples) by GNU Units. Because currency (and fungible financial instruments in general) have variable exchange rates.

For currency conversion, it's a lot more tricky because there's many ways to convert. Eg; if I want to go from CHF to USD there's a lot of CHF->USD volume and there are market rates for that exact conversion. But between eg; SGD (singapore dollar) and Peruvian Soles (PEN) the market is a lot smaller so it may be actually beneficial to do SGD -> USD -> PEN.

Typically this means ingesting a feed of real time prices + any fees and then doing a limited-hop graph traversal.

It is interesting because I see a file `currency.units` in the source distribution. It has the list of all countries' currencies normalized to USD. If Units doesn't deal with currency, why does it maintain this conversion file? And, I agree that the exchange rate varies day to day. But, this may provide an estimate conversion.

money is handled by gnu units

the base unit is the us dollar

this is arguably incorrect but inarguably useful

from the man page:

> The units program database includes currency exchange rates and prices for some precious metals. Of course, these values change over time, sometimes very rapidly, and ‘units’ cannot provide real-time values. To update the exchange rates, run ‘units_cur’, which rewrites the file containing the currency rates, typically ‘/var/lib/units/currency.units’ or ‘/usr/local/com/units/currency.units’ on a Unix-like system or ‘C:\Program Files (x86)\GNU\units\definitions.units’ on a Windows system.

You can't really convert units of money to any other units, so I'm not convinced of the utility of money conversion in this kind of tool.

US Dollars would be connected to US Cents in the graph, and Pounds Sterling and New Pence would be connected to each other too, but those two subgraphs would be entirely disconnected from each other and from any SI unit like distance or mass.

It's useful for some practical conversions like fuel efficiency calculations. I think in USD per mile and it's handy to be able to directly take CAD/liter and l/km for my trips to Canada.

Money (currency, really) is a whole forest of units with bespoke scales, arithmetic, and market-driven conversion logic. If you are converting money to other units with a library, you are almost certainly doing it wrong, or are operating at a level of abstraction much higher than my puny brain can fathom.

Convert to USD then back. Which is what Units does.

Yep. Especially if using a bignum library to keep sufficient precision during the intermediate conversion.

Think a spoke/hub type thing would be a lot easier. Just convert inputs to SI, then from SI to the output.

Parent was suggesting a hash table lookup though, in which case the topology of the graph would be irrelevant. The number of entries in the table would be constant regardless of whether the original graph was connected with the fewest number of edges or with the greatest number of edges (a complete graph, which is what the table would be encoding).

I get it that some suggest the graph is a complicated/over-engineer while other suggest just stick to SI. Well, my rationale is that not everything has a SI conversion, and simple SI/hub/spoke would need you to maintain a unit -> SI (or base unit like USD in currency conversion).

What I like about the graph solution is that you don’t have to use SI or base unit at all! If your graph has km -> m, now you add (updating your graph) for m -> feet, you could traverse from km -> feet. Later on, you can add nautical mile -> feet, using this graph you could basically get km -> nautical mile if you need to.

Reply on news.ycombinator.com