From: Andy Little (andy_at_[hidden])
Date: 2006-06-14 16:43:51
"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
> 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
>> > 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
>> the extra complexity in the t1_quantity/fixed_quantity. Having some form of
>> output/serialisation for quantities is seemingly trivial, something like a
>> feature, but it is very useful indeed for demonstrating and communicating
>> the type can do and for diagnosing what it is doing with minimal effort.
>> may seem trivial but that type of feedback is very helpfull in the first
>> of trying out a library to see what it can do. I can speculate that is part
>> the reason for the good level of interest in PQS, because it helps when
>> providing short examples in discussions like this. That simple functionality
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk