On 05.06.2012, at 11:35, marco atzeri wrote: > On 6/5/2012 11:06 AM, Lukas Reichlin wrote: >> On 05.06.2012, at 10:28, marco atzeri wrote: >> >>> On 6/5/2012 7:16 AM, Lukas Reichlin wrote: >>> >>>> >>>> Marco, Alexander >>>> >>>> Could it be that you are using BLAS from ATLAS and LAPACK from Reference >>>> LAPACK 3.4.1? >>>> What I meant was using no ATLAS at all (and no Accelerate/Veclib). There >>>> is a BLAS included in Reference LAPACK 3.4.1. You have to specify "make >>>> blaslib" as it is not included in "all:" of the Top Level Makefile for >>>> LAPACK. >>>> >>>> Regards, >>>> Lukas >>>> >>>> >>> >>> Lukas, >>> it is was a pure lapack + blas reference from 3.4.1 . >>> >>> As cygwin package maintainer for Octave and Lapack (and something more) >>> I am pretty sure of the blas implementation. >>> >>> Please find attached the diary for the two cases: >>> >>> atlas-3.9.72 fails 3 tests >>> blas/lapack-3.4.1 fails 2 tests. >>> >>> >>> Regards >>> Marco >>> <diary_atlas_3.9.72><diary_lapack_3.4.1> >> >> Marco, could you please run the tests from test_control separately? For >> example >> test @lti/feedback >> test hnamodred >> Otherwise it's quite hard for me to figure out which test was failing. To >> make it easy for you, just copy-paste the block [1] below to the terminal. >> >> Regards, >> Lukas >> >> >> [1] test_control.m >> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/control/inst/test_control.m?revision=10558&view=markup >> >> ## test collection >> test ltimodels >> >> ## LTI methods >> test @lti/c2d >> test @lti/d2c >> test @lti/feedback >> test @lti/horzcat >> test @lti/inv >> test @lti/minreal >> test @lti/mtimes >> test @lti/norm >> test @lti/plus >> test @lti/prescale >> test @lti/sminreal >> test @lti/zero >> >> ## robust control >> test h2syn >> test hinfsyn >> test ncfsyn >> >> ## ARE solvers >> test care >> test dare >> test kalman >> >> ## Lyapunov >> test covar >> test dlyap >> ## test dlyapchol # TODO: add tests >> test gram >> test lyap >> test lyapchol >> >> ## model order reduction >> test bstmodred >> test btamodred >> test hnamodred >> ## test spamodred # TODO: create test case >> >> ## controller order reduction >> test btaconred >> test cfconred >> test fwcfconred >> ## test spaconred # TODO: create test case >> >> ## identification >> test fitfrd >> >> ## various oct-files >> test ctrbf >> test hsvd >> test place >> >> ## various m-files >> test ctrb >> test filt >> test initial >> test issample >> test margin >> test obsv >> test sigma >> >> > > echo on should be enough... > > attached > > Regards > Marco > <diary_atlas_3.9.72><diary_lapack_3.4.1>
Hi Marco A few remarks regarding your tests: ** ltimodels I don't know what causes the fail in ltimodels nor whether the results are correct. There are different absolute values, not only sign changes. The failing oct-file is sltg0hd, which is used by isctrb and isstabilizable. Since you don't check controllablity and stabilizability for descriptor (!) state-space models very often, it's not a tragedy. ** @lti/minreal Looks like the usual nasty but harmless sign changes. Again, only descriptor models are affected, regular state-space models are OK. ** bstmodred Sign changes, this time for regular state-space models (descriptor models are not supported here). Now I would like to compare with other people's results. Lukas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
