Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-01-30 12:41:51


Andy Little wrote:
> I would hope that a general purpose physical quantities lib would
> deal with units, even if you dont use anything but the base units.
> The Mars lander crash and all that. IOW you need to be explicit about
> what units you are using.

In my view, a dimension library has to exist independently of any units
library. It is a separate and smaller concept. I should stand on its own.
This will make it

a) much easier and faster to come to consensus
b) much easier develop and test.
c) immediatly usefull. Lots of applications would find it useful even in
the absense of a units library.
d) not permit applications that use only this functionality to not be
dependent on anything else.
e) someday a units library will be built that uses this. Some people won't
like it for on reason or another. If dimensions are a separate library -
this won't be a problem as they can use their own version of units.

>> Still, as I said, agreement couldn't be achieved last time round on
>> pretty much anything,

So lets try to agree on less - a dimensions library.

> This seems to be a pessimistic view of what went on IMO. Is it not up
> to the librray designed to come up with a solution based on the
> discussions. I incorporated some things from these discussions into
> pqs. However I have always had a very specific view of what I want
> from a physical_quantities library, which has naturally had a major
> influence on the design.

Ahhhh - here is the rub. Is the library designers job to satisfy his
"customers" or produce the most elegant, complete and useful package as he
sees it. This is a very hard question. The main reason that boost
libraries are of superior quality is that they come closest to reconciling
these conflicting propositions. Libraries are develope by one or two
people. This maintains a logical cohesiveness and elegance which is
essential to a good library. On the other hand, they have to satisfy a
large number of different "users". Fortunately, most users are focused on
features though sometime implementation issues are important. So the
appropriate attitude to be successful in this endeavor is

a) Make a list of all the features it going to need to get accepted.
b) Start making your library
c) Realize that the job is too big to get done before its obsolete
d) Divide your library in to smaller pieces that are useful in their own
right
e) Pick a piece
f) go back to b

This whole thing of trying to satify everyone and still keep the thing from
becomming a microsoft-like API is a huge challange - actually much harder
than writing and proving the code and manual (though that is way harder than
it looks !!!!)

> Though if there was to be a boost version, unfortunately this would
> need to be thrashed out. And that is the problem. It is a big
> project. I would ideally like to 'boostify' pqs but dont have time
> currently.

Basically, I believe that in software design, as in most other design
edeavors, less is more.

> However Robert Rameys idea to do the dimensional anlysis library
> alone seems good, as it is less contentious and surely would not be
> too much work.

"would not be too much work" - LOL so it would seem. add in the
documentation, tests, bjam hassle, varying compilers (add in a lot for
this). even this is going to be a lot of work

If this could be done

a) we would have something useful
b) people would have something to use for experiments on units. Issues of
money, etc could be experimented with independently. This would be very
helpful in a future discussion of units as we would have more real data and
wouldn't have to rely so much on speculation.
c) it has a better chance of getting accepted.
d) This would add a lot to the writers resume - thereby making it easier
justify the time invested - which is still going to be alot.

Perhaps this could be used to flog the development of a rationals library.
Another thing we sorely need.

Robert Ramey


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