From: Andy Little (andy_at_[hidden])
Date: 2004-01-11 05:41:04
"Dan W." <danw_at_[hidden]> wrote in message
> David Abrahams wrote:
> > On the other hand, premature generalization often spells design bloat
> > and death ;-)
> I know, been there;
I have been thinking on this point. The major deficiency in my lib is that
it will only deal with integer powers.(Thanks Dan for bringing to light
some examples that require Rational fractions.)
When a serious flaw is found in something I have designed (Usually just
before the deadline), I am the first person to suggest a big pause
to totally redo the analysis and if necessary throw the design away
and start again. (A philosophy which is not always err..hm.. popular ;-) )
Do I think that is necessary here ?... No.
One thing that has come to light during the thread is that the concepts
behind a physical-quantity are not well understood here at boost.
What I currently have could be described in a derogatory way as only
being capable of 'schoolboy physics'. OTOH it could also be
described as modelling a physical-quantity in a limited sense.
(One criteria for acceptance at boost is I believe education.)
My type can be used to understand the basic concepts without
'muddying the waters further' with complexities:
) It stays in the realm of physics.
) It is based around the SI system.. which is The system
recommended by goverments around the world.
Furthermore , having actually used the physical-quantities type for some
time now, I am starting to discover some intriguing problems that it throws
up. These all arise because a physical quantity is Not a numeric.
with a numeric_type N_t one may find operator * declared like this:
N_t operator * (N_t, N_t);
However when using a physical_quantity type arg PQin_t the returned type
PQout_t is Not(usually) the same as PQin_t:
PQout_t operator* (PQin_t, PQin_t); // simple case :-)
Now try to make That work with std::complex. :-)
(note: Non integer powers-of-dimension will not help here )
Similar problems Will arise in a large number of situations.
Which means that to do anything non-trivial with the type,
unless you wish to rewrite entire numeric libraries you will
need to convert it back to a good old numeric at the input
to the calc, do the dimensional/unit analysis manually and
then convert back at the output. (For my self I am quite
intrigued by the alternative... rewriting libs to see what happens :-) )
IOW How seriously the thing should be taken I don't know.
But.. its a lot of fun :-)
[ A lot of other useful stuff ... which I will leave for others to
comment on.. thanks Dan]
BTW I hope to continue work on the type... with a view
to putting on boost soon so I am going to step back a bit
from the discussion.
Please though in the spirit of physics do try the thing (if it wont
compile...good feedback) Before making direct comments of
the "Andys type does/doesnt do such and such" variety:
(N.B. The next version 'pqs-1-01-00' will be a further evolutionary step.
The powers/upgradeability problem I think I have solved... more or less)
Yes I need much more/better/cohesive docs..I'm working on it .
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk