Boost logo

Boost :

From: Phil Richards (news_at_[hidden])
Date: 2005-10-21 05:50:05


On 2005-10-20, Deane Yang <deane_yang_at_[hidden]> wrote:
> Phil Richards wrote:
[some stuff]
> I have no idea what all this means. Why would I change my "basis set" (I
> assume this means a base collection of dimensions) if I want to use SI
> dimensions?

You wouldn't. I wasn't saying that you would. I was saying that if
you define a different set of dimensions as the ones you want to use
in you equations, then it isn't going to interoperate with SI.

> Why should it matter to you that someone else outside of physics might
> use the library with a completely set of dimensions that are completely
> disjoint from the dimensions you use?

It doesn't. The problem only comes in if you try and make the two
sets of dimensions interact - because the result may not be well-formed.
You can't combine SI-based quantities with quanties in which time
and length have the same units because you have no guarantee that the
resulting dimension makes sense. This is why I went down the path
of insisting that you predefine what make up a well-formed set of
dimensio

You snipped out where I said:
> > Which, funnily enough, is where I got to with my "dimensionality
> > family" stuff. I was never enormously convinced of my solution, it
> > has to be said, but it works if all you want to do is define disjoint,
> > non-interacting, dimensional analysis systems.

The key part is the "it works if all you want to do is define disjoint,
non-interacting, dimensional analysis systems." Which, from what you
are saying, is exactly how you would expect/want it to work.

You see, the problem I have is that I can't understand now (or back
a year or so ago) what else needed to be added to the stuff I've done.
Since I can't understand what is missing, I can't add it.

> Are you objecting to using an mpl map, because you think it'll
> substantially increase the compilation time?

No. Implementation isn't the issue. I converted to using MPL
(admittedly, mpl::vector, but that's not really important - it
just so happens that if you define your basis set of dimensions
up front, you don't need to mess about with maps and the sorting
and uniqifying that goes on as a result). I'm not happy with
the performance when doing unit conversion and printing, but they
are moderately rare in what I do...

> In mathematical finance, the only essential dimensions are time and
> dimensions derived from time. Why do I want a library that lugs around
> all the other physical dimensions, too?

With what I did, you wouldn't have to. You would define your
dimensional system to be
    struct Finance : finance_system<u::second> {};
(or some such). The only downside is that it would interoperate with
SI::time, but that's not necessarily a problem from what you've said.
If you want to track second, hour, day, year as separate dimensions,
then just do:
    struct Finance : finance_4system<u::second, u::hour, u::day, u::year> {};

I'm guessing that I'm still missing something :-)

phil

-- 
change name before "@" to "phil" for email

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk