Some filters will break real-time

[toeklk]

migrated from Bugzilla #479
status ASSIGNED severity blocker in component core for 0.7.0
Reported in version trunk on platform All
Assigned to: BFL mailinglist

Original attachment names and IDs:

• EKparticlefilter.patch (ID 183)
• EKparticlefilter.patch (ID 184)
• kalmanfilter.patch (ID 187)
• extendedkalmanfilter.patch (ID 188)
• iteratedextendedkalmanfilter.patch (ID 189)
• SRiteratedextendedkalmanfilter.patch (ID 190)
• histogramfilter.patch (ID 191)
• particlefilter.patch (ID 193)
• conditionalgaussian.patch (ID 194)
• discreteconditionalpdf.patch (ID 195)
• gaussian.patch (ID 196)
• linearanalyticconditionalgaussian.patch (ID 197)
• uniform.patch (ID 199)
• rauchtungstriebel.patch (ID 200)
• mcpdf.patch (ID 204)
• gaussian.patch (ID 205)
• kalmanfilter.patch (ID 207)
• mcpdf.cpp (ID 212)
• mcpdf.patch (ID 215)
• EKparticlefilter.patch (ID 219)
• extendedkalmanfilter.patch (ID 226)
• iteratedextendedkalmanfilter.patch (ID 227)
• uniform.patch (ID 228)
• gaussian.patch (ID 376)
• matrix_LTI.patch (ID 426)

On 2008-01-07 16:46:39 +0100, Klaas Gadeyne wrote:

  HistogramFilter::SysUpdate(SystemModel()* const sysmodel, const intampersand u) { [...] vector() old_prob = ( (DiscretePdf*)_post )->ProbabilitiesGet(); vector() new_prob(num_states); [...] } If I'm not mistaken, this will lead to allocations on the heap and make the historgram filter unsuited for use in real-time applications. I noticed similar code in the MeasUpdate function of HistogramFilter and the KalmanFilter code also seems to suffer from a similar issue: void KalmanFilter::CalculateSysUpdate(ColumnVector J, Matrix F, SymmetricMatrix Q) { [...] Matrix temp = F * (Matrix)_post->CovarianceGet() * F.transpose() + (Matrix)Q; SymmetricMatrix Sigma_new(_post->DimensionGet()); [...] } Idem dito for the IEKF code and the SRIEKF. Particle Filter code seems to be fine. I guess people@PMA should have noticed this when using this filters under LXRT? Damned, I should have noticed this long ago :-(

On 2008-01-08 19:36:31 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 0) > HistogramFilter::SysUpdate(SystemModel()* const sysmodel, const intampersand u) > { > [...] > vector() old_prob = ( (DiscretePdf*)_post )->ProbabilitiesGet(); > vector() new_prob(num_states); > [...] > } > > If I'm not mistaken, this will lead to allocations on the heap and make the > historgram filter unsuited for use in real-time applications. It appears I am not mistaken. Consider the following example [kgad@ampere /tmp]$ cat main.cpp #include ampersandlt;vectorampersandgt; #define NUM_TRIES 10 #define SIZE 1000 int main() { for (int i=0; i ampersandlt; NUM_TRIES; i++) { std::vector() a(SIZE,1.0); std::vector() b = a; } return 0; } [kgad@ampere /tmp]$ cat main_efficient.cpp #include ampersandlt;vectorampersandgt; #define NUM_TRIES 10 #define SIZE 1000 int main() { std::vector() a(SIZE,1.0); std::vector() b(SIZE); for (int i=0; i ampersandlt; NUM_TRIES; i++) { b[1]=2.0; b=a; } return 0; } When performing some heap profiling action using valgrind's massif tool on these executables, e.g. valgrind --tool=massif --time-unit=B ./a.out and then print some result using ms_print, we get the following chart for the "naive" implementation KB 15.64^ # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | # : : : : @ : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : | : # : :: : : :: : : : : : : : @ : :: : : :: : : : : : : 0 +----------------------------------------------------------------------->KB 0 312.8 You can consider the x-axis to be some kind of "time", and the y-axis the heap size. You can see very nicely that the allocation happens every time in the for loop (10 times). the following plot is produced for the "efficient" main KB 15.64^ # | # | # | # | # | # | # | # | # | # | : # : | : # : | : # : | : # : | : # : | : # : | : # : | : # : | : # : | : # : 0 +----------------------------------------------------------------------->KB 0 31.28 [I hope bugzilla doesn't mangle this ascii art...] Increasing the defines in both programs also shows the performancy decrease. regards, Klaas Ps. Unfortunately, AFAIK valgrind does not yet work for xenomai or lxrt :-(

On 2008-01-09 17:14:33 +0100, Tinne De Laet wrote:

  I accept this bug, but any help is welcome of course. I will propose patches for all filters/pdf seperately to prevent an unreadable patch-file. Tinne

On 2008-01-09 17:20:36 +0100, Tinne De Laet wrote:

  Created attachment 183 Patch to solve allocation issues for EKparticlefilter

On 2008-01-09 17:42:52 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 3) > Created an attachment (id=183) [details] > Patch to solve allocation issues for EKparticlefilter Source code wise, I think this solves some issues, but not all of them. Since this is a particle filter involving a KF step, I think you should also _preallocate_ the matrices, and not only the lists, e.g. in the constructor instead of just doing _sampleCov.resize(prior->NumSamplesGet()); you should add something like (note: this is only pseudo code) _cov_it = _sampleCov.begin(); while (_cov_it != _sampleCov.end()) { (*_cov_it).resize(this->StateSizeGet()); } For the rest, this seems fine. However, when running make check, I get a nasty error *** glibc detected *** /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter: corrupted double-linked list: 0x080c5bb8 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6[0x40340df9] /lib/i686/cmov/libc.so.6[0x4034253e] /lib/i686/cmov/libc.so.6(cfree+0x90)[0x403461a0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x40271e41] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZN9__gnu_cxx13new_allocatorIN3BFL14WeightedSampleIN13MatrixWrapper12ColumnVectorEEEE10deallocateEPS5_j+0x11)[0x8062927] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZNSt12_Vector_baseIN3BFL14WeightedSampleIN13MatrixWrapper12ColumnVectorEEESaIS4_EE13_M_deallocateEPS4_j+0x27)[0x8062951] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZNSt12_Vector_baseIN3BFL14WeightedSampleIN13MatrixWrapper12ColumnVectorEEESaIS4_EED2Ev+0x36)[0x806298a] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZNSt6vectorIN3BFL14WeightedSampleIN13MatrixWrapper12ColumnVectorEEESaIS4_EED1Ev+0x5b)[0x8062d9d] /home/kgad/SVN/bfl-trunk/build-boost/src/liborocos-bfl.so(_ZN3BFL16EKParticleFilterD0Ev+0x117)[0x4012551b] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZN19Complete_FilterTest29testComplete_FilterValue_ContEv+0x21d2)[0x805fcba] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZN7CppUnit10TestCallerI19Complete_FilterTestE7runTestEv+0x55)[0x806192d] /usr/lib/libcppunit-1.12.so.0(_ZNK7CppUnit21TestCaseMethodFunctorclEv+0x29)[0x40195e49] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit16DefaultProtector7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x2e)[0x4018742e] /usr/lib/libcppunit-1.12.so.0(_ZNK7CppUnit14ProtectorChain14ProtectFunctorclEv+0x23)[0x40191a43] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit14ProtectorChain7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x1d4)[0x40191764] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit10TestResult7protectERKNS_7FunctorEPNS_4TestERKSs+0x51)[0x4019e2b1] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit8TestCase3runEPNS_10TestResultE+0x10d)[0x40195b4d] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit13TestComposite15doRunChildTestsEPNS_10TestResultE+0x3d)[0x401964bd] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit13TestComposite3runEPNS_10TestResultE+0x2a)[0x401963ea] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit13TestComposite15doRunChildTestsEPNS_10TestResultE+0x3d)[0x401964bd] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit13TestComposite3runEPNS_10TestResultE+0x2a)[0x401963ea] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit10TestRunner13WrappingSuite3runEPNS_10TestResultE+0x40)[0x401a0960] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit10TestResult7runTestEPNS_4TestE+0x2a)[0x4019e04a] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit10TestRunner3runERNS_10TestResultERKSs+0x50)[0x401a07a0] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit14TextTestRunner3runERNS_10TestResultERKSs+0x2b)[0x401a3f7b] /usr/lib/libcppunit-1.12.so.0(_ZN7CppUnit14TextTestRunner3runESsbbb+0x62)[0x401a3ff2] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(main+0x1f2)[0x805c442] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x402ed450] /home/kgad/SVN/bfl-trunk/build-boost/tests/test_complete_filter(_ZNK7CppUnit4Test12findTestPathEPKS0_RN

On 2008-01-10 11:04:04 +0100, Tinne De Laet wrote:

  Created attachment 184 Patch to solve allocation issues for EKparticlefilter - bis > Source code wise, I think this solves some issues, but not all of them. > Since this is a particle filter involving a KF step, I think you should > also _preallocate_ the matrices, and not only the lists, e.g. in the > constructor instead of just > doing > > _sampleCov.resize(prior->NumSamplesGet()); > > you should add something like (note: this is only pseudo code) > > _cov_it = _sampleCov.begin(); > while (_cov_it != _sampleCov.end()) > { > (*_cov_it).resize(this->StateSizeGet()); > } > Ack, I think the new patch also preallocates the matrices,... but using the assign function in stead of iterating over the list. Tinne

On 2008-01-10 14:04:33 +0100, Tinne De Laet wrote:

  Created attachment 187 Patch to solve allocation issues for kalmanfilter ... notice the work-around-solution for initializing some of the variables needed in measupdate. Tinne

On 2008-01-10 14:10:15 +0100, Tinne De Laet wrote:

  Created attachment 188 Patch to solve allocation issues for extendedKalmanFilter same remark as with kalmanfilter-patch

On 2008-01-10 14:11:40 +0100, Tinne De Laet wrote:

  Created attachment 189 Patch to solve allocation issues for itereatedExtendedKalmanFilter ... same remark as with kalmanfilter

On 2008-01-10 14:13:01 +0100, Tinne De Laet wrote:

  Created attachment 190 Patch to solve allocation issues for SRitereatedExtendedKalmanFilter ... same remark as with kalmanfilter

On 2008-01-10 14:17:56 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 5) > Created an attachment (id=184) [details] > Patch to solve allocation issues for EKparticlefilter - bis Patch seems ok (2 minor issues, (i) a small and minor indentation thingie, and (ii) by adding the delete statement in the destructor, I guess your fixing another bug, but "who cares" :-) > Ack, I think the new patch also preallocates the matrices,... but using the > assign function in stead of iterating over the list. Excellent. Apart from the above, I still think we have to figure out a way of automagically detecting these kind of errors in the unit testing (or at least somewhere else) Now we actually _think_ the bug is fixed, and we need to investigate valgrind traces in order to be sure, which is not a good thing. Klaas

On 2008-01-10 14:22:11 +0100, Tinne De Laet wrote:

  Created attachment 191 Patch to solve allocation issues for histogramfilter

On 2008-01-10 14:59:17 +0100, Tinne De Laet wrote:

  Created attachment 193 Patch to solve allocation issues for particlefilter

On 2008-01-10 17:34:05 +0100, Tinne De Laet wrote:

  A small question: To obtain real-timeness I think I should change some things to the function sampleFrom (pdf.h ...) 84 virtual bool SampleFrom (vector(Sample(T) )ampersand list_samples, 85 const unsigned int num_samples, 86 int method = DEFAULT, 87 void * args = NULL) const; In the implementation in for instance gaussian.cpp, the list_samples is first resized to num_samples which breaks the real-timeness. Could I add a precondition (and an assert) to make sure that the list_samples already has the correct size? Or do you see another, more suitable, solution. Tinne

On 2008-01-10 17:50:40 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 13) > A small question: > > To obtain real-timeness > I think I should change some things to the function sampleFrom (pdf.h ...) > 84 virtual bool SampleFrom (vector(Sample(T) )ampersand list_samples, > 85 const unsigned int num_samples, > 86 int method = DEFAULT, > 87 void * args = NULL) const; > In the implementation in for instance gaussian.cpp, the list_samples is first > resized to num_samples which breaks the real-timeness. > Could I add a precondition (and an assert) to make sure that the list_samples > already has the correct size? If I understand it correctly, the resize operation only breaks realtime if list_samples.size() != num_samples If not, the resize() operation does not break real-time. So the user of this function _can_ have real-time evaluation if he wants to. IMO, what should be done is adding a warning to the API documentation of Pdf about this. This should allow people creating BFL filters meant for real-time use obtaining real-time behavior, but it should not hinder people that are not interested in real-time behavior of writing simple applications like gaussian g(mu,sigma) vector(Sample(ColumnVector) ) v; g.samplefrom(v,100); The BFL logger (which does currently not exist, and whom [?] I'd like to share with the other Orocos subprojects (hence, reusing the RTT logger) could then print a warning about the real-timeness. Klaas

On 2008-01-10 18:43:58 +0100, Tinne De Laet wrote:

  Any suggestions how to get the sampleFrom(list ) in discretepdf realtime? The rescaling of the uniform samples is causing my difficulties.

On 2008-01-10 18:45:56 +0100, Tinne De Laet wrote:

  Created attachment 194 Patch to solve allocation issues for conditionalgaussian

On 2008-01-10 18:46:24 +0100, Tinne De Laet wrote:

  Created attachment 195 Patch to solve allocation issues for discreteconditionalpdf

On 2008-01-10 18:46:56 +0100, Tinne De Laet wrote:

  Created attachment 196 Patch to solve allocation issues for gaussian

On 2008-01-10 18:47:29 +0100, Tinne De Laet wrote:

  Created attachment 197 Patch to solve allocation issues for linearanalyticconditionalgaussian

On 2008-01-11 10:20:10 +0100, Tinne De Laet wrote:

  Created attachment 199 Patch to solve allocation issues for uniform

On 2008-01-11 10:20:48 +0100, Tinne De Laet wrote:

  Created attachment 200 Patch to solve allocation issues for rauchtungstriebel

On 2008-01-11 14:48:30 +0100, Tinne De Laet wrote:

  Created attachment 204 Patch to solve allocation issues for mcpdf

On 2008-01-11 16:31:31 +0100, Tinne De Laet wrote:

  Created attachment 205 Patch to solve allocation issues for gaussian - bis

On 2008-01-11 20:04:56 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 6) > Created an attachment (id=187) [details] > Patch to solve allocation issues for kalmanfilter > > ... > notice the work-around-solution for initializing some of the variables needed > in measupdate. The calculatesysupdate and calculatemeasupdate functions should use references for passing the matrix arguments, otherwise the local copies will also result in allocations. So I think you need function references like void CalculateMeasUpdate(const ColumnVector ampersand z, const ColumnVector ampersand Z, const Matrix ampersand H, const SymmetricMatrix ampersand R) etc. Concerning the workaround: suppose you have a system with measurements from 2 sources which generate measurements approximately randomly, in that case, you will allocate each time. What about turning _S and _K as a vectors of ColumnVectors/Matrices, which you can initialize using an allocateMeasModel function?

On 2008-01-13 19:57:50 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 24) > (In reply to comment # 6) > > Created an attachment (id=187) [details] [details] > > Patch to solve allocation issues for kalmanfilter > > > > ... > > notice the work-around-solution for initializing some of the variables needed > > in measupdate. > > The calculatesysupdate and calculatemeasupdate functions should use references > for passing the matrix arguments, otherwise the local copies will also result > in allocations. > So I think you need function references like > > void CalculateMeasUpdate(const ColumnVector ampersand z, const ColumnVector ampersand Z, const > Matrix ampersand H, const SymmetricMatrix ampersand R) > > etc. > > Concerning the workaround: suppose you have a system with measurements from 2 > sources which generate measurements approximately randomly, in that case, you > will allocate each time. > > What about turning _S and _K as a vectors of ColumnVectors/Matrices, which you > can initialize using an allocateMeasModel function? While trying to do a 5 minute implementation of the above, I discovered we would need something like stl::hash_set() in order to implement this efficient (i.e. make the lookup of which vectors to use very fast)

On 2008-01-16 14:28:34 +0100, Tinne De Laet wrote:

  Created attachment 207 Patch to solve allocation issues for kalmanfilter - bis (In reply to comment # 24 and # 25) > The calculatesysupdate and calculatemeasupdate functions should use references > for passing the matrix arguments, otherwise the local copies will also result > in allocations. > So I think you need function references like > > void CalculateMeasUpdate(const ColumnVector ampersand z, const ColumnVector ampersand Z, const > Matrix ampersand H, const SymmetricMatrix ampersand R) > > etc. Ok. > Concerning the workaround: suppose you have a system with measurements from 2 > sources which generate measurements approximately randomly, in that case, you > will allocate each time. > > What about turning _S and _K as a vectors of ColumnVectors/Matrices, which you > can initialize using an allocateMeasModel function? > While trying to do a 5 minute implementation of the above, I discovered we > would need something like stl::hash_set() in order to implement this efficient > (i.e. make the lookup of which vectors to use very fast) I used a map to implement the behavior you suggested. Furthermore I made a struct of variables which need to be allocated during the call of MeasUpdate. Tinne

On 2008-01-18 16:37:47 +0100, Tinne De Laet wrote:

  Created attachment 212 Solves issue explained in bug # 497

On 2008-01-18 19:30:53 +0100, Tinne De Laet wrote:

  Created attachment 215 Solves issue explained in bug # 497, this time with a patch an not just the mcpdf

On 2008-01-19 17:46:14 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 17) > Created an attachment (id=195) [details] > Patch to solve allocation issues for discreteconditionalpdf patch ok, although these constructions - int DiscreteConditionalPdf::IndexGet(int input, - std::vector() condargs) const + int DiscreteConditionalPdf::IndexGet(const intampersand input, + const std::vector()ampersand condargs) const are somewhat unnecessary, since the copy will be on the stack.

On 2008-01-19 17:52:37 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 11) > Created an attachment (id=191) [details] > Patch to solve allocation issues for histogramfilter Patch ok

On 2008-01-19 18:05:18 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 12) > Created an attachment (id=193) [details] > Patch to solve allocation issues for particlefilter apart from some whitespace cluttering, patch seems ok. Klaas

On 2008-01-19 18:26:40 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 16) > Created an attachment (id=194) [details] > Patch to solve allocation issues for conditionalgaussian Patch seems ok

On 2008-01-19 18:33:43 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 19) > Created an attachment (id=197) [details] > Patch to solve allocation issues for linearanalyticconditionalgaussian patch seems ok (again :-)

On 2008-01-19 18:41:42 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 20) > Created an attachment (id=199) [details] > Patch to solve allocation issues for uniform this patch is ok, but it seems that there is an unused (and unnecessary) variable _rit defined in the header file. some minor remark (I've seen this in a couple of the patches). Don't add doxygen style comment for the helper variables (they should be hidden for the user)

On 2008-01-21 09:05:26 +0100, Tinne De Laet wrote:

  Created attachment 219 Patch to solve allocation issues for EKparticlefilter - bis2 Final patch for EKparticlefilter. (?)

On 2008-01-21 09:06:36 +0100, Tinne De Laet wrote:

  (In reply to comment # 35) > Created an attachment (id=219) [details] > Patch to solve allocation issues for EKparticlefilter - bis2 > > Final patch for EKparticlefilter. (?) > Patch applied in revision 28848: Sending filter/EKparticlefilter.cpp Sending filter/EKparticlefilter.h Transmitting file data .. Committed revision 28848.

On 2008-01-23 08:44:00 +0100, Tinne De Laet wrote:

  Created attachment 226 Patch to solve allocation issues for extendedKalmanFilter - bis This patch also adds a map to the extendedKalmanFilter to allocate memory needed during the measurement updat (see comment # 24, # 25, # 26) Tinne

On 2008-01-23 09:49:02 +0100, Tinne De Laet wrote:

  Created attachment 227 Patch to solve allocation issues for iteratedextendedKalmanFilter - bis This patch also adds a map to the iteratedExtendedKalmanFilter to allocate memory needed during the measurement update (see comment # 24, # 25, # 26) Tinne

On 2008-01-23 10:52:18 +0100, Tinne De Laet wrote:

  (In reply to comment # 30) > (In reply to comment # 11) > > Created an attachment (id=191) [details] [details] > > Patch to solve allocation issues for histogramfilter > > Patch ok > Patch (attachement # 191) applied in revision 28868. Sending histogramfilter.cpp Sending histogramfilter.h Transmitting file data .. Committed revision 28868.

On 2008-01-23 11:01:50 +0100, Tinne De Laet wrote:

  > (In reply to comment # 12) > > Created an attachment (id=193) [details] [details] > > Patch to solve allocation issues for particlefilter > > apart from some whitespace cluttering, patch seems ok. Patch (attachment (id=193)) applied in revision 28869: Sending particlefilter.cpp Sending particlefilter.h Transmitting file data .. Committed revision 28869 Tinne

On 2008-01-23 11:12:55 +0100, Tinne De Laet wrote:

  (In reply to comment # 32) > (In reply to comment # 16) > > Created an attachment (id=194) [details] [details] > > Patch to solve allocation issues for conditionalgaussian > > Patch seems ok > Patch (attachment (id=194)) applied in revision 28870. Sending conditionalgaussian.cpp Sending conditionalgaussian.h Transmitting file data .. Committed revision 28870. Tinne

On 2008-01-23 11:23:25 +0100, Tinne De Laet wrote:

  (In reply to comment # 29) > (In reply to comment # 17) > > Created an attachment (id=195) [details] [details] > > Patch to solve allocation issues for discreteconditionalpdf > > patch ok, although these constructions > - int DiscreteConditionalPdf::IndexGet(int input, > - std::vector() condargs) const > + int DiscreteConditionalPdf::IndexGet(const intampersand input, > + const std::vector()ampersand condargs) const > > are somewhat unnecessary, since the copy will be on the stack. > Patch (attachment (id=195)) applied in revision 28871: Sending pdf/discreteconditionalpdf.cpp Sending pdf/discreteconditionalpdf.h Transmitting file data .. Committed revision 28871. Tinne

On 2008-01-23 11:29:15 +0100, Tinne De Laet wrote:

  (In reply to comment # 23) > Created an attachment (id=205) [details] > Patch to solve allocation issues for gaussian - bis > Patch (attachment (id=205)) applied in revision Sending gaussian.cpp Sending gaussian.h Transmitting file data .. Committed revision 28872.

On 2008-01-23 11:36:29 +0100, Tinne De Laet wrote:

  (In reply to comment # 33) > (In reply to comment # 19) > > Created an attachment (id=197) [details] [details] > > Patch to solve allocation issues for linearanalyticconditionalgaussian > > patch seems ok (again :-) > Patch (attachment (id=197)) applied in revision 28873: Sending linearanalyticconditionalgaussian.cpp Sending linearanalyticconditionalgaussian.h Transmitting file data .. Committed revision 28873. Tinne

On 2008-01-23 11:42:02 +0100, Tinne De Laet wrote:

  Created attachment 228 Patch to solve allocation issues for uniform - bis (In reply to comment # 24) > > Created an attachment (id=199) [details] [details] > > Patch to solve allocation issues for uniform > this patch is ok, but it seems that there is an unused (and unnecessary) > variable _rit defined in the header file. > some minor remark (I've seen this in a couple of the patches). Don't add > doxygen style comment for the helper variables (they should be hidden for > the user) Your suggestions are applied in the new patch. tinne

On 2008-01-23 11:43:28 +0100, Tinne De Laet wrote:

  (In reply to comment # 45) > Created an attachment (id=228) [details] > Patch to solve allocation issues for uniform - bis the user) > > Your suggestions are applied in the new patch. Patch (attachment (id=228)) applied in revision 28874: Sending uniform.cpp Sending uniform.h Transmitting file data .. Committed revision 28874. Tinne

On 2008-01-23 15:26:08 +0100, Tinne De Laet wrote:

  (In reply to comment # 21) > Created an attachment (id=200) [details] > Patch to solve allocation issues for rauchtungstriebel > Patch (attachment (id=200)) applied in revision 28875: Sending rauchtungstriebel.cpp Sending rauchtungstriebel.h Transmitting file data .. Committed revision 28875. Tinne

On 2008-01-23 17:19:15 +0100, Tinne De Laet wrote:

  (In reply to comment # 28) > Created an attachment (id=215) [details] > Solves issue explained in bug # 497, this time with a patch an not just the > mcpdf > Patch (attachment (id=215)) applied in revision 28876 Sending mcpdf.cpp Sending mcpdf.h Transmitting file data .. Committed revision 28876. Tinne

On 2008-01-23 17:39:22 +0100, Tinne De Laet wrote:

  > (In reply to comment # 12) > > Created an attachment (id=193) [details] [details] [details] > > Patch to solve allocation issues for particlefilt(In reply to comment # 26) > Created an attachment (id=207) [details] > Patch to solve allocation issues for kalmanfilter - bis [..] Patch (attachment (id=207)) applied in revision 28877: Sending kalmanfilter.cpp Sending kalmanfilter.h Transmitting file data .. Committed revision 28877. Tinne

On 2008-01-23 17:44:29 +0100, Tinne De Laet wrote:

  (In reply to comment # 37) > Created an attachment (id=226) [details] > Patch to solve allocation issues for extendedKalmanFilter - bis > > This patch also adds a map to the extendedKalmanFilter to allocate memory > needed during the measurement updat (see comment # 24, # 25, # 26) Patch applied in revision 28878 Sending extendedkalmanfilter.cpp Sending extendedkalmanfilter.h Transmitting file data .. Committed revision 28878. Tinne

On 2008-01-23 17:47:33 +0100, Tinne De Laet wrote:

  (In reply to comment # 38) > Created an attachment (id=227) [details] > Patch to solve allocation issues for iteratedextendedKalmanFilter - bis > > This patch also adds a map to the iteratedExtendedKalmanFilter to allocate > memory needed during the measurement update (see comment # 24, # 25, # 26) > Patch (attachment (id=227)) applied in revision: Sending filter/iteratedextendedkalmanfilter.cpp Sending filter/iteratedextendedkalmanfilter.h Transmitting file data .. Committed revision 28879 Tinne

On 2008-01-26 00:30:51 +0100, Klaas Gadeyne wrote:

  (In reply to comment # 47) > (In reply to comment # 21) > > Created an attachment (id=200) [details] [details] > > Patch to solve allocation issues for rauchtungstriebel > > > > Patch (attachment (id=200) [details]) applied in revision 28875: > > Sending rauchtungstriebel.cpp > Sending rauchtungstriebel.h > Transmitting file data .. > Committed revision 28875. Patch seems ok (even a posteriori) :-). I think all of them are reviewed and applied now?

On 2009-01-30 16:27:01 +0100, Tinne De Laet wrote:

  Created attachment 376 Removes an extra allocation from gaussian and therefore adds a multiply function to the matrixwrapper

On 2009-01-30 16:29:38 +0100, Tinne De Laet wrote:

  Patch # 376 applied in revision 29884 : svn commit Sending src/pdf/gaussian.cpp Sending src/pdf/gaussian.h Sending src/wrappers/matrix/matrix_BOOST.cpp Sending src/wrappers/matrix/matrix_BOOST.h Sending src/wrappers/matrix/matrix_LTI.cpp Sending src/wrappers/matrix/matrix_LTI.h Sending src/wrappers/matrix/matrix_NEWMAT.cpp Sending src/wrappers/matrix/matrix_NEWMAT.h Sending src/wrappers/matrix/matrix_wrapper.h Transmitting file data ......... Committed revision 29884.

On 2009-05-07 16:58:53 +0200, Klaas Gadeyne wrote:

  (In reply to comment # 54) > Patch # 376 applied in revision 29884 : > svn commit > Sending src/pdf/gaussian.cpp > Sending src/pdf/gaussian.h > Sending src/wrappers/matrix/matrix_BOOST.cpp > Sending src/wrappers/matrix/matrix_BOOST.h > Sending src/wrappers/matrix/matrix_LTI.cpp > Sending src/wrappers/matrix/matrix_LTI.h > Sending src/wrappers/matrix/matrix_NEWMAT.cpp > Sending src/wrappers/matrix/matrix_NEWMAT.h > Sending src/wrappers/matrix/matrix_wrapper.h > Transmitting file data ......... > Committed revision 29884. This last patch seems to break the LTI matrix wrapper, see http://lists.mech.kuleuven.be/pipermail/bfl/2009-May/001156.html

On 2009-05-20 15:11:14 +0200, Tinne De Laet wrote:

  Created attachment 426 solves error reported in Comment # 55

On 2009-05-20 15:13:55 +0200, Tinne De Laet wrote:

  (In reply to comment # 56) > Created an attachment (id=426) [details] > solves error reported in Comment # 55 Patch (attachment (id=426) ) applied in revision 30165 svn commit Sending matrix/matrix_LTI.h Transmitting file data . Committed revision 30165.