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
> | 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
> | it on at the moment).
> Suggest you post in the files area. This will expose it to view at
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:
m = length;
cm = 0.01 * m;
mm = 0.1 * cm;
km = 1000 * m;
in = 2.54 * cm;
ft = 12 * in;
yd = 3 * ft;
mile = 1760 * yd;
nm = 6076 * ft; // Fundamentals
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,
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
> and propagating, uncertainty in all sorts of measurements, and uses
> simple and well known 'very restrictive assumptions' statistical rules
> 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.
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk