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
>> 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
>> 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
>> 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
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
>> 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
>> 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
> 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 !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk