[ublas] 1.33 regressions in test4 and test5
I don't know who (if anyone?) is maintaining ublas at present, but test4 and test5 are failing *on every single compiler* at present. I've partly traced the problem: an exception is being thrown in banded.hpp line 192, in : boost::numeric::ublas::banded_matrix<double,boost::numeric::ublas::basic_row_major<unsigned int,int>,boost::numeric::ublas::unbounded_array<double,std::allocator<double>
::operator()(unsigned int i=0x00000000, unsigned int j=0x00000001) Line 192 + 0x34 C++
The cause is that the member data member _upper has been initialised to zero, which means any attempt here to access members of the matrix results in an exception being thrown! At present I'm stumped, I haven't been able to figure out what the code is supposed to do well enough to even begin to suggest a fix, so I'm just hoping this will ring a bell with someone, who'll know what to do :-) Regards, John.
At 03:17 2005-05-07, John Maddock wrote:
I don't know who (if anyone?) is maintaining ublas at present, but test4 and test5 are failing *on every single compiler* at present.
I've partly traced the problem: an exception is being thrown in banded.hpp line 192, in :
boost::numeric::ublas::banded_matrix<double,boost::numeric::ublas::basic_row_major<unsigned int,int>,boost::numeric::ublas::unbounded_array<double,std::allocator<double>
::operator()(unsigned int i=0x00000000, unsigned int j=0x00000001) Line 192 + 0x34 C++
The cause is that the member data member _upper has been initialised to zero, which means any attempt here to access members of the matrix results in an exception being thrown!
At present I'm stumped, I haven't been able to figure out what the code is supposed to do well enough to even begin to suggest a fix, so I'm just hoping this will ring a bell with someone, who'll know what to do :-)
I should have caught up on my mail before I dove back into looking at test results. I'd just discovered what you say about an hour ago and have been debugging the test to see if I could see where it should logically be different. I'm not even sure I know what lower_, upper_, and size_ are supposed to be for, or where/when things get allocated (if they do) when one accesses something outside the current bounds.
Regards,
John.
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
I should have caught up on my mail before I dove back into looking at test results. I'd just discovered what you say about an hour ago and have been debugging the test to see if I could see where it should logically be different. I'm not even sure I know what lower_, upper_, and size_ are supposed to be for, or where/when things get allocated (if they do) when one accesses something outside the current bounds.
Neither do I. I've had a reply from Michael Stevens (below) that indicates that the problem is basically unfixable, and has always been present: so at present no-ones too sure what to do about it :-( It's not helped by the fact that ublas's original authors are no longer around, so maintenance has basically been left to those users who care about the library, and probably have better things to do anyway... John. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks for putting all the effort looking into the problem. The problem has actually been present for a very long time. Actually it has been there for several releases. Just that previously (the last 2 years) the test code specifically disabled the testing of 'matrix_slice' proxies in test4 and test5 to avoid the error!!! After Boost 1.32.0 was out I made sure all such test 'fudge' code was disabled so we could see the true state of affairs. The test4 and test5 failures are not really regressions. Similarly the failure with VC8 in test2 is I believe due to a bug in VC7 onwards that was specifically worked around before. Fixing the bug with 'matrix_slice' proxies is very hard. The problem only occurs with packed matrices and is due to the design of 'matrix_slice'. Sadly a version that may work would probably be less efficient. Before 1.33.0 is release we need to decide where to fudge the tests again. No user has yet found it a problem in practice! Regards, Michael
participants (2)
-
John Maddock -
Victor A. Wagner Jr.