VS2012 inconsistent Debug/Release results with lu_substitute() 1.55 & 1.52

classic Classic list List threaded Threaded
4 messages Options
JT
Reply | Threaded
Open this post in threaded view
|

VS2012 inconsistent Debug/Release results with lu_substitute() 1.55 & 1.52

JT

Folx,
ublas is not my specialty, so apologies if Ive done something silly, but
as I get different results with Debug & Release builds on identical
code, I think there is a problem in ublas's interaction with Visual
Studio 2012.
[There may also be problems in my code, but I think its simple enough
that I expect consistent answers (I view consistently wrong as better
than inconsistent). ]

MS Windows 7
Visual Studio 2012
Boost 1.55 or 1.52 (I think also earlier, but I didnt go back that far
to test)

Simple usage of Fredrik Orderud's LU decompisition matrix inversion
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LU_Matrix_Inversion

I've disabled _SCL_SECURE_NO_WARNINGS because its not standard C++.

Ive disabled BOOST_UBLAS_TYPE_CHECK because I wanted to check with error
control flow caused differences.

Any guidance on why the results are inconsistent ?

thanks,
- JT


_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]

umt.cpp (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VS2012 inconsistent Debug/Release results with lu_substitute() 1.55 & 1.52

Nasos Iliopoulos
jT,
try this:
change line:
std::copy( &(input_data[0][0]), &(input_data[matSize-1][matSize-1]), data.begin() );

to:
std::copy( &(input_data[0][0]), &(input_data[matSize-1][matSize-1]) + ptrdiff_t(1), data.begin() );

(The last iterator should be one past the last element)

You might get another response that was sent prior to this and has some further valid points you may want to keep in mind.

-Nasos

On 10/20/2014 07:53 AM, tidswell wrote:

Folx,
ublas is not my specialty, so apologies if Ive done something silly, but as I get different results with Debug & Release builds on identical code, I think there is a problem in ublas's interaction with Visual Studio 2012.
[There may also be problems in my code, but I think its simple enough that I expect consistent answers (I view consistently wrong as better than inconsistent). ]

MS Windows 7
Visual Studio 2012
Boost 1.55 or 1.52 (I think also earlier, but I didnt go back that far to test)

Simple usage of Fredrik Orderud's LU decompisition matrix inversion
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LU_Matrix_Inversion

I've disabled _SCL_SECURE_NO_WARNINGS because its not standard C++.

Ive disabled BOOST_UBLAS_TYPE_CHECK because I wanted to check with error control flow caused differences.

Any guidance on why the results are inconsistent ?

thanks,
- JT



_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]


_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
JT
Reply | Threaded
Open this post in threaded view
|

Re: VS2012 inconsistent Debug/Release results with lu_substitute() 1.55 & 1.52

JT
Thank you Nasos.

The bug Nasos identified crept in when I tried to extract a suitable
sample for posting.

But I think I still have a problem:
  * lu_factorize() is returning 0 (which if I understand API correctly
means not singular)
  * if I reenable the type checks then the upper triangular type check
in lu_substitute() fails.
     (see my inserted #error in code fragment below)

Is it reasonable for the solution not to be upper triangular when the
matrix is not singular ?

thanks,
- JT

template<class M, class E>
     void lu_substitute (const M &m, matrix_expression<E> &e) {
         typedef const M const_matrix_type;
         typedef matrix<typename E::value_type> matrix_type;

#if BOOST_UBLAS_TYPE_CHECK
         matrix_type cm1 (e);
#endif

         inplace_solve (m, e, unit_lower_tag ());

#if BOOST_UBLAS_TYPE_CHECK
         BOOST_UBLAS_CHECK (detail::expression_type_check (prod
(triangular_adaptor<const_matrix_type, unit_lower> (m), e), cm1),
internal_logic ());
         matrix_type cm2 (e);
#endif

         inplace_solve (m, e, upper_tag ());

#if BOOST_UBLAS_TYPE_CHECK
#error "This is the check that fails in debug!"
         BOOST_UBLAS_CHECK (detail::expression_type_check (prod
(triangular_adaptor<const_matrix_type, upper> (m), e), cm2),
internal_logic ());
#endif
     }


On 21/10/14 02:01, Nasos Iliopoulos wrote:

> jT,
> try this:
> change line:
> std::copy( &(input_data[0][0]), &(input_data[matSize-1][matSize-1]),
> data.begin() );
>
> to:
> std::copy( &(input_data[0][0]), &(input_data[matSize-1][matSize-1]) +
> ptrdiff_t(1), data.begin() );
>
> (The last iterator should be one past the last element)
>
> You might get another response that was sent prior to this and has
> some further valid points you may want to keep in mind.
>
> -Nasos
>
> On 10/20/2014 07:53 AM, tidswell wrote:
>>
>> Folx,
>> ublas is not my specialty, so apologies if Ive done something silly,
>> but as I get different results with Debug & Release builds on
>> identical code, I think there is a problem in ublas's interaction
>> with Visual Studio 2012.
>> [There may also be problems in my code, but I think its simple enough
>> that I expect consistent answers (I view consistently wrong as better
>> than inconsistent). ]
>>
>> MS Windows 7
>> Visual Studio 2012
>> Boost 1.55 or 1.52 (I think also earlier, but I didnt go back that
>> far to test)
>>
>> Simple usage of Fredrik Orderud's LU decompisition matrix inversion
>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LU_Matrix_Inversion 
>>
>>
>> I've disabled _SCL_SECURE_NO_WARNINGS because its not standard C++.
>>
>> Ive disabled BOOST_UBLAS_TYPE_CHECK because I wanted to check with
>> error control flow caused differences.
>>
>> Any guidance on why the results are inconsistent ?
>>
>> thanks,
>> - JT
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> [hidden email]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to:[hidden email]
>
>
>
> _______________________________________________
> ublas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to:[hidden email]

_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: VS2012 inconsistent Debug/Release results with lu_substitute() 1.55 & 1.52

Oswin Krause
Hi,

this error occurs most likely, because the test of the numerics is much
too strict. This just measures an error bound between the elements of
both matrices. most likely lu_substitute had to divide a big number by a
small one. (you can print out the diagonal of m to see whether it
contains very small values)

We have had problems with the UBLAS_TYPE_CHECK as well and in the end
came to the conlusion that it should be deactivated as it is much too
strict. It might be good for internal testing with nicely conditioned
matrices but users can not guarantee that.

On 26.10.2014 02:54, tidswell wrote:

> Thank you Nasos.
>
> The bug Nasos identified crept in when I tried to extract a suitable
> sample for posting.
>
> But I think I still have a problem:
>  * lu_factorize() is returning 0 (which if I understand API correctly
> means not singular)
>  * if I reenable the type checks then the upper triangular type check
> in lu_substitute() fails.
>     (see my inserted #error in code fragment below)
>
> Is it reasonable for the solution not to be upper triangular when the
> matrix is not singular ?
>
> thanks,
> - JT
>
> template<class M, class E>
>     void lu_substitute (const M &m, matrix_expression<E> &e) {
>         typedef const M const_matrix_type;
>         typedef matrix<typename E::value_type> matrix_type;
>
> #if BOOST_UBLAS_TYPE_CHECK
>         matrix_type cm1 (e);
> #endif
>
>         inplace_solve (m, e, unit_lower_tag ());
>
> #if BOOST_UBLAS_TYPE_CHECK
>         BOOST_UBLAS_CHECK (detail::expression_type_check (prod
> (triangular_adaptor<const_matrix_type, unit_lower> (m), e), cm1),
> internal_logic ());
>         matrix_type cm2 (e);
> #endif
>
>         inplace_solve (m, e, upper_tag ());
>
> #if BOOST_UBLAS_TYPE_CHECK
> #error "This is the check that fails in debug!"
>         BOOST_UBLAS_CHECK (detail::expression_type_check (prod
> (triangular_adaptor<const_matrix_type, upper> (m), e), cm2),
> internal_logic ());
> #endif
>     }
>
>
> On 21/10/14 02:01, Nasos Iliopoulos wrote:
>> jT,
>> try this:
>> change line:
>> std::copy( &(input_data[0][0]), &(input_data[matSize-1][matSize-1]),
>> data.begin() );
>>
>> to:
>> std::copy( &(input_data[0][0]), &(input_data[matSize-1][matSize-1]) +
>> ptrdiff_t(1), data.begin() );
>>
>> (The last iterator should be one past the last element)
>>
>> You might get another response that was sent prior to this and has
>> some further valid points you may want to keep in mind.
>>
>> -Nasos
>>
>> On 10/20/2014 07:53 AM, tidswell wrote:
>>>
>>> Folx,
>>> ublas is not my specialty, so apologies if Ive done something silly,
>>> but as I get different results with Debug & Release builds on
>>> identical code, I think there is a problem in ublas's interaction
>>> with Visual Studio 2012.
>>> [There may also be problems in my code, but I think its simple
>>> enough that I expect consistent answers (I view consistently wrong
>>> as better than inconsistent). ]
>>>
>>> MS Windows 7
>>> Visual Studio 2012
>>> Boost 1.55 or 1.52 (I think also earlier, but I didnt go back that
>>> far to test)
>>>
>>> Simple usage of Fredrik Orderud's LU decompisition matrix inversion
>>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LU_Matrix_Inversion 
>>>
>>>
>>> I've disabled _SCL_SECURE_NO_WARNINGS because its not standard C++.
>>>
>>> Ive disabled BOOST_UBLAS_TYPE_CHECK because I wanted to check with
>>> error control flow caused differences.
>>>
>>> Any guidance on why the results are inconsistent ?
>>>
>>> thanks,
>>> - JT
>>>
>>>
>>>
>>> _______________________________________________
>>> ublas mailing list
>>> [hidden email]
>>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>>> Sent to:[hidden email]
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> [hidden email]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to:[hidden email]
>
> _______________________________________________
> ublas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [hidden email]

_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]