On Ubuntu Precise (haven't tested on stable version), test_discrete.py fails, causing a build failure.
Simply bumping TestProbitCG's maxiter value from 250 to 500 fixes it. 500 matches the same iters that TestProbitNM is afforded, so it doesn't seem unreasonable.
TST: Bump maxiter in TestProbitCG. Closes #109.
I am using the latest build as of 19/12/2012:
TestProbitCG is failing again, even though I can confirm that maxiter is set to 500.
Traceback (most recent call last):
File "/home/woodri/build/out/lib/python2.7/site-packages/nose/case.py", line 187, in runTest
File "/home/woodri/build/out/lib/python2.7/site-packages/statsmodels-0.5.0-py2.7-linux-x86_64.egg/statsmodels/discrete/tests/test_discrete.py", line 46, in test_conf_int
assert_almost_equal(self.res1.conf_int(), self.res2.conf_int, DECIMAL_4)
File "/home/woodri/build/out/lib/python2.7/site-packages/numpy/testing/utils.py", line 452, in assert_almost_equal
return assert_array_almost_equal(actual, desired, decimal, err_msg)
File "/home/woodri/build/out/lib/python2.7/site-packages/numpy/testing/utils.py", line 800, in assert_array_almost_equal
header=('Arrays are not almost equal to %d decimals' % decimal))
File "/home/woodri/build/out/lib/python2.7/site-packages/numpy/testing/utils.py", line 636, in assert_array_compare
Arrays are not almost equal to 4 decimals
x: array([[ 0.26584602, 2.98583433],
[ -0.11269245, 0.21615338],
[ 0.26008598, 2.5926075 ],
y: array([[ 0.2658255, 2.985795 ],
[ -0.1126929, 0.2161508],
[ 0.2600795, 2.592585 ],
[-12.43547 , -2.469166 ]])
which scipy and numpy versions are you using?
Since this tests is skipped on Windows, maybe there are more serious problems with fmin_cg and we should rethink what to do with this test.
One change that might have affected this is that we are now renormalizing the likelihood function by 1/nobs for the optimization.
can you try to lower gtol to gtol=1e-8 and run the tests?
It looks like there is still a version issue.
This test doesn't fail on Travis-CI nor in the pythonxy Ubuntu tests https://code.launchpad.net/~pythonxy/+recipe/statsmodels-daily-current
Linux xldn5103pap 2.6.18-194.11.4.el5 #1 SMP Fri Sep 17 04:57:05 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Changing gtol=1e-8 fixed the tests:
Ran 1857 tests in 244.987s
Good, lowering gtol compensates for the normalization, and requires roughly the same precision as before.
I just saw the failure also on
correction: that builds statsmodels_0.4.2-1
There shouldn't be a failure with that. ?
Would this fail in master? Should we focus on getting a release out? Features / clean up / PR review is a neverending job...
Yes, it's still on current master, just lowering the gtol should be enough.
I wasn't set up for changing master at the time and had forgotten about it.
I can start in 2 weeks with release preparation, then I have hopefully larger time blocks available.
I want to go through the errors in
I saw several bugs in the code (in untested code paths) where I would also like to check why they are not tested.
TST: TestProbitCG: increase optimization precision, closes #109
test failure on Windows 64bit MingW binaries
maxiter is too low, needs 766 iterations instead of less than maxiter=500, but then the result has atol 1e-6 instead of 4 decimals as in test suite.
looks like fmin_cg needs larger maxiter
see new issue #1690
fixed again in PR #1699 and test failures on some machines in PR #1766
Unit tests are just working around the problems in scipy's fmin_cg.
Problems in using fmin_cg in "not nice" cases still persist. Just make the estimation problem "nice".