Re: [boost] Yet Another Units Library

From: Geoff Leyland (gley001_at_[hidden])
Date: 2003-11-05 18:04:55

On Thursday, Nov 6, 2003, at 07:09 Pacific/Auckland, Paul A. Bristow 
wrote:

> | If anyone wants to have a look at the code I'd be more than happy do
> | dig it out and send it to them (I don't have a server I can easily 
> put
> | it on at the moment).
>
> Suggest you post in the files area.  This will expose it to view at 
> least.

Ha ha!  I dug it out and even with Codewarrior I got 876 errors.  
Mostly related to bits of ANTLR that seem to be missing.  Anyway it 
looks like a mess, and I'm not going to spend time getting ANTLR going 
again (and find that patch I wrote to make the lexer twice as fast that 
I never managed to get the maintainer to accept).  So...

> We were really looking for someone to do the work ;-)

..what should I do?
I could still post it to the files area, but a better answer is that if 
there's an interest I'd be happy to having a go at learning Spirit* 
(which I've wanted to do for a while now) and updating the units 
library to a state where people can decide whether it's worth going any 
further.  It might take me a while though.

*Here's a Spirit question.  In spirit, can I easily define a "small" 
parser than someone can then embed without much fuss in a larger 
parser?  Specifically, if I write a unit expression parser, can I then 
use it as a small part of a parser for a language that involves units 
without a lot of mucking around?  This wasn't really possible in ANTLR.

This is a RUN TIME (not compile time) dimensions and units library that 
was supposed to integrate with a compile-time units library that I 
never really finished.  So it can output dimensioned values in units 
that the user requires (there were ways of setting flags on the stream 
- like setwidth() or setprecision() you could do a sort of setsi() or 
setimperial() though it wasn't quite like that - but it could be!).   
However I suspect output is covered by the compile time libraries that 
have been proposed.
It could also read a value with units, the advantage over compile 
time-stuff being that the user can type in a temperature or a enthalpy 
or a pressure or whatever, and you can react to what you get.  (which 
is what you want when you're asking the user about fluid properties.

The other advantage was that all the unit definitions are in a text 
file that the user could easily edit to add units.  The text file 
looked a bit like this:

// Length
new length;
// SI
m	= length;
cm	= 0.01 * m;
mm	= 0.1 * cm;
km	= 1000 * m;
// imperial
in	= 2.54 * cm;
ft	= 12 * in;
yd	= 3 * ft;
mile	= 1760 * yd;
nm	= 6076 * ft;			// Fundamentals

// Mass
new mass;
// SI
kg	= mass;
g	= 0.001 * kg;
....

I can't find a decent example of use, but it did all the dimension math 
as you'd expect, as well as parsing strings.  Something like,

unit					m("m");
quantity				speed = 3.0 * m / fetch_unit("s");

Sorry I can't be more specific at this stage.  Like I said, if there's 
any interest, and there's no-one else who's done it already, or better, 
I'll have a go.

It's coolest feature was its name : "Unity"

> Agreed but the ISO GUM Guide to expression of uncertainty in 
> measurement (1995)
> (and many other sources) is a useful guide to current thinking on 
> expressing,
> and propagating, uncertainty in all sorts of measurements, and uses 
> fairly
> simple and well known 'very restrictive assumptions' statistical rules 
> for
> propagation.  It is accepted that these are only an approximation but 
> seem to be
> acceptable and useful, and standardised.
>
> code by Evan Manning (manning_at_[hidden])
> Evan Marshal Manning C/C++ Users Journal, March 1996 page 29 to 38.
>  ftp://beowulf.jpl.nasa.gov/pub/manning
>
> is an example of using these 'simple' 'rules'.

That's very interesting!  However I couldn't get to the ftp server, so 
I don't know all the details yet.  Could one imagine a system where you 
had uncertain values and under one "policy" you used these rules, and 
then by changing your policy and recompiling (and waiting an awful long 
time for it to run) you'd do some kind of simulation?  That'd be very 
interesting.

In the same vein, I once wrote a Sobol sequence generator using start 
data from Waikato university for over 1000 dimensions.  I sent it to 
Jens Maurer about a year ago, but I think he has a lot on his plate.

> One would not want to require use of uncertainty handling of course, 
> but I
> believe that any dimensions and units package must also 'party' with an
> uncertainty package.

I think that both would be very interesting to work on.

cheers,
Geoff