Re: [boost] [Review][PQS] Review ends

From: Andy Little (andy_at_[hidden])
Date: 2006-06-11 04:29:25

"Janek Kozicki"
> Andy Little
>
> Hello :)
>
> <snip>
>> >    It would be nice if t1_quantity was renamed to some descriptive word.
>> > Perhaps a discussion on the mailing list would help to discover a better
>> > word.
>>
>> Perhaps just quantity1, quantity2, quantity3 or quantitya, quantityb,
>> quantityc.
>
> OK, I'll give it a shot, because the point is not to move number (or
> letter) to the end of the name:

OK ... :-)

Thanks for the suggestions that follow:

> # t1_quantity where the dimension and unit are fixed [during compilation].
>
>     fixed_quantity    // it's fixed, right?

Its dimension and unit are fixed, but its value isnt fixed, but the name is
better than t1_quantity !

> # t2_quantity where the dimension is fixed [during compilation] but the unit
> can be modified at runtime.
>
>     scalable_quantity // changing unit means, that the underlying numbers are
> scaled

OK.

> # t3_quantity where the dimension and unit can be modified at runtime.
>
>     free_quantity     // it's free, right?

I did think of uni_quantity or universal quantity

Yes these names make more sense.

FWIW I think there is another important variant. This is a quantity whose
dimension can change , but whose unit is fixed. The purpose of this would be for
run-time dimensional analysis of calculations with a guarantee of no scaling. .
OTOH  the 'free_quantity' could have a flag settable to restrict its operations
so that scaling is banned. The free_quantity would be switched in for debugging
and switched out for release as  Leland Brown described earlier.

> <snip>
>> > I recommend to investigate
>> > tight integration with boost::numeric::ublas. I'm sure that people
>> > responsible
>> > for that library will gladly accept the idea, and accept any patches
>> > related
>> > to
>> > this. Basically this will make boost::ublas a ,,sort of'' part of pqs.
>> >    Other solution would be to reimplement such huge matrices in pqs, but
>> > how
>> > far Andy could go?
>>
>> I dont know if its possible. Another option is to cast the quantities to
>> numerics. IOW exit the type checking. I will have to ask on the ublas list.
>
>
> I must admit that I don't know where to start. Asking on ublas list is
> a very good idea. I remember that Noel Belcourt spent some time trying
> to adapt his Finite Element code to pqs - maybe he has some interesting
> suggestions about that.

Noel Belcourt is working on a Units library which is in the Boost Sandbox. I
looked at it but didnt understand the approach. What you say may shed some light
on the work. Anyway I will ask him.

I have been thinking about this whole issue of dimensional analysis checking and
how to apply it. I realise that my view has been very one-sided because I have
worked only on the so-called fixed_quantity. Because of the 'compile time checks
only' constraint,  the so-called 'fixed_quantity' is very restricted in what
areas it can be used.

Though I have little experience of matrices beyond 3d transform matrices it
seems that mathematicians will do calculations in matrices which causes the
quantity type of the element to change at runtime which rules out the
fixed_quantity.  Feedback from you and others confirms the real benefits of
being able to run dimensional analysis checks on your calculations, but to be
able to take out the diagnostics tools so that they dont affect the release
code, seems like another area that should be explored. (Again Leland Brown has
implemented this AFAIK).

>> > until I guessed that it's some kind of Cpp pseudocode.
>> I could make it clear and maybe try to follow conventions too. Maybe I should
>> make like GIL:
>
> I'd prefer real C++, what others think?

I think it follows Concepts C++ language proposals. If so then one day that code 
might be real C++.
See :

http://www.generic-programming.org/languages/conceptcpp/

> <snip>
>> >    OK, my favourite name is one letter longer, but still - "math" says a
>> > lot
>> > more than "three_d", so this name is more descriptive, IMHO.
>>
>> Maybe even lose math:: ?
>
> hmm.. I'm not sure. maybe better not. Having vector3d in the same
> directory/namespace as unit length makes me feel uneasy.

