[Numpy-discussion] MKL ValueError: On entry to DLASCL parameter number 5 had an illegal value

2015-03-10 Thread josef.pktd
I got a illegal value message using MKL on Windows 64 while running the
statsmodels test suite.

Kevin is getting the same with more information, which indicates that it
might be numpy.linalg.svd
https://github.com/statsmodels/statsmodels/issues/2308#issuecomment-78086656

Is this serious?

I'm just setting up a new computer and haven't investigated yet.
Given the name of the test class, this might be a warning for an inf or
nan, then it would be our problem in statsmodels

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


Re: [Numpy-discussion] MKL ValueError: On entry to DLASCL parameter number 5 had an illegal value

2015-03-10 Thread Charles R Harris
On Tue, Mar 10, 2015 at 10:33 AM,  wrote:

>
> I got a illegal value message using MKL on Windows 64 while running the
> statsmodels test suite.
>
> Kevin is getting the same with more information, which indicates that it
> might be numpy.linalg.svd
>
> https://github.com/statsmodels/statsmodels/issues/2308#issuecomment-78086656
>
> Is this serious?
>
> I'm just setting up a new computer and haven't investigated yet.
> Given the name of the test class, this might be a warning for an inf or
> nan, then it would be our problem in statsmodels
>
>
What version of Numpy? Does this also happen if you aren't using MKL?
The dlascl
reference 
is here. It is possible that the problem being solved is numerically
sensitive and that the treatment of underflow/overflow due to compiler
flags might be producing zeros or infs.

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


Re: [Numpy-discussion] MKL ValueError: On entry to DLASCL parameter number 5 had an illegal value

2015-03-10 Thread josef.pktd
On Tue, Mar 10, 2015 at 1:20 PM, Charles R Harris  wrote:

>
>
> On Tue, Mar 10, 2015 at 10:33 AM,  wrote:
>
>>
>> I got a illegal value message using MKL on Windows 64 while running the
>> statsmodels test suite.
>>
>> Kevin is getting the same with more information, which indicates that it
>> might be numpy.linalg.svd
>>
>> https://github.com/statsmodels/statsmodels/issues/2308#issuecomment-78086656
>>
>> Is this serious?
>>
>> I'm just setting up a new computer and haven't investigated yet.
>> Given the name of the test class, this might be a warning for an inf or
>> nan, then it would be our problem in statsmodels
>>
>>
> What version of Numpy? Does this also happen if you aren't using MKL? The 
> dlascl
> reference
>  is
> here. It is possible that the problem being solved is numerically sensitive
> and that the treatment of underflow/overflow due to compiler flags might be
> producing zeros or infs.
>

nosetests says NumPy version 1.9.2rc1
Version is from winpython which I guess uses Gohlke binaries.

It didn't show up with official numpy in 32bit python, and it doesn't show
up on TravisCI.

In contrast to Kevin, I don't get any info or test failure

M:\Notes>nosetests --pdb --pdb-failures -v
statsmodels.base.tests.test_data.Test
MissingArray
statsmodels.base.tests.test_data.TestMissingArray.test_raise_no_missing ...
ok
statsmodels.base.tests.test_data.TestMissingArray.test_raise ... ok
statsmodels.base.tests.test_data.TestMissingArray.test_drop ... ok
statsmodels.base.tests.test_data.TestMissingArray.test_none ...
Intel MKL ERROR: Parameter 4 was incorrect on entry to DLASCL.

Intel MKL ERROR: Parameter 5 was incorrect on entry to DLASCL.

Intel MKL ERROR: Parameter 4 was incorrect on entry to DLASCL.

Intel MKL ERROR: Parameter 5 was incorrect on entry to DLASCL.
ok
statsmodels.base.tests.test_data.TestMissingArray.test_endog_only_raise ...
ok
statsmodels.base.tests.test_data.TestMissingArray.test_endog_only_drop ...
ok
statsmodels.base.tests.test_data.TestMissingArray.test_mv_endog ... ok
statsmodels.base.tests.test_data.TestMissingArray.test_extra_kwargs_2d ...
ok
statsmodels.base.tests.test_data.TestMissingArray.test_extra_kwargs_1d ...
ok

--
Ran 9 tests in 0.049s

OK

However based on the testcase, it looks like we call np.linalg.svd with an
array that contains nans,
DLASCL might then be used internally in the svd calculations

Josef


> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Would like to patch docstring for numpy.random.normal

2015-03-10 Thread Paul Hobson
On Mon, Mar 9, 2015 at 4:33 PM, Charles R Harris 
wrote:

>
>
> On Mon, Mar 9, 2015 at 2:34 PM, Paul Hobson  wrote:
>
>> I feel your pain. Making it worse, numpy.random.lognormal takes "mean"
>> and "sigma" as input. If there's ever a backwards incompatible release, I
>> hope these things will be cleared up.
>>
>
> There is a numpy 2.0 milestone ;)
>
>
Is it worth submitting PRs against the existing 2.X branch or is that so
far away that the can should be kicked down the road?
-Paul
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Would like to patch docstring for numpy.random.normal

2015-03-10 Thread Nathaniel Smith
On Mar 10, 2015 11:15 AM, "Paul Hobson"  wrote:
>
>
> On Mon, Mar 9, 2015 at 4:33 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>>
>>
>>
>> On Mon, Mar 9, 2015 at 2:34 PM, Paul Hobson  wrote:
>>>
>>> I feel your pain. Making it worse, numpy.random.lognormal takes "mean"
and "sigma" as input. If there's ever a backwards incompatible release, I
hope these things will be cleared up.
>>
>>
>> There is a numpy 2.0 milestone ;)
>>
>
> Is it worth submitting PRs against the existing 2.X branch or is that so
far away that the can should be kicked down the road?

Not sure what you mean by "the existing 2.X branch" (does such a thing
exist somewhere?), but yeah, don't submit PRs like that. Best case they'd
bit rot before we ever get around to 2.0, worst case 2.0 may never happen.
(What, you liked python 2 -> 3 so much you want to go through that again?)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Would like to patch docstring for numpy.random.normal

2015-03-10 Thread Sturla Molden
On 09/03/15 21:34, Paul Hobson wrote:
> I feel your pain. Making it worse, numpy.random.lognormal takes "mean"
> and "sigma" as input. If there's ever a backwards incompatible release,
> I hope these things will be cleared up.

The question is how...

The fix is obvious, but the consequences are unacceptable.

Sturla



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


Re: [Numpy-discussion] Would like to patch docstring for numpy.random.normal

2015-03-10 Thread Paul Hobson
On Tue, Mar 10, 2015 at 11:22 AM, Nathaniel Smith  wrote:

> On Mar 10, 2015 11:15 AM, "Paul Hobson"  wrote:
> >
> >
> > On Mon, Mar 9, 2015 at 4:33 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >>
> >>
> >>
> >> On Mon, Mar 9, 2015 at 2:34 PM, Paul Hobson  wrote:
> >>>
> >>> I feel your pain. Making it worse, numpy.random.lognormal takes "mean"
> and "sigma" as input. If there's ever a backwards incompatible release, I
> hope these things will be cleared up.
> >>
> >>
> >> There is a numpy 2.0 milestone ;)
> >>
> >
> > Is it worth submitting PRs against the existing 2.X branch or is that so
> far away that the can should be kicked down the road?
>
> Not sure what you mean by "the existing 2.X branch" (does such a thing
> exist somewhere?), but yeah, don't submit PRs like that. Best case they'd
> bit rot before we ever get around to 2.0, worst case 2.0 may never happen.
> (What, you liked python 2 -> 3 so much you want to go through that again?)
>

It's been a while, but last time I build numpy from the master on github,
numpy.__version__ came back as 2.dev or something like that. So I always
assumed there was a 2.X branch.

It's been a while since I've built numpy, but clearly I'm mistaken.
-p
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion