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_amd64.whl
>>>>>>
>>>>>> https://nipy.bic.berkeley.edu/scipy_installers/scipy-0.13.3-cp27-none-win_amd64.whl
>>>>>>
>>>>>> You can test with:
>>>>>>
>>>>>> pip install -U pip # to upgrade pip to latest
>>>>>> pip install -f https://nipy.bic.berkeley.edu/scipy_installers numpy
>>>>>> scipy
>>>>>>
>>>>>> Please do send feedback.
>>>>>>
>>>>>> ATLAS binary here:
>>>>>>
>>>>>>
>>>>>> https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-64-full-sse2.tar.bz2
>>>>>>
>>>>>> 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.

Cheers,

Josef

 

Cheers,

Matthew
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion