"Phil Richards" wrote
On 2006-06-23, Andy Little <andy@servocomm.freeserve.co.uk> 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