complex support

I pushed a new branch which now has basic complex support. Basically all the same functionality as the reals, with the exception of matrix pruning.

I consider the problem solved. I hope you might consider merging.

Hi Trevor,

I disapproved the merge as you see, as it is lots of new code while there is alreay (not yet used) infrastructure for making this substantially easier.

Let me explain: the visitors (if you uncomment the _NEW_VISITORS at the beginning of minieigen.cpp) define templates which themselves define python functions -- MatrixBaseVisitor, VectorVisitor, MatrixVisitor, AabbVisitor. The reason it is not enabled by default is that it is not yet 100% compatible with the current state. On the other hand, the code shrinks by more than half when enabled, so it is a way to go.

The visitors have different parts included for floating-point vs. integer scalars, and for fixed-size vs. dynamic-size matrices. Complex numbers fit very nicely into the mix. Check out how it Vector2r wrapped with visitors:

py::class_<Vector2r>("Vector2","doc").def(py::init<Real,Real>()).def(MatrixBaseVisitor<Vector2r>()).def(VectorVisitor<Vector2r>());

So you'd just repeat that for Eigen::Matrix<std::complex,2,1> and Vector2cr is done.

You merge request reminds me to finish the work on that, I will try to do it in the days to come. Can you check if visitors work with complex numbers right away?

Let's continue the discussion on this (here).

PS comaptibility with the current state of affairs (non-visitors vs. visitors) is needed as minieigen is used extensively by Yade and Woo projects, and breaking stuff on that side is not really acceptable. But it is almost there.

I implemented complex types via visitors in trunk (rev 39) - you can try it yourself, you need to uncomment the #defines at the beginning of minieigen.cpp: _NEW_VISITORS and _COMPLEX_SUPPORT. What is missing (for now) are ctors for vectors like Vector3c(1,2,5j), so you need to type a=Vector3c(); a[0],a[1],a[2]=1,2,5j . I will have a look at that soon. I guess you see the advantage of visitors now.

I agree that your solution is more elegant. Thanks. Seems to be working. I hope you might consider making this default once all the details have been ironed out.

Thanks.

I cleand the code up today and I think it is ready. Rev 44 got rid of the old code. I ran a few complex scripts with Woo and the results are the same. I will let people over using Yade know about the change so that they can report regression (I hope there are none). If you spot somethign suspicious, bug reports or merge requests are always welcome. Cheers, Václav

PS if your project something I could look at? Just out of curiosity.

Thanks for the update. I'll check it out. Minieigen is really useful for
me. Thanks, and thanks for jumping on this complex problem so quickly.

I am wrapping a geophysical (primarily electromagnetic) modelling and
inversion package http://lemmasoftware.org/

As an aside, for my purposes miniEigen (or a derivative) would actually
transparently map all Eigen vectors to numpy arrays. Minieigen already
works in reverse! Which is really nice. As far as my users are concerned,
there is no actual need to expose them to any of Eigen, I just need a way
to wrap methods that pass around eigen vectors. If that could be numpy
arrays on the python side, it would really be ideal. But, as is, it's
pretty painless, and you can easily convert using
x = np.array(MyVectorXr),
which I was extremely happy to see worked. I wonder if there would not be
additional use cases like mine? And if so, would you have an idea for how
best to do that?

Cheers,

-- Trevor

On 1 January 2014 11:51, Václav Šmilauer <
<email address hidden>> wrote:

> Your question #241201 on miniEigen changed:
> https://answers.launchpad.net/minieigen/+question/241201
>
> Václav Šmilauer posted a new comment:
> I cleand the code up today and I think it is ready. Rev 44 got rid of
> the old code. I ran a few complex scripts with Woo and the results are
> the same. I will let people over using Yade know about the change so
> that they can report regression (I hope there are none). If you spot
> somethign suspicious, bug reports or merge requests are always welcome.
> Cheers, Václav
>
> PS if your project something I could look at? Just out of curiosity.
>
> --
> You received this question notification because you asked the question.
>