"Janek Kozicki" wrote
Andy Little said: (by the date of Wed, 14 Jun 2006 20:22:35 +0100)
"Janek Kozicki" wrote
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...
I think the ability to distinguish quantity types is important for other purposes.
I'm sorry about being a bit picky. You said it's overcomplicated (11 lines above this line). Now you say it's needed (4 lines above ;)
I think you chopped the quote :-) I think I said that some reviewers had said that the t1_quantity/fixed_quantity was over complicated. The context I said it was about adding yet more functionality, this time to distinguish different unit systems. In case of distinguishing torque and energy, reciprocal time and frequency etc, I think its useful functionality. It would be useful to add the other too FWIW, but practically a huge job IMO, which I dont see as realistic for me to take on. That needs someone with more experience in physics AFAIKS.
Can you give examples of where ability to distiguish is useful? With exception of serialization examples because it is listed below (printing unit correctly).
The only example is serialisation or standard output, but I think that is enough.
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?
Having thought about that I come to the conclusion that it is worthwhile to have the extra complexity in the t1_quantity/fixed_quantity. Having some form of output/serialisation for quantities is seemingly trivial, something like a toy feature, but it is very useful indeed for demonstrating and communicating what the type can do and for diagnosing what it is doing with minimal effort. That may seem trivial but that type of feedback is very helpfull in the first stage of trying out a library to see what it can do. I can speculate that is part of the reason for the good level of interest in PQS, because it helps when providing short examples in discussions like this. That simple functionality is underrated IMO.
I have difficulties understanding this paragraph. You say that PQS should be able to print "N*m" or print "J" depending on the context, because it is a very helpfull feedback. Right?
Yes. Its for completeness, but the serialisation is modular and can easily be left out . The kind of place it might be useful is for students homework, short demos (<libs/pqs/examples>) exporting to a spreadsheet etc. (I am guessing here. It may not be suitable at all for students homework. I am not a lecturer), but for more serious use as in yade, if the distinction is not important ( as is the case for dimensional analysis checking) then the type could referred to strictly as an anonymous-quantity which could then be representing torque or energy(which are so-called named-quantities in PQS definitions section) but without the distinction being important for the current use. regards Andy Little