Re: [boost] [qvm] few q's for emil

Subject: Re: [boost] [qvm] few q's for emil
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-07-19 02:54:30

On Mon, Jul 18, 2011 at 2:55 PM, Emil Dotchevski
<emildotchevski_at_[hidden]>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