From: Rafael L. <ra...@la...> - 2012-09-07 11:37:25
|
* Lukas Reichlin <luk...@gm...> [2012-09-03 12:03]: > On 03.09.2012, at 10:39, Rafael Laboissiere <ra...@la...> wrote: > > > * Rafael Laboissiere <ra...@la...> [2012-08-30 23:47]: > > > >> * Carnë Draug <car...@gm...> [2012-08-27 16:43]: > >> > >>> a new release of control package is out, version 2.3.53, by Lukas Reichlin. > >> > >> In exercising the tests in inst/@lti/minreal.m, I got the error below. > >> Is it normal? > >> > >> I am running octave 3.6.2 on a Debian unstable system. > >> > >> [snip] > > > > Testing ltimodels and bstmodred also yield errors, cf below. > > > > [snip] > > You can check whether the observed and expected results are equivalent > state-space models (i.e. state-transformation, see command prescale for > formulae). This can be done, e.g., by inspection of the Hankel singular > values (command hsvd), time response (step, impulse) or frequency > response (sigma). > > If they are the same, there should be nothing to worry about. If you > want the same results, use Reference BLAS (and LAPACK) from > www.netlib.org instead of ATLAS which you are probably using. The > SLICOT authors recommend the use of the reference implementations. > Correct results are more important than minor speed advantages of > automatically tuned linear algebra software, aren't they? :-) I built the control package on my Debian system with libblas-dev installed and libatlas3-base, libatlas-dev, libopenblas-base, and libopenblas-dev removed. I still get the same errors in the unit testings. Here is the build log of the Debian package octave-control (version 2.3.53-1) with the same errors: https://buildd.debian.org/status/fetch.php?pkg=octave-control&arch=i386&ver=2.3.53-1&stamp=1346708061 It seems that using the Reference BLAS is not enough for getting rid of the problem. Rafael |