Boost logo

Boost :

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


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