Re: [eigen] a problem with RowsAtCompileTime in SparseVector

[Daniel Lowengrub <lowdanie@xxxxxxxxx>]

Ok, I'll try to fix it on sunday.  From what I understand, the
SparseVector should first check the size of other and then call
resize, similar to the SparseMatrix assignment.

Daniel

On Fri, Jul 23, 2010 at 1:47 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> Hi,
>
> yes the bug is rather in SparseVector where Dynamic sized was assumed.
>
> Feel free to fix it if you have time.
>
> gael
>
> On Fri, Jul 23, 2010 at 10:00 AM, Daniel Lowengrub <lowdanie@xxxxxxxxx> wrote:
>> Hi,
>> I noticed that the following code complies but crashes with an assert:
>> Vector10d d = Vector10d::Random(); //Vector10d is the obvious typedef
>> sd = d.sparseView();
>>
>> The assert is:
>> Assertion `( ((ei_traits<Derived>::SupportedAccessPatterns&OuterRandomAccessPattern)==OuterRandomAccessPattern)
>> || (!((Flags & RowMajorBit) != (OtherDerived::Flags & RowMajorBit))))
>> && "the transpose operation is supposed to be handled in
>> SparseMatrix::operator="' failed.
>>
>> On the other hand, this code is fine:
>> VectorXd d = Vector10d::Random();
>> sd = d.sparseView();
>>
>> I think that the problem is that in the SparseVector assignment
>> operator, the RowsAtCompileTime is checked:
>> inline SparseVector& operator=(const SparseMatrixBase<OtherDerived>& other)
>>     {
>>       if (int(RowsAtCompileTime)!=int(OtherDerived::RowsAtCompileTime))
>>         return Base::operator=(other.transpose());
>> ...
>>     }
>> And then since d.sparseView() takes the same RowsAtCompileTime as d
>> (which is 10 in the first case but -1 in the second) but sd has -1
>> RowsAtCompileTime, d.sparseView() is transposed in the first case
>> which leads to the assertation.
>>
>>
>> Should SparseView explicitly set RowsAtCompileTime to -1 (Dynamic)?
>> Or should the assignment operator call the resize method like in the
>> SparseMatrix class?
>>
>> Daniel
>>
>>
>>
>
>
>