I’ve always wondered why units(1) isn’t a library. I’d love to have access to abstract “united quantities” and “united measurements” in my HLL of choice, rather than needing to switch to a special-purpose tool (units, Frink) or a statistical-analysis language like R just to get them.
Sometimes I need to bust out stoichiometry-like unit-balancing in the middle of my code, and I want type enforcement that I’m getting the right units in the output! Sometimes I want to do a series of floating-point calculations, and I need to put error-bars on the result, and it’d be great if those were tracked for me in the form of a measurement ADT that tracked sig-figs. Etc.
My only guess for why there’s no libunits, is that it’d be a obtrusive black-box of operational non-guarantees if it was implemented in C, given that what Units does — if naively implemented — would be heavy on arbitrary memory allocations, and basically necessitate garbage collection.
It’d make much more sense for a libunits to exist as a C++-ish “template library” that takes an allocator as an argument; but that doesn’t really help anyone who wants to use any language other than C++ (as the template parameters can’t be exposed in the C wrapper code that other languages FFI to.)
(Before someone asks, you could get a limited kind of united-quantities — ones that can only represent “realistic” units — with a static per-qty bitfield representing the compiled-in units. But this wouldn’t really let you represent arbitrary unexpected “unit polynomial” qtys, e.g. m^5s^-3. This might seem fine, but sometimes intermediate quantities in formulae look like that, even though they work out to something sensible when everything is multiplied out.)
Even if there couldn’t be a single units library implementation, it’d at least make sense for there to be 1. a canonical libunits-data release (sort of like tzdata), that individual library impls could pull in; and 2. a high-level API spec or reference-impl of what a libunits library for a given language-runtime would look like (sort of like how every HLL has copied JodaTime’s datetime design.)
And yes, it has always struck me as strange that date/time/calendar utilities are standard as canonical functionality shipped with language distributions, but units are not.
The source isn't that big, I just downloaded 2.21 source and it is one directory with about ~45 files, and the majority of bytes are for /doc/dvi binaries, only 5 c files and a post Yacc'd tab file for parsing the units definitions file. Surprisingly simple now that I look at it.
Heck... I was going ask you to write it, but now I'm thinking this could be a fun weekend project.
There are heaps of libraries for all languages because it is a fairly fun and straight forward project. I personally created this one because I was frustrated with how slow and clunky the existing javascript libraries were:
Commenting on my own thread because the window to edit has passed. What is up with the haters today? I share a useful open-source library with everyone that I spent a ton of time working on only to get crapped on by the know-it-all crew? Did you even click the link and read the github readme? This library is tested against NIST data! It also has 100% test coverage and support for corner cases like non-linear unit conversions like temperature. How does anyone enjoy participating in this community?
HN has a huge number of users, most of whom don't comment on any given topic. So I think it's best to not care too much what the handful of individuals who interact with you happen to think.
I went to search through dang's comment history to see whether he's posted any statistics to make that "huge number of users" more precise, but instead I found this comment which explains it better than any statistics: https://news.ycombinator.com/item?id=18523361
What makes you say that? I suppose you could add as much complexity as you want with differentiating units from different standards and adding uncertainty in the unit definitions and on and on. But for 99% percent of users, just conversion factors and basic arithmetic operations are all that is needed. What application do you have in mind where this would fall short? In 15 years as an engineer I have not run into one.
Be conservative in what you send, be liberal in what you accept.
leap years, leap seconds, julian dates, pre-gregorian dates, years beyond 9999, yyyy-mm-dd vs d/m/y vs month day year vs ..., zero padding, 12 hour vs 24 hour, 32 bit time stamps, DOS time accurate to every two seconds, why does excel need the date time in a specific format, I dual boot between Windows10 and Linux and every-time I boot up Windows10 the first thing I need to do is adjust the date time, pico-second granularity, time zones, daylight savings time, ...
Today is Stability (4), Flint (Tijaax * Etznab)
It's a good day to: Spend time in reflection and introspection.
Keeping track of units was one of the first ever uses of C++ templates (one of the Bjarne books IIRC mentions it existing prior to the STL), but was apparently reinvented multiple times later.
Sometimes I need to bust out stoichiometry-like unit-balancing in the middle of my code, and I want type enforcement that I’m getting the right units in the output! Sometimes I want to do a series of floating-point calculations, and I need to put error-bars on the result, and it’d be great if those were tracked for me in the form of a measurement ADT that tracked sig-figs. Etc.
My only guess for why there’s no libunits, is that it’d be a obtrusive black-box of operational non-guarantees if it was implemented in C, given that what Units does — if naively implemented — would be heavy on arbitrary memory allocations, and basically necessitate garbage collection.
It’d make much more sense for a libunits to exist as a C++-ish “template library” that takes an allocator as an argument; but that doesn’t really help anyone who wants to use any language other than C++ (as the template parameters can’t be exposed in the C wrapper code that other languages FFI to.)
(Before someone asks, you could get a limited kind of united-quantities — ones that can only represent “realistic” units — with a static per-qty bitfield representing the compiled-in units. But this wouldn’t really let you represent arbitrary unexpected “unit polynomial” qtys, e.g. m^5s^-3. This might seem fine, but sometimes intermediate quantities in formulae look like that, even though they work out to something sensible when everything is multiplied out.)
Even if there couldn’t be a single units library implementation, it’d at least make sense for there to be 1. a canonical libunits-data release (sort of like tzdata), that individual library impls could pull in; and 2. a high-level API spec or reference-impl of what a libunits library for a given language-runtime would look like (sort of like how every HLL has copied JodaTime’s datetime design.)