From: Andy Little (andy_at_[hidden])
Date: 2004-01-03 09:21:56
"David Abrahams" <dave_at_[hidden]> wrote in message
> "Dan W." <danw_at_[hidden]> writes:
> >> Amen. And I think this applies to 90% of the potential users of
> >> a quantities library. What is widely needed is an abstract quantities
> >> library, with NO pre-defined units or dimensions. This, in my view,
> >> is a much more important library than the physical dimensions library,
> >> which serves a much narrower need.
> > I still think that a physical quantities library is *very*
> > important. Maybe what I would like best would be Andy Little's library
> > just for physical quantities, and Matthias Shabel's solution, without
> > predefined physical dimensions and units, for the more common needs,
> > and for the two to be inter-operable. I'll tell you why: for
> > physical quantities I like Andy Little's rigor; --I don't even want to
> > be able to mess with it to add a "thoughts-per-eye-blink"
> > dimension. Physical quantities should be physical quantities.
> I don't think that's a good excuse for code duplication. There are
> ways to hide configurability so that it looks like you "can't mess
> with it."
OTOH dont add configurability,complexity or generality until you find that
you actually need it...
Start with the specific problem. Get a minimal solution to that. Get it to
work. Then use it for a while
Find its problems... work on those..
Some time later .. is it still in use? ... is it stable? is it any good?
If so... there Will be momentum to apply it more generally. (Most libs,
probably including mine, wont get this far.)
I would conjecture that this is how STL came about... the problems of (say)
containers had been there for many years... with a lot of previous solutions
in particular areas.. to draw from to see what worked in practise.... better
The STL took what it considered to be best(then) and most universal practise
for its needs from all the previous types of (say) container.
another example is C++ itself. Systems evolve in unpredictable ways.
I have started with a relatively loose specification: physical-quantities.
And the detail is still being worked on to tighten the specification up.
Even in this limited arena(physics) there are a lot of grey areas for which
solutions need to be found...
do-something-configurably" is much too loose a specification.
I cant take any of this too seriously without a tighter definition of what
you guys are actually talkng about.
It may be important and useful... some mathematical system/rules for
combining (arbitrary?) entities... perhaps?
Anyone care to provide a tight detailed definition ...?
Also some real world examples(code) of where the system does/would be
useful/apply would help.
BTW( As far as my own work goes I too would be interested in examples of
currently used physical_quantity use/systems.. if info on these are publicly
Ideally I hope to provide physical_quantities context in the docs. I do not
think for one minute that I have The Solution... but I do think I have made
I'm sticking just with physical_quantities currently.
But if a tight generic
do-something-configurably" definition is forthcoming I shall follow with
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk