Hi Oleg, "Oleg Abrosimov" wrote
Janek Kozicki writes:
Andy Little said: (by the date of Tue, 13 Jun 2006 00:59:11 +0100)
t1_quantity type in PQS is overcomplicated. Two decisions complicated the design of t1_quantity. The first was the requirement to distinguish dimensionally equivalent quantities (torque and energy say).
IMHO this distinguish is not that important. We only need units so that compiler will check if there is any mistake in the formulas...
Difference between torque and energy happens only during serialization (print N*m, or print J ?), so maybe instead of complicated abstract_quantity_id, there should be just some extra argument/setting that will talk with serialization functions?
Maybe this will make the design a bit leaner.
I'm completely disagree here.
1) Can anyone provide a really useful example of quantities with units encoded? I mean all these "length::m" things in PQS. There were requests to disable it and reduce to simple "length" and treat with units only in I/O with help of manipulators. Note that historical units can be handled in the same way:
length l; cin >> l; // in meters by default cout << hyst_unit_manip << l;
The genesis of PQS was the need in my own work to remember which unit a floating point variable was expressed in. In this particular application the user had various data entry boxes where the entry unit was millimeters. In my internal calculations I had to convert these lengths to meters. Again I had to convert them back for output. I found I spent a huge amount of time going back and forth between source files trying to remember whether a particular variable was in meters or millimeters. You could argue that the design of the application was poor but it was one of those applications that grow from very simple beginnings by gradual additions into a huge creaking monster. Users of the application often made requests to be allowed to specify other units (feet and inches, meters etc) for data input too I also had an email from a software house who needed to work in imperial units for their work and had done some tests and found PQS potentially very useful for their work. Finally of course there is the famous example of the Mars Lander which crashed wasting Millions of dollars, apparently because one team was using metric and the other imperial units. There are countless other examples too.
2) torque is a really bad smell in PQS! it has the same dimension as an energy and, if I'm not wrong, is treated in the same way, so one can add torque and energy. It is a completely meaningless. There can not be meaningful equation that do that. And if PQS allows it it means that it is broken here IMO.
Actually PQS works in terms of so-called anonymous quantities where only their dimension and unit is significant. The results of many calculations return an anonymous quantity because I dont see any simple way to predict from the imput variable what type the result should be.. The so-called named_quantities are there for users who want to distinguish quantities for their own purposes. (the obvious one being more satisfying output). OTOH if you can come up with a way to distinguish the result of force * distance into either torque or energy depending on some criteria I would be interested. FWIW I experimented with making torque have an angle ValueType. That approach might be worth pursuing. My reason for not pusuing it was that I felt that many potential users would simply find the extra complexity annoying ( as I did during trying it out). And of course in the limit an angular velocity (*radius) becomes a straight velocity etc, etc...
the problem here is that PQS deals with only dimensions, but physical quantities have not only that, they have rank also.
the difference between energy and torque is such that energy is a scalar and torque is a vector, or, more correctly, a pseudovector (it doesn't change its sign if space is inversed. velocity is a vector, it negates when space is inverted).
it is completely wrong to add a scalar and a pseudovector (or vector). rank really matters! moreover, adding scalar with pseudoscalar or vector with pseudovector is meaningless too. such a summation can not occur in any correct equation.
Sure there is a lot of truth in what you are saying. What is lacking is a set of rules that can be used to apply these principles. I believe that Matt Calabrese was working on this aspect of quantities some time ago, so it might be worth talking to him about it. I opted to stick to dimensional analysis checking only and ignore other features of a quantity. I have enough on my plate as it is. So I accept the criticism of PQS, but I believe a working implementation of what you are describing will throw up difficulties (based on a small excursion into that territory) that add a lot of complexity, nevertheless I would be interested in at least some more details about how it would work in practise. It should be clear from the amount of input in this review that this field is potentially huge and worthy of much further research. The PQS library only scratches the surface and leaves many gaps as you are saying. However my goal is to keep PQS as simple as possible (IOW basically as it is now), but to tighten up the documentation, add supporting classes (again a simple set as possible), continue to look through the comments here, accept suggestions for syntax and usability improvements etc etc, but not to extend into the territory you are suggesting (largely as I keep saying because my maths and physics capabilities simply arent good enough). It will then be up to others like yourself to criticise and extend improve on, reject etc, etc PQS as part of that research. regards Andy Little