Re: [Numpy-discussion] AppVeyor

2015-12-21 Thread Ian Henriksen 
>
> Also, am I correct that these are win64 builds only? Anyone know if it
> would be easy to add win32?
>

It'd be really easy to add 32 bit builds. The main reason I didn't was
because appveyor only
gives one concurrent build job for free, and I didn't want to slow things
down too much. I can get
a PR up for 32 bit builds too if you'd like.

Some background: I based the initial setup off of the dynd-python appveyor
setup
(https://github.com/libdynd/dynd-python/blob/master/appveyor.yml) where we
do one 32 and one
64 bit build. For fancier selection of Python installation, there's a demo
at
https://github.com/ogrisel/python-appveyor-demo that looks promising as
well. I avoided that
initially because it's a lot more complex than just a single appveyor.yml
file.

Best,
-Ian
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] AppVeyor

2015-12-21 Thread Ian Henriksen 
>
> The Python 3 build runs much faster than the Python 2. You can close and
>> reopen my testing PR to check what happens if you enable the numpy project.
>
>
I'm not sure why this is the case. MSVC 2015 is generally better about a
lot of things, but it's
surprising that the speed difference is so large.
Best,
-Ian
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Why is masked string array fill value 'N/A'

2015-12-21 Thread Charles R Harris 
Why, why, why is it not the empty string. you can't actually fill an `S2`
type with such a string, hence one must convert masked string arrays to a
list of strings to use it. That is pathetic.

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

[Numpy-discussion] PR for complex np.interp, question about assert_almost_equal

2015-12-21 Thread Peter Creasey 
Hi all,
I submitted a PR (#6872) for using complex numbers in np.lib.interp.

The tests pass on my machine, but I see that the TravisCI builds are
giving assertion fails (on my own test) with python 3.3 and 3.5 of the
form:
> assert_almost_equal
> TypeError: Cannot cast array data from dtype('complex128') to 
> dtype('float64') according to the rule 'safe'

When I was writing the test I used np.testing.assert_almost_equal with
complex128 as it works in my python 2.7, however having checked the
docstring I cannot tell what the expected behaviour should be (complex
or no complex allowed). Should my test be changed or the
assert_almost_equal?

Best,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

2015-12-21 Thread Chris Barker 
On Fri, Dec 18, 2015 at 1:51 PM, Ralf Gommers
>
> +1 from me. Despite the number of downloads still being high, I don't
> think there's too much value in these binaries anymore.
>

If there are a lot of downloads, then there is value. At least until we
have binary wheels on PyPi.

What's up with that, by the way?

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal: stop providing official win32 downloads (for now)

2015-12-21 Thread Ralf Gommers 
On Mon, Dec 21, 2015 at 11:11 PM, Chris Barker 
wrote:

> On Fri, Dec 18, 2015 at 1:51 PM, Ralf Gommers
>>
>> +1 from me. Despite the number of downloads still being high, I don't
>> think there's too much value in these binaries anymore.
>>
>
> If there are a lot of downloads, then there is value.
>

There's a good chance that many downloads are from unsuspecting users with
a 64-bit Python, and they then just get an unhelpful "cannot find Python"
error from the installer.

At least until we have binary wheels on PyPi.
>
> What's up with that, by the way?
>

I expect those to appear in 2016, built with MinGW-w64 and OpenBLAS.

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

Re: [Numpy-discussion] PR for complex np.interp, question about assert_almost_equal

2015-12-21 Thread Ralf Gommers 
On Tue, Dec 22, 2015 at 12:55 AM, Peter Creasey <
p.e.creasey...@googlemail.com> wrote:

> Hi all,
> I submitted a PR (#6872) for using complex numbers in np.lib.interp.
>
> The tests pass on my machine, but I see that the TravisCI builds are
> giving assertion fails (on my own test) with python 3.3 and 3.5 of the
> form:
> > assert_almost_equal
> > TypeError: Cannot cast array data from dtype('complex128') to
> dtype('float64') according to the rule 'safe'
>
> When I was writing the test I used np.testing.assert_almost_equal with
> complex128 as it works in my python 2.7, however having checked the
> docstring I cannot tell what the expected behaviour should be (complex
> or no complex allowed). Should my test be changed or the
> assert_almost_equal?
>

Hi Peter, that error is unrelated to assert_almost_equal. What happens is
that when you pass in a complex argument `fp` to your modified
`compiled_interp`, you're somewhere doing a cast that's not safe and
trigger the error at
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/ctors.c#L1930.
For what "safe casting" means, see
http://docs.scipy.org/doc/numpy/reference/generated/numpy.can_cast.html

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

Re: [Numpy-discussion] AppVeyor

2015-12-21 Thread Ralf Gommers 
On Mon, Dec 21, 2015 at 7:42 PM, Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:

> Also, am I correct that these are win64 builds only? Anyone know if it
>> would be easy to add win32?
>>
>
> It'd be really easy to add 32 bit builds. The main reason I didn't was
> because appveyor only
> gives one concurrent build job for free, and I didn't want to slow things
> down too much. I can get
> a PR up for 32 bit builds too if you'd like.
>

That would be quite useful I think. 32/64-bit issues are mostly orthogonal
to py2/py3 ones, so may only a 32-bit Python 3.5 build to keep things fast?

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