[Gsll-devel] feedback on gsll-tests

Liam Healy lhealy at common-lisp.net
Tue Apr 20 19:01:19 UTC 2010


All fixed, see below.

On Tue, Apr 13, 2010 at 11:27 AM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> Hi,
>
> I just installed the latest gsll and gsl (1.14) on
> red-hat/linux/64-bit sbcl 1.0.34 on .  A couple observations on (what
> I think are) minor unit-tests errors and failures.
>
> *** CHOLESKY:
>
> The following error
>
> CHOLESKY: Function CHOLESKY-INVERT (gsl_linalg_cholesky_invert) is not
> available in the
> currently loaded release 1.14 of GSL; it was introduced in release 1.12.
>
> does not make sense since gsl_linalg_cholesky_invert is present in
> gsl1.14 (http://www.gnu.org/software/gsl/manual/html_node/Cholesky-Decomposition.html)
> - admittedly, I did not dig into the c code to verify if the code and
> documentation are out of line

This had me stumped until I figured out what you must have done.  The message
should be clearer now, but will still be there unless you follow the
instructions :-).

>
> *** ELLIPTIC-FUNCTIONS:  failure shows up when doing
> (lisp-unit:run-tests), but not when doing the individual tests:
>
> GSL> (lisp-unit:run-tests)
> ...
> ELLIPTIC-FUNCTIONS: (MULTIPLE-VALUE-LIST
>                     (JACOBIAN-ELLIPTIC-FUNCTIONS 0.2d0 0.81d0)) failed:
> Expected (0.19762082367187703d0 0.9802785369736752d0 0.9840560289645665d0
>          0.0d0 0.0d0 0.0d0)
> but saw (0.19762082367187703d0 0.9802785369736752d0 0.9840560289645665d0
>         0.5000000000000027d0 7.618282373747058d-16 2.5991577338697564d-13)
> ...
>
> GSL> (lisp-unit:run-tests elliptic-functions)
> ELLIPTIC-FUNCTIONS: 2 assertions passed, 0 failed.
>
> Does GSL set-up some of lisp-unit's precision variables *epsilon* or
> *significant-figures*?

Fixed; the problem is that gsl_sf_elljac_e does not provide any error estimates.
As a historical side-note, this is the longest-standing bug in GSLL, because
this is the first function I ported (my original motivation for creating GSLL
was because I needed to compute these functions).  For that reason,
it made it into the documentation with the same erroneous assumption;
that too has been fixed.

>
> *** MATHIEU: failure can be eliminated with lower precision:
>
> GSL> (let ((lisp-unit::*epsilon* 1d-15))
>       (lisp-unit:run-tests mathieu))
> produces two errors, but
>
> GSL> (let ((lisp-unit::*epsilon* 1d-13))
>       (lisp-unit:run-tests elliptic-functions))
> ELLIPTIC-FUNCTIONS: 2 assertions passed, 0 failed.

Fixed Mathieu, see above for elliptic.

>
> *** TDIST
>
> When doing the bulk test run, it produces three failures, two of which
> could be eliminated with slightly higher tolerances:
> TDIST: (MULTIPLE-VALUE-LIST (TDIST-PINV 0.6475836176504334d0 1.0d0)) failed:
> Expected (0.500000000000001d0) but saw (0.5000000000000003d0)
> TDIST: (MULTIPLE-VALUE-LIST (TDIST-QINV 0.3524163823495667d0 1.0d0)) failed:
> Expected (0.5d0) but saw (0.5000000000000002d0)
>
> But these two failures do not show up when doing an individual test
> run (lisp-unit:run-tests tdist)
>
> The one remaining error might be due to the reference data out of order:
>
> Expected ((0.14989366374481017d0 0.6794142879291215d0 -1.615833951108472d0
>           -1.6008862825783456d0 -1.7010935505767397d0
>           -0.04370959749808691d0 0.12761159276595174d0
>           -0.019731218255494867d0 -0.6534666117199732d0
>           0.2035771324523077d0 !!!1.77650300477611d0!!!))
> but saw ((0.14989366374481017d0 0.6794142879291215d0 ***2.3228005857300897d0***
>          -1.615833951108472d0 -1.6008862825783456d0 -1.7010935505767397d0
>          -0.04370959749808691d0 0.12761159276595174d0 -0.019731218255494867d0
>          -0.6534666117199732d0 0.2035771324523077d0))

Fixed by wholesale port of all GSL tdist tests to GSLL; there are 278 of them,
and they should always pass.  The old tests have been eliminated.

Most of the tests in GSLL are ones I made
up.  After I discovered that GSL has its own tests (including tolerances)
I've just ported those.  So it's not worth trying to fix my tests;
it's better to
use GSL's.  The downside is that it's a fair amount of work, but I think
I have a way to make it go faster.  I'm still showing some failures on gamma,
levy, and exponential, so those will be my next priority.

Liam




More information about the gsll-devel mailing list