Re: [eigen] Matrix assignment |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Matrix assignment*From*: Benoît Jacob <jacob@xxxxxxxxxxxxxxx>*Date*: Tue, 21 Oct 2008 14:26:34 +0200*Cc*: Cristóvão Sousa <crisjss@xxxxxxxxx>

On Tuesday 21 October 2008 14:07:47 Cristóvão Sousa wrote: > > 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. > > Well, if the auto re-size was removed from operator= then a > couple of checks would be removed, right? But, introducing auto > re-size for zero sized matrices would introduce a check... That's true. It's not as bad as the current situation though: only one rows(),cols() pair to read from memory instead of two. > > I think that the need of an auto/non-auto re-size feature will > always be dependent on the application: > > - In a Matlab like style the matrices should be automatically > re-sized. > - Also, in a more traditional C++ approach, coping an object to > an other should make the destination object "equal" to the > original, as is proposed to happen with zero sized matrices. > - But in many cases, as in my specific application needs, it is > desirable to maintain the destination matrix size unaltered, > raising an failure if matrices have different sizes and debug > mode is enabled. This can eliminate the overhead (if any) of > checking sizes in non debug mode, As you said it gets replaced by the smaller overhead of checking for nonzero size. Will hardly make any difference in practice, but it's always nice to reduce this constant overhead. > and is more consistent with > fixed-size matrices, as you said. > > > I did had not mentioned but when I realise that the operator= > re-sizes the destination matrix, the first solution, which did > not worked, that comes to my mind was to use the .cwise() in the > lhs matrix: > > m0.cwise() = m1; > > as in "m0.cwise() += scalar". I'm not for using cwise for that, it's not explicit enough IMO. It's like in C++ the static keyword is used for too many different things. > > This can be a solution too, although it could turn to be not > very clear if the rhs expression should be a matrix with equal > size or a scalar. Indeed > > Another solution that may be nice is to deny any resizing unless > you call some function, like: > > m0.copy(m1); > or > m0.assign() = m1; This could be called m0.resize() = m1; I am not coding currently but I will be keeping this thread in mind for my next coding phase, unless Gael beats me to it. Cheers, Benoit ---

**Follow-Ups**:**Re: [eigen] Matrix assignment***From:*Benoît Jacob

**References**:**[eigen] Matrix assignment***From:*Cristóvão Sousa

**Re: [eigen] Matrix assignment***From:*Gael Guennebaud

**Re: [eigen] Matrix assignment***From:*Cristóvão Sousa

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Matrix assignment** - Next by Date:
**Re: [eigen] Matrix assignment** - Previous by thread:
**Re: [eigen] Matrix assignment** - Next by thread:
**Re: [eigen] Matrix assignment**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |