On Mon, Jul 18, 2011 at 2:55 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Mon, Jul 18, 2011 at 12:49 PM, Jeffrey Lee Hellrung, Jr.
[...]
To answer your question, there aren't currently functions to remove an element of a vector except as part of the swizzling support which can only output dimensions up to 4. For example v%YZ maps the Y and Z elements of a vector with size at least 3, as a 2D vector. There are functions for removing rows and columns of matrices, so perhaps a similar functionality makes sense for vectors in general.
Agreed; also the symmetric operations of (lazily) adding rows and columns to matrices and (lazily) adding elements to vectors would be useful, too.
No I have not. The determinant computations are currently pretty straight-forward, save the use of an off-line code generator.
I just ran through a quick count of the number of multiplies, and for 4x4 matrices, dynamic programming will reduce the number of multiplications from 40 to 28 over straightforward recursion, while for 5x5 matrices, the reduction from 205 to 75 (or so).
I welcome any optimization like this. Is it possible to write a generic code generator for this algorithm, similarly to the other code generators in libs/qvm/gen/gen.cpp?
I think it is, but it's certainly more challenging than the straightforward algorithm. Lemme look at this gen.cpp to see what you do. I'm curious, what are you reasons for not using the preprocessor for code generation? Is it not possible in this case? Too much of a maintenance problem? Compile-time speed? Haven't tried?
I guess that the documentation isn't clear but boost/qvm/math.hpp
defines function templates that correspond to the functions from <math.h>. The templates are specialized for float and double, but can be specialized for any other scalar. That said, I don't have tests using any other scalar type. Perhaps a fixed point scalar should be implemented to make sure there isn't something missing.
Are complex scalar types within the scope of the library?
I think so. I've certainly been very careful to design a type system that permits non-trivial scalar types.
I figured complex scalars might be tacitly supported, as you don't require ordering comparisons on scalar types, but I'm not sure the scalar type requirements you give are sufficient (e.g., you probably need conjugation somehow). In any case, this was more of a curiosity than an actual need.
Like I said, my motivation was to write a generic library that's useful for 3D graphics, but I'm not against extending the scope beyond that as long as things don't get too crazy. Complex and fixed point scalars seem appropriate,
Well, when you get that far, it seems you'll need to revisit your (documented) scalar requirements. It's possible that could be a precondition for review. but I know I don't want to support vectors
and matrices of dynamic size or general sparsity.
Of course.
I'll continue to browse through the library and let you know if I have additional comments or questions.
I appreciate your feedback!
No problem. - Jeff