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 |
