| Re: [eigen] [Review] Pull request 66, Huge Tensor module improvements |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
Hi!
On 11.06.2014 20:27, Christian Seiler wrote:
Ok, since we're looking for an arbitrary number anyway, why don't we
just say 10?
"640 [...] should be enough for everyone"
Bonus question: What is the smallest arbitrary integer? ;)
(10 is not correct because it is not arbitrary)
however I
don't see an equivalent to the Eigen Matrix class in the tensor world.
One of the first times I heard about Tensors was the generalizing of
linear maps to multi-linear maps (e.g. when describing a
multi-dimensional Taylor series). So I agree with Christian on that --
also that preferably you should not implement operator* at all, because
even the multi-linear map interpretation is ambiguous.
The downside of the pblend approach is that the then and else expression
always have to be evaluated. When using a packet of 4 there is a 12.5%
chance that either can be completely skipped, so the non vectorized
implementation of select might be faster in some case. Before using the
pblend instruction in Eigen Core I'd like to update the evaluation cost
model to reflect this.
That really depends on the then/else expressions. I think in most cases
avoiding branches and completely exploiting vectorization should be
worth the effort. There is a problem with invalid expressions, e.g. the
following Array::select expression is all right only with current lazy
evaluation:
ArrayXi A, B;
// ...
ArrayXi C = (B!=0).select(A/B, 0);
There is no packet integer division, so this couldn't be vectorized
anyways, but it should be clear if select selects everything, only
what's necessary or whether this is not specified (e.g. if it depends on
the evaluation cost).
The Map code assumes a 2D layout in several places. For example, the
notion of inner and outer strides assume there are exactly 2 strides.
Similarly, referring to a coefficient can be done by row and column. On
the other hands, n dimensional accessors are missing. Long term I'd like
to see the Tensor code moved into Eigen core and the TensorMap merged
with the Map class, but for the time being I thought it was safer to
create a TensorMap class.
No, you completely misunderstand me: I don't want to reuse the code of
Map<>. It's clear that this won't work. I just want to reuse the name,
so that the user has a consistent API.
Yes, there is also the example of Map<Quaternion> which shares
practically no code with Map<Matrix> or Map<Array>.
Generally speaking: just to be on the same page about a future plan: I'd
also like to continue working on the Tensor module myself (that's why I
started this thread in the first place), so we need to do a couple of
things:
If you just want to both work on the code, there is no need to pull it
to the main repository. You can give each other write access to your
private branches and we can pull it to the main repository once it is in
a more complete status.
I don't object having experimental code in the unsupported modules, but
if you are going to change the API several times in the official
repository you will annoy possible users of your module -- of course
they should not rely on having a stable API yet, but it's definitely
preferable to limit API changes.
Christoph
--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen
Tel: +49 (421) 218-64252
----------------------------------------------