Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Units

gnu.org

Post reply on HN
Print view View original

21–30 of 117 posts

Re: GNU Units

#21

Post by tadfisher »

mrbonner wrote: post #13
ygra wrote: post #12

Earlier quoted context omitted.

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?

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.

Re: GNU Units

#22

Post by theamk »

Qem wrote: post #2

This tool is underrated. Failing to deal with units conversion already crashed a Mars probe: https://www.latimes.com/archives/la-xpm-1999-oct-01-mn-17288... I wonder if the recent problem with the voyager was due to something like this, for example, 2 arcminutes or 2*pi radians being mistaken for 2 degrees.

The idea of using units is underrated, yes. More programming languages should be offer support for units, and more program should be using them.

That particular tool, "GNU Units"? Nope. It is pretty good command-line calculator (especially if you give inputs on command line so that history is preserved), but it is not really scriptable, and you'd _definitely_ want to avoid all manual calculations in any sort of important process.

Re: GNU Units

#23

Post by seabass-labrax »

simplicio wrote: post #11
mrbonner wrote: post #5

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 convers…

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).

Re: GNU Units

#24

Post by qbrass »

mrbonner wrote: post #13
ygra wrote: post #12

Earlier quoted context omitted.

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?

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

Re: GNU Units

#25

Post by mrbonner »

alfalfasprout wrote: post #16
mrbonner wrote: post #13

Earlier quoted context omitted.

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

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…

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.

Re: GNU Units

#26

Post by fest »

Qem wrote: post #9
krger wrote: post #4

Earlier quoted context omitted.

>This tool is underrated. Failing to deal with units conversion already crashed a Mars probe The mistake there was that they were unaware that they had to make the unit conversion, not that they did it wrong. No tool can, by itself, overcome your ignorance of its necessity.

> The mistake there was that they were unaware that they had to make the unit conversion, not that they did it wrong. I think the root cause here was continued use of medieval units, instead of just standardizing on the metric system as it's already done around nearly the entire world.

Even if it was all metric, in embedded systems you often have to deal with the same measurements in different units, like angles in radians, degrees, centidegrees, length in mm, m, cm, due to various reasons (mostly historical, like integer math being faster than floating point math).

It is getting less frequent in modern code bases that target 32-bit MCUs with hardware-floating point support, but converting large codebases

Re: GNU Units

#27

Post by [deleted] »

Qem wrote: post #9
krger wrote: post #4

Earlier quoted context omitted.

>This tool is underrated. Failing to deal with units conversion already crashed a Mars probe The mistake there was that they were unaware that they had to make the unit conversion, not that they did it wrong. No tool can, by itself, overcome your ignorance of its necessity.

> The mistake there was that they were unaware that they had to make the unit conversion, not that they did it wrong. I think the root cause here was continued use of medieval units, instead of just standardizing on the metric system as it's already done around nearly the entire world.

[deleted]

Re: GNU Units

#28

Post by kragen »

mrbonner wrote: post #5

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 convers…

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

Re: GNU Units

#29

Post by kragen »

alfalfasprout wrote: post #16
mrbonner wrote: post #13

Earlier quoted context omitted.

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

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…

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.

Re: GNU Units

#30

Post by Rayhem »

I had a lot of fun working with the maintainers of this utility to better support Gaussian units[1]. This is usually done (incorrectly) by multiplying, say, some number of SI coulombs by a dimensionless constant (actually 2_997_924_580) to produce some number of statcoulombs that represents the same charge. It's very subtle, though, that statcoulombs and coulombs have different dimensions (which is the point of Gaussian units) despite representing the same physical quantity[2], so the conversion is much more involved. I learned a lot about the nature of units and software development working with them.

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

[2]: A consequence of this is that electromagnetic equations formulated in terms of Gaussian units have goofy things like sqrt(grams) as "base" units. That was the tricky part to handle.

Post reply on HN