Re: [boost] Quantity library: any interest?

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-05-02 08:46:16

>From: "Paul A. Bristow" <boost_at_[hidden]>

> > From: Terje Slettebø
>
> | As mentioned, the work on this predates the current Boost thread, as I
> | experimented with a version about a year ago. When the issue has come up
a
> | few times, later, I've gone a little back to it. In summary, I've
restarted
> | several times.

There's actually only been one complete restart, the one leading to the
current version. The reason for restarting is that sometimes you may find a
completely new way of doing things, for example with experience with an
earlier version, that it may be easier to start from scratch, than trying to
refactor the earlier one.

> | This would of course be a possibility, if that's what you suggest,
e.g.:|
> | length<double> value="1.23 km";|
> | It would then have to decode this, before use.
> | I'm already using Spirit for processing formatting strings for output,
so it
> | could be possible to use it for input, as well.
> |
> A string would seem OK.  (Of course, decoding may get trickier: "1.234
km/s/s" to
> "9.876 BThU/fortnight".  And users will not doubt get M surprises when
they get their 'm's and their M's confused ;-)

<g> :)

Yeah, parsing such an expression could be a nontrivial task, especially as
it currently doesn't store the defined units in a central place, which may
be looked up. Of, course, this could be done.

I think it should be ok to do:

1.234 * km / s / s

or:

typedef dim<double, unit<0,1,-2,0,0,0,0>, si::prefix::k> some_quantity;

some_quantity value=1.234; // Or value(1.234)

Note that the following is not allowed:

value=1.234; // Error, can't assign a scalar value to a dimensional quantity

Only the constructor takes a scalar value.

Anyway, how to specify units, etc. may be tweaked, once one get some
experience with it.

>  Output: "1.23 kV (electric potential difference)"
> |
> | Nifty? ;)
>
> Nifty Indeed!
>
> But I have another suggestion which I find works very nicely, and that is
to be able to dynamically chose the SI multiplier prefix so that the value
is always between 1.0000 and 999.9999.  So output of 978.6 m is 978.6 m but
1234 m is 1.234 km and 0.567 m is 567 mm.

Another good idea!

I'll work on implementing this, possibly with a format specifier which may
give such a "dynamic" prefix, or the "static" (declared) prefix.

>And I have also combined this a stored uncertainty (perhaps a future system
could use the Boost interval library for this) to only output significant
decimal digits.  This avoids the plague of misleading digits from almost all
programs.

Yet another good idea. :) I saw you suggested this earlier in this thread,
too. I'll look into it.

Yes, especially for calculations involving measured quantities, it's useful
to know what accuracy the returned value has, based on the accuracy of the
input, and the computations done.

Also, I plan to define some mathematical/physical/etc. constants, but this
may well be delegated to a dedicated constants library, such as what has
been discussed at the list.

> | I'm also careful not to use partial specialisation, so it should work
even
> | on MSVC 6/7. :)
>
> But is this becoming less important with the release of C++.net 2003 aka
7.11?which is rumoured to do nearly all the things it should. So if partial
specialisation is the best/convenient solution, I would use it.

I know. However, the template use is "conservative", as MSVC  is not the
only one with problems, there are some other quite flaky compilers out
there - Borland C++ comes to mind. However, if there's a feature that
requires unreasonable workarounds, I'll let it be. So far I haven't needed
any workarounds. I'm also using components which have their own workarounds,
such as bind, ref, and MPL.

There hasn't been done any compromises in the design with reference to
nonconformant compilers. There simply haven't been a need for more advanced
template code in this case (or so I thought - see below). This is different
from the composite stream operators, where things like template friends and
delicate balance between overloaded function templates enabled a more
elegant design, than without it.

However, I haven't yet compiled this library on MSVC... :) I've been using
Intel C++. I tried to compile it on MSVC 6, now, and it stopped already in
boost/iterator.hpp - in the middle of some MSVC workaround code. :)

So I guess any compatibility with MSVC 6 is kind of moot. Perhaps MSVC 7.
Hm, I tested there, now, and it doesn't work there, either. Also, testing it
on MSVC 7.1 Final Beta gives an ICE..

I guess I'll wait for the release version, and try it again, there.

Hm, g++ 3.2 doesn't handle it, either...

Never mind what I said about "conservative code". Apparently, it's not. :)

Then again, it may be problems that may be relatively easy to work around,
on more conforming compilers. It reminds me of the saying that a program
isn't portable until it has been ported. Actually, I guess the saying was
regarding "reusable" and "reused", but it may apply to porting, as well.

Apparently, I've got a portability job to do, once the functionality is in
place. :)

Another thing I plan to do, is to add support for "models", like some other
SI unit libraries, such as "standard", "relativistic" (speed of light, c =
1), etc.

Regards,

Terje