Boost logo

Boost :

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
>> 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

>> > 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.

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at