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

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-06-10 16:07:36

Andy Little said:     (by the date of Sat, 10 Jun 2006 17:58:35 +0100)

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:

# t1_quantity where the dimension and unit are fixed [during compilation].

     fixed_quantity    // it's fixed, right?

# 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

# t3_quantity where the dimension and unit can be modified at runtime.

     free_quantity     // it's free, right?

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

<snip>
> OK. I need to study UML for diagrams

start here: 
http://www.objectmentor.com/resources/listArticles?key=topic&topic=UML

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

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

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.

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

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

 

<snip>
> > #include <boost/units/length.hpp>     // to get length
> > #include <boost/units/io/length.hpp>  // or sth similar to get IO for length.
> > (input.hpp is OK too)
> 
> I think that is better than the current arrangement.

yeah :)

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

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

-- 
Janek Kozicki                                                         |