Re: [eigen]

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/6/1 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> I revert my change! Sorry!

This is now reverted (the ReturnByValue changes). Instead, we now do a
simple aliasing check, that in the case of your test program,
correctly reports:

.../eigen/Eigen/src/LU/Inverse.h:299: void
Eigen::ei_inverse_impl<MatrixType>::evalTo(Dest&) const [with Dest =
Eigen::Matrix<double, 2, 2>, MatrixType = Eigen::Matrix<double, 2,
2>]: Assertion `&dst != &m_matrix && "Aliasing problem detected in
inverse(), you need to do inverse().eval() here."' failed

By the way, this made me think of how a really complete aliasing check
system could work (only in debug mode, perhaps even a non-default
stronger debug mode). When doing an assignment (dst=src), the dst
could query the src expression for "do you alias this address?" and
the src would recursively scan, for example, in x=y+z, x asks y+z "do
you alias ptr?" and y+z asks its own members y and z, etc. Doing this
on &dst(0,0) would already be quite good and not too expensive; doing
it on all of dst's coeffs would be very expensive, but would offer
complete safety.

Benoit

>
> Benoit
>
>>
>> gael
>>
>>
>>
>> On Sun, May 30, 2010 at 7:46 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>
>>> This is now fixed.
>>>
>>> The problem was not specific to inverse(), but existed for all ReturnByValue-enabled function. For example, doing x = y.solve(x) would probably have exhibited the same aliasing issues.
>>>
>>> The fix was to make ReturnByValue evaluate-before-assigning. If you want the old behavior (slightly more efficient), you can use .noalias() to tell Eigen not to care about aliasing, like this:
>>>
>>>   x.noalias() = y.inverse();  /// don't do this if y aliases x !!
>>>
>>> Since this is the behavior for products, it felt natural, API-wise, to do the same for other "multiplicative" operations such as inverse(), and more generally, solve() and friends.
>>>
>>> Benoit
>>>
>>> 2010/5/30 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>>>>
>>>> aaahh... this had me puzzled for a while, but what you really have here is an aliasing problem. With the devel branch, when you do S = S.inverse(), S starts being overwritten with its inverse and then read again to compute the rest of the inverse... i need to have a look at the code to see if we're getting any speed gain from that, a priori i'd say let's work like in 2.0, taking care of aliasing, and if later there is demand for a super optimized noalias variant, we can then add it with an explicit name like a.noalias()  = a.inverse(), like for products.
>>>>
>>>> Benoit
>>>>
>>>> 2010/5/28 SHIROKOBROD Oleg <Oleg.Shirokobrod@xxxxxxxxxx>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> I’ve met a problem with development branch. Here you are the case.
>>>>>
>>>>>                                    { -2.0                                     -1.0 }
>>>>>
>>>>> I have a 2x2 matrix S = {                                                   }
>>>>>
>>>>>                                    { 0.00026130287408377900     -2.0 }
>>>>>
>>>>>
>>>>>
>>>>> and I want to inverse it. This is the code I compiled with MSVS 2008
>>>>>
>>>>>
>>>>>
>>>>> #include <Eigen\Core>
>>>>>
>>>>> #include <Eigen\LU>
>>>>>
>>>>>
>>>>>
>>>>> Eigen::Matrix<double, 2, 2> S;
>>>>>
>>>>> S << -2.0 , -1.0 , 0.00026130287408377900 , -2.0;
>>>>>
>>>>> S = S.inverse();
>>>>>
>>>>>
>>>>>
>>>>> Eigen2 gives the right answer
>>>>>
>>>>>
>>>>>
>>>>>                    {-0.499967339
>>>>>
>>>>>            0.24998367}
>>>>>
>>>>> S.inverse  =  {
>>>>>
>>>>>
>>>>>
>>>>>                    {-6.53215E-05
>>>>>
>>>>>           -0.499967339}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Eigen3 (development branch I got on 26.05) gives a wrong answer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                    {-0.499967339
>>>>>
>>>>>            0.24998367}
>>>>>
>>>>> S.inverse  =  {
>>>>>
>>>>>
>>>>>
>>>>>                    {-6.53215E-05
>>>>>
>>>>>           -0.124983670170524}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What’s wrong?
>>>>>
>>>>>
>>>>>
>>>>> Thank you,
>>>>>
>>>>>
>>>>>
>>>>> Oleg Shirokobrod
>>>>>
>>>>>
>>>>>
>>>>> ___________________________________________________________________________
>>>>> This e-mail is confidential and is for the addressee only.   Please refer to
>>>>> www.oxinst.com/email-statement for regulatory information.
>>>
>>
>