Unit test test_gsl.praat fails randomly

[rlaboiss]

The unit test for funtion incompleteGammaP in file dwtest/test_gsl.praat fails randomly:

$ while true ; do xvfb-run -a praat --run dwtest/test_gsl.praat || break ; done
[…]
Error: Script assertion fails in line 64 (false):
   abs((.res-.r)/(.res+.r)) < .tol; 1.1811196938982237e-08=incompleteGammaP (3, 0.004142521544216127) (1.1811196909405908e-08)
Script “/var/data/rlaboiss/debian/PKGS/praat/praat/dwtest/test_gsl.praat” not completed.
Praat: script command <<dwtest/test_gsl.praat>> not completed.

The patch fix-gsl-unit-test.txt fixes the problem. It essentially increases the tolerance by 4 orders of magnitude. It is pretty puzzling why the analytical expression for the incomplete Gamma function gives not precisely the same values of the function in the GSL library. Unfortunately, I do not time for investigating this issue further now.

[davidweenink]

I have to upgrade gsl first. Maybe newer version don't give this error any more.

[rlaboiss]

I tested a version of Praat compiled against the external GSL library version 2.3 and the problem persists. The discrepancy between the results of the GSL-based function incompleteGammaP and the analytical solution (1-(1+x+0.5*x^2)*exp(-x))/2 happens only for small values of .x. When a increase the lower limit of the randomly generated number, for instance .x = randomUniform (0.1, emax), then there is no more random failures.

My guess is that the computations behind (1-(1+x+0.5*x^2)*exp(-x))/2 in the Praat script are not done with the same floating-point precision as the computations in the GSL library.

[rlaboiss]

By the way, you might consider a mechanism for allowing the user to compile Praat against the external GSL library. For now, the only way to do it is by patching the source files. FYI, this is the patch that I applied in order to compile Praat as I described in the previous comment.

[davidweenink]

I modified test_gsl.praat. It doesn't fail anymore.