On Sat, Apr 26, 2014 at 10:10 AM, <josef.pktd@gmail.com> wrote:
On Fri, Apr 25, 2014 at 1:21 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Apr 24, 2014 at 5:26 PM, <josef.pktd@gmail.com> wrote:
On Thu, Apr 24, 2014 at 7:29 PM, <josef.pktd@gmail.com> wrote:
On Thu, Apr 24, 2014 at 7:20 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Apr 24, 2014 at 5:08 PM, <josef.pktd@gmail.com> wrote:
On Thu, Apr 24, 2014 at 7:00 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: > > > Hi Matthew, > > On Thu, Apr 24, 2014 at 3:56 PM, Matthew Brett > <matthew.brett@gmail.com> wrote: >> >> Hi, >> >> Thanks to Cark Kleffner's toolchain and some help from Clint Whaley >> (main author of ATLAS), I've built 64-bit windows numpy and scipy >> wheels for testing. >> >> The build uses Carl's custom mingw-w64 build with static linking. >> >> There are two harmless test failures on scipy (being discussed on
the
>> list at the moment) - tests otherwise clean. >> >> Wheels are here: >> >> >> https://nipy.bic.berkeley.edu/scipy_installers/numpy-1.8.1-cp27-none-win_amd... >> >> https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.13.3-cp27-none-win_am... >> >> You can test with: >> >> pip install -U pip # to upgrade pip to latest >> pip install -f https://nipy.bic.berkeley.edu/scipy_installersnumpy >> scipy >> >> Please do send feedback. >> >> ATLAS binary here: >> >> >> https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-64-full-ss... >> >> Many thanks for Carl in particular for doing all the hard work, >> > > Cool. After all these long years... Now all we need is a box running > tests for CI. > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
I get two test failures with numpy
Josef
>>> np.test() Running unit tests for numpy NumPy version 1.8.1 NumPy is installed in C:\Python27\lib\site-packages\numpy Python version 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] nose version 1.1.2
======================================================================
FAIL: test_iterator.test_iter_broadcasting_errors
Traceback (most recent call last): File "C:\Python27\lib\site-packages\nose\case.py", line 197, in runTest self.test(*self.arg) File "C:\Python27\lib\site-packages\numpy\core\tests\test_iterator.py", line 657, in test_iter_broadcasting_errors '(2)->(2,newaxis)') % msg) File "C:\Python27\lib\site-packages\numpy\testing\utils.py", line 44, in assert_ raise AssertionError(msg) AssertionError: Message "operands could not be broadcast together with remapped shapes [original->remapped]: (2,3)->(2,3) (2,)->(2,newaxis) and requested shape (4,3)" doesn't contain remapped operand shape(2)->(2,newaxis)
======================================================================
FAIL: test_iterator.test_iter_array_cast
Traceback (most recent call last): File "C:\Python27\lib\site-packages\nose\case.py", line 197, in runTest self.test(*self.arg) File "C:\Python27\lib\site-packages\numpy\core\tests\test_iterator.py", line 836, in test_iter_array_cast assert_equal(i.operands[0].strides, (-96,8,-32)) File "C:\Python27\lib\site-packages\numpy\testing\utils.py", line 255, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k, err_msg), verbose) File "C:\Python27\lib\site-packages\numpy\testing\utils.py", line 317, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0
ACTUAL: 96L DESIRED: -96
Ran 4828 tests in 46.306s
FAILED (KNOWNFAIL=10, SKIP=8, failures=2) <nose.result.TextTestResult run=4828 errors=0 failures=2>
Strange. That second one looks familiar, at least the "-96" part. Wonder why this doesn't show up with the MKL builds.
ok tried again, this time deleting the old numpy directories before installing
Ran 4760 tests in 42.124s
OK (KNOWNFAIL=10, SKIP=8) <nose.result.TextTestResult run=4760 errors=0 failures=0>
so pip also seems to be reusing leftover files.
all clear.
Running the statsmodels test suite, I get a failure in test_discrete.TestProbitCG where fmin_cg converges to something that differs in the 3rd decimal.
I usually only test the 32-bit version, so I don't know if this is specific to this scipy version, but we haven't seen this in a long time. I used our nightly binaries http://statsmodels.sourceforge.net/binaries/
That's interesting, you saw also we're getting failures on the tests for powell optimization because of small unit-at-last-place differences in the exp function in mingw-w64. Is there any chance you can track down where the optimization path is diverging and why? It's just that - if this is also the exp function maybe we can see if the error is exceeding reasonable bounds and then feed back to mingw-w64 and fall back to the numpy default implementation in the meantime.
I'm a bit doubtful it's exp, the probit model is based on the normal distribution and has an exp only in the gradient via norm._pdf, the objective function uses norm._cdf.
I can look into it.
However: We don't use fmin_cg for anything by default, it's part of "testing all supported scipy optimizers" and we had problems with it before on various machines https://github.com/statsmodels/statsmodels/issues/109 The test was completely disabled on Windows for a while, and I might have to turn some screws again.
I'm fighting with more serious problems with fmin_slsqp and fmin_bfgs, which we really need to use.
If minor precision issues matter, then the code is not "robust" and should be fixed.
compared to precision issues. I'm fighting more with the large scale properties of exp. https://github.com/scipy/scipy/issues/3581
Neverthless, I would really like to know why I'm running into many platform differences and problems with scipy.optimize.
To avoid giving a wrong impression: Scipy.optimize works in general very well for statsmodels, we use it heavily and we have a large set of test cases for it. It's just the last 5% or so of cases where I spend a considerable amount of time figuring out how to get around convergence problems, which are sometimes platform specific and sometimes not. Josef
Cheers,
Josef
Cheers,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion