4 ms·

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 a

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?

simplicio 3y ago
Think a spoke/hub type thing would be a lot easier. Just convert inputs to SI, then from SI to the output.
- seabass-labrax 3y ago
  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).
ygra 3y ago
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.
- mrbonner 3y ago
  Then how do you deal with non-SI units, like money?
  - simplicio 3y ago
    Just pick a unit as the "standard" for that type of quantity.
  - alfalfasprout 3y ago
    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.
    - mrbonner 3y ago
      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.
    - kragen 3y ago
      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.
  - seabass-labrax 3y ago
    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.
- alfalfasprout 3y ago
  Yep. Especially if using a bignum library to keep sufficient precision during the intermediate conversion.
cb321 3y ago
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 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 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 https://en.wikipedia.org/wiki/International_System_of_Units
kragen 3y ago
no dude you're seriously overcomplicating the problem it's just a finite-dimensional vector space over ℚ https://en.wikipedia.org/wiki/Dimensional_analysis#Mathematical_properties 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
mrbonner 3y ago
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.

simplicio 3y ago

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

seabass-labrax 3y ago
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).

ygra 3y ago

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.

mrbonner 3y ago
Then how do you deal with non-SI units, like money?
- simplicio 3y ago
  Just pick a unit as the "standard" for that type of quantity.
- alfalfasprout 3y ago
  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.
  - mrbonner 3y ago
    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.
  - kragen 3y ago
    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.
- seabass-labrax 3y ago
  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.
alfalfasprout 3y ago
Yep. Especially if using a bignum library to keep sufficient precision during the intermediate conversion.

cb321 3y ago

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 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 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 https://en.wikipedia.org/wiki/International_System_of_Units

kragen 3y ago

no dude you're seriously overcomplicating the problem it's just a finite-dimensional vector space over ℚ https://en.wikipedia.org/wiki/Dimensional_analysis#Mathematical_properties 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

mrbonner 3y ago

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.