|Re: [eigen] Matrix assignment|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Matrix assignment
- From: "Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>
- Date: Mon, 20 Oct 2008 20:36:05 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=O17wV98aQMOtfqZlDgWpogJUi1tI+QM8jBbH6wmH2jQ=; b=e/73JqSelnOIGe9r86FVzAwvc4pKzsHkizhrlHcF8F/3MKgKltK6Ode42J+jXdzNkk qGy1xCa33bNRwGFRDZow4IjiBHmibYQEciMU1RubG+kisT4krTqcCjtn2kjFm8B0S8sL 5NJ7q1/2TeltbjCvnpTKweAoG4L62H3THq3pA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=nh2ca4kCRuXt2SomIsjl68qW7EkHkkGx+NgM6R0LSVodxYsvDkd9cUVyFxWxtfXL4I 9GqNyfr+kEI11N55KiPyfNh3yIXIyVj8MsxT/0FwQR1tTOiZxpGjILTLCVrQaLEgV2NV W1CayXx9uwNGpJjn99PCW3aSYV4OQyx4pSmCA=
first of all thanks for the very kind words :) it is nice to see that
we are not the only ones to think that !
thanks also for putting that issue on the table. This is indeed
something that might be confusing and hide bugs, and as far as I
remember we've never debated about it.
before the debate, let's answer the question about the performance of
operator<<. Actually doing "m0 << m1" yields:
m0.block(0, 0, m1.rows(), m1.cols()) = m1;
plus 2 comparisons to check that m1.rows()==m0.rows() and m1.cols()==m0.cols().
So, in practice you lost the knowledge that both the rhs m1 and lhs m0
have the same alignment and so the vectorized copy/evaluation might be
a bit slower. However I'm not 100% here, the underlying mechanisms are
quite complex ! Also, I've observed that sometime gcc gets confused
with the Block expression and generates sligthly less efficient code
(gcc-4.4 seems to solve that issue). So, to conclude I would rather
try to avoid the use of << for that purpose, even though, again, the
best is to try and bench !
Now what about the automatic resizing of operator= ? Honestly I would
not be against removing this feature and enforcing that the left-hand
side has the correct size. This is also more consistent with
fixed-size matrices which cannot be resized anyway. In that case we
could add the folfowing exception: the lhs will still be automatically
resized if its size is 0. Well, currently we cannot create such an
empty matrix, but I think that would be nice to allow that regardless
of the automatic resizing issue.
Let me also mention that the operator <<= is not used yet, and it
could be used to implement one of the missing semantic of operator =,
either assignment with automatic resizing or without depending on the
decision we made about operator=. Actually, I mentionned that idea
just is case some people would champion it, but personaly I would
prefer not to introduce an additional assignment operator.
ok, well... any more firm opinions ??? ;)
On Mon, Oct 20, 2008 at 7:18 PM, Cristóvão Sousa <crisjss@xxxxxxxxx> wrote:
> I'm wondering what operator is better for matrix (coefficient wise like)
> = or << ?
> I have a matrixXd "m" which will store the result of some matrices(Xd)
> Matrix "m" should have a fixed size, only known at runtime. If for some reason,
> related to a bug in my code, the operations result in a different matrix size,
> the assignment
> m = "operations with m2,m3,m4,..."
> will change "m" size.
> I rather need, for debug purposes, an assertion failure being raised.
> I discover that the "<<" operator does just what I need (it fails even if the
> operations resulting matrix is smaller than "m").
> But now I'm wondering if "<<" operator is equal, in terms of speed and laziness
> optimizations, to the "=" operator.
> Thanks in advance. And thanks very very very much for Eigen! It was the matrix
> killer library I was looking for! I had tried Blitz,boost::ublas, GSL, Tvmet,
> Honestly, Eigen (version 2) is just the best single piece of C++ code I ever
> Cristóvão Sousa