Re: [boost] [PQS] wiki, decoupled library names.

From: Andy Little (andy_at_[hidden])
Date: 2006-06-23 17:36:15

"Phil Richards" wrote
> On 2006-06-23, Andy Little <andy_at_[hidden]> wrote:
>> > I concur.  I was already concerned with the size of PQS - recent
>> > discussions have made me distinctly worried.  PQS should do roughly
>> > what it says on the tin: dimensional analysis and units.  Do it
>> > small, do it tidily, do it clean.
>>  That is all very well Phil. Now where's the code?.
>>  Actually I know you have written some code. I would be interested naturally
>> to
>>  see it.
>
> Well, even so, I think your comment is a little bit unfair given that I have
> implemented most of what I've talked about in the past.

You are criticising my work. I believe you have been unfair. You say you can do
better . Its only reasonable to expect a demo isnt it?

> I still think that PQS at 24,000 lines of code is rather on the heavy
> side.  And all the talk I've seen is about adding more.  BUt I might
> have missed something.  It's been a long thread.

I havent calculated in terms of Klocs, but (if you have a copy of pqs_3_1_1),
you could look at the <boost/pqs/t1_quantity/types> directory.
You should also add in the <boost/pqs/meta/components> directory, the
two_d,three_d, angle and utility stuff.

That adds up to around 2/3 of the total code size on my local disc AFAICS. That
comprises what I call User interface.

>>  What happens when you start a quantities library is that you suddenly find
>> the
>>  problems are a bit bigger than you thought.
>
> Probably don't need to remind me of that...
>
>>  The dimensional analysis part is frankly trivial. The bloat you talk about
>> is
>>  the result of going into detail that previous libraries ignored:
>>  User interface, units and basic input/output.
>
> Done basic input/output.  Done *simple* units conversion (and I admit,
> it is nowhere near to the depth you did - and I like the ideas behind
> what you have done in that area, but that doesn't mean that a
> functionally equivalent solution to yours couldn't be achieved).
>
> Not sure what "user interface" is and I'd probably say it was subjective
> anyway.

User interface is first the convenient typedefs with units, second the
supporting classes for physical quantities in space, as I mentioned above.. 
Physical quantities is
a brave new world from floats.

>>  IMO the other problem that previous libraries had was that they assumed that
>>  using mpl was mandatory. [...]
>>              I did so with a heavy heart because I was aware that doing so
>> would
>>  probably kill PQS as a boost library
>
> Don't really think it is a killer.  I've done it both ways - the MPL
> took a lot of effort to get anywhere near reasonable compile-time
> performance, and even then it was at least a factor of 2 slower.  So,
> I agree with you about not using.

OK, and I think its worth pointing out for anyone developing their own units
library. Its another hurdle for me because its a central theme in the TMP book.
Its also an underlying reason for rejection of PQS AFAICS. The myth continues
....

>>  I mean if the problems were trivial boost would have its quantities library
>> by
>>  now wouldnt it?
>
> Erm, yes.  One of the reasons I gave up on this whole thing (in Boost)
> was simply that trying to get measurable/achievable requirements was
> rather hard.  And I can't solve problems in domains for which I have
> no experience without some practical use-cases.

I rest my case ..................;-)

>> > It's nice to see that there appears to be a move in the direction
>> > of separating the dimensional analysis and units into orthogonal
>> > bits, though.  It's the way I've gone... :-)
>>  Are you saying that PQS doesnt do that?
>
> Perhaps I should have used "independent" rather than "orthogonal".
>
>>  The signature of the t1_quantity is
>>  t1_quantity<abstract_quantity, unit, value_type>
>>  That looks like quite a  clear separation of concerns to me FWIW.
>>  Am I missing something?
>
> Yes.  It should (ideally) be something like:
>    dimensioned<value_type, dimension>
>    united<value_type, unit>
> for any "reasonable" value_type (and both united and dimensioned would
> be "reasonable").  Or some such.

In practise what this means is that the user needs to deal with the
united_value. That means either a special case for quantities that use it as a
value_type or rewriting sin, cos, and everything in <cmath> FWIW.

Feel fee to do that if you wish ;-)

The underlying reason is that there is no such thing as a quantity without units
FWIW.

> If you only want dimensionality checking, you can have it without units.
> If you only want units, you can have it.  If you want both, you stack
> them.  (united<dimensioned<value_type, dimension>, unit>)
>
> Yes, I know it's not that easy.  And it might even require typeof to be
> even slightly achievable, so might even be a non-starter.  I just wish I
> had time to have a play with it :-)
>
> As you imply, unless I'm willing to code it, I really should shut up.
> So I will.

No offence intended Phil, I know you have done a lot of work in this area. Its a
shame you didn't get time to do a review. I would have been interested in that.

Again.. Congrats on the baby !

regards
Andy Little