OK. how about a namespace called three_d then  ;-)

Seriously though I think vector3d and three_d::vector are functionally
equivalent and, bearing in mind your dislike of sticking letters and numbers on
type names, I can't see whats wrong with the latter. What are the arguments for
the '3d' suffix on the name?

> boost::units::math - is clear to understand - math classes with support
> for units. I don't mind writing one extra namespace name when it makes
> perfect sense. Paul said wisely: "write once, read many". Math constants
> will also reside there.

OK. This is a contentious issue with conflicting views from several people.
Hopefully math constants will be a separate library so they arent any way
dependent on anything in PQS library. OTOH physics constants are, because they
must be compatible with quantities so there is a direct dependency on PQS.
However, the way constants are done in PQS as member elements of a struct e.g
boltzmannns_constant::K, means that any sub namespace is technically redundant
for them.  As for geometry a 'vector' in the root namespace cant work, so either
suffixing the name or a sub-namespace must be used to distinguish 2D and 3D (
and nD ??) versions. A namespace is slightly more flexible in that you can make
use of using directives and using declarations so only need to qualify when
using (say) two_d::vector  while the default vector is implied as
three_d::vector.

FWIW the worst part about the 3D namespace IMO is the actual name 'three_d'.

> <snip>
>> > rename rc_matrix into matrix, and never implement cr_matrix. There is
>> > an interesting reasoning about this problem inside panda3d software
>> > manual (given time I'll find it later).
>>
>> Its certainly less work sticking to one type of matrix so I dont object to
>> that.
>> There may be performance resaons to choose on or other type?
>
> I have found that excerpt in panda3d manual. But for whatever reasons in
> new release of manual they have removed this chapter. So I can't point
> some URL to it, instead I have added it as an attchment. (Note to
> readers: it is .html, you might want open it in your favourite browser).
>
> There shouldn't be any performance differences. It's just that vectors will
> work with matrices (be internally compatibile). And that's all.

I'm all in favour of less work  :-)

> <snip>
>> >    without pqs: 3.8 seconds
>> >    with pqs   : 4.8 seconds
>> >
>> It is interesting to see the comparison.  I spent some time trying to keep
>> compile times down.
>
> IMHO compilation time is not that important. We have distcc, and
> processors are getting faster and multicore. Design, (and runtime speed,
> which comes with good design) - that's what really matters.

Yes, I  should work on this mechanism of using the checked quantities only for
debugging, but leaving no artefacts of them(like reduced speed) for release. I
should also work on closing the gap betwen fixed_quantity and floats too though.

[...]

>> use a typedef defined so that  quantities/ floating
>> point types are swapped in to do dimensional analysis then swapped out in
>> favour
>> of floats in finished code. I have written some code this way.
>
> that would be a nice option. At least to compare perfomance difference:
> speed with and without units.
>
>> All these usages are possible including the default style, the SI_units style
>> preferred by Jesper  Schmidt and the style described above...
>
> I can't find his posts on the mailing list...

See the post entitled '[review] forwarded comments on pqs' from Thorten Ottosen.

message id  news.gmane.org gmane.comp.lib.boost.devel:143767

Unfortunately I cant seem to get a direct link.

> <snip>
>> > operator *= for vect was missing. I had to write { vect1 = vect1 *
>> > some_scalar;};
>> >    Also vect has a function magnitude(), please add squared_magnitude().
>>
>> OK. vect is quite new and unfinished, needs a lot of work and tests of
>> course.
>
> I bet I can help a bit with that.

Great. I need to sit down and think about where PQS is going in tlight of all 
the review feedback. It depends majorly on the review result of course.  If PQS 
is accepted then Boost CVS and Test can be utilised, else it should really go to 
another database somewhere. I dont have one except a local one. I guess the 
Boost Vault is better than nothing though.

regards
Andy Little