Re: [Numpy-discussion] linux wheels coming soon

[Nathaniel Smith]

https://github.com/numpy/numpy/issues/7545

On Wed, Apr 13, 2016 at 3:38 PM, Nathaniel Smith  wrote:
> I can reproduce in self-compiled 1.9, so it's not a new bug.
>
> I think something's going wrong with NPY_SIGINT_ON / NPY_SIGINT_OFF,
> where our special sigint handler is getting left in place even after
> our code finishes running.
>
> Skimming the code, my best guess is that this is due to a race
> condition in how we save/restore the original signal handler, when
> multiple threads are running numpy fftpack code at the same time (and
> thus using NPY_SIGINT_{ON,OFF} from multiple threads).
>
> -n
>
> On Wed, Apr 13, 2016 at 1:47 PM, Matthew Brett  
> wrote:
>> On Wed, Apr 13, 2016 at 1:29 PM, Oscar Benjamin
>>  wrote:
>>> On 13 April 2016 at 20:15, Matthew Brett  wrote:
 Done.  If y'all are on linux, and you have pip >= 8.11,  you should
 now see this kind of thing:
>>>
>>> That's fantastic. Thanks Matt!
>>>
>>> I just test installed this and ran numpy.test(). All tests passed but
>>> then I got a segfault at the end by (semi-accidentally) hitting Ctrl-C
>>> at the prompt:
>>>
>>> $ python
>>> Python 2.7.9 (default, Apr  2 2015, 15:33:21)
>>> [GCC 4.9.2] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>> import numpy
>> numpy.test()
>>> Running unit tests for numpy
>>> 
>>> Ran 5781 tests in 72.238s
>>>
>>> OK (KNOWNFAIL=6, SKIP=15)
>>> 
>> Segmentation fault (core dumped)
>>>
>>> It was stopped at the prompt and then I did Ctrl-C and then the
>>> seg-fault message.
>>>
>>> $ uname -a
>>> Linux vnwulf 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC
>>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>>> $ lsb_release -a
>>> No LSB modules are available.
>>> Distributor ID:Ubuntu
>>> Description:Ubuntu 15.04
>>> Release:15.04
>>> Codename:vivid
>>>
>>
>> Thanks so much for testing - that's very useful.
>>
>> I get the same thing on my Debian Sid machine.
>>
>> Actually I also get the same thing with a local compile against Debian
>> ATLAS, here's the stack trace after:
>>
> import numpy; numpy.test()
> # Ctrl-C
>>
>> https://gist.github.com/f6d8fb42f24689b39536a2416d717056
>>
>> Do you get this as well?
>>
>> Cheers,
>>
>> Matthew
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org



-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] linux wheels coming soon

[Nathaniel Smith]

I can reproduce in self-compiled 1.9, so it's not a new bug.

I think something's going wrong with NPY_SIGINT_ON / NPY_SIGINT_OFF,
where our special sigint handler is getting left in place even after
our code finishes running.

Skimming the code, my best guess is that this is due to a race
condition in how we save/restore the original signal handler, when
multiple threads are running numpy fftpack code at the same time (and
thus using NPY_SIGINT_{ON,OFF} from multiple threads).

-n

On Wed, Apr 13, 2016 at 1:47 PM, Matthew Brett  wrote:
> On Wed, Apr 13, 2016 at 1:29 PM, Oscar Benjamin
>  wrote:
>> On 13 April 2016 at 20:15, Matthew Brett  wrote:
>>> Done.  If y'all are on linux, and you have pip >= 8.11,  you should
>>> now see this kind of thing:
>>
>> That's fantastic. Thanks Matt!
>>
>> I just test installed this and ran numpy.test(). All tests passed but
>> then I got a segfault at the end by (semi-accidentally) hitting Ctrl-C
>> at the prompt:
>>
>> $ python
>> Python 2.7.9 (default, Apr  2 2015, 15:33:21)
>> [GCC 4.9.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
> import numpy
> numpy.test()
>> Running unit tests for numpy
>> 
>> Ran 5781 tests in 72.238s
>>
>> OK (KNOWNFAIL=6, SKIP=15)
>> 
> Segmentation fault (core dumped)
>>
>> It was stopped at the prompt and then I did Ctrl-C and then the
>> seg-fault message.
>>
>> $ uname -a
>> Linux vnwulf 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC
>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID:Ubuntu
>> Description:Ubuntu 15.04
>> Release:15.04
>> Codename:vivid
>>
>
> Thanks so much for testing - that's very useful.
>
> I get the same thing on my Debian Sid machine.
>
> Actually I also get the same thing with a local compile against Debian
> ATLAS, here's the stack trace after:
>
 import numpy; numpy.test()
 # Ctrl-C
>
> https://gist.github.com/f6d8fb42f24689b39536a2416d717056
>
> Do you get this as well?
>
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion



-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] linux wheels coming soon

[Oscar Benjamin]

On 13 Apr 2016 21:48, "Matthew Brett"  wrote:
>
> On Wed, Apr 13, 2016 at 1:29 PM, Oscar Benjamin
>  wrote:
> > On 13 April 2016 at 20:15, Matthew Brett 
wrote:
> >> Done.  If y'all are on linux, and you have pip >= 8.11,  you should
> >> now see this kind of thing:
> >
> > That's fantastic. Thanks Matt!
> >
> > I just test installed this and ran numpy.test(). All tests passed but
> > then I got a segfault at the end by (semi-accidentally) hitting Ctrl-C
> > at the prompt:
> >
> > $ python
> > Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> > [GCC 4.9.2] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
>  import numpy
>  numpy.test()
> > Running unit tests for numpy
> > 
> > Ran 5781 tests in 72.238s
> >
> > OK (KNOWNFAIL=6, SKIP=15)
> > 
>  Segmentation fault (core dumped)
> >
> > It was stopped at the prompt and then I did Ctrl-C and then the
> > seg-fault message.
> >
> > $ uname -a
> > Linux vnwulf 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC
> > 2015 x86_64 x86_64 x86_64 GNU/Linux
> > $ lsb_release -a
> > No LSB modules are available.
> > Distributor ID:Ubuntu
> > Description:Ubuntu 15.04
> > Release:15.04
> > Codename:vivid
> >
>
> Thanks so much for testing - that's very useful.
>
> I get the same thing on my Debian Sid machine.
>
> Actually I also get the same thing with a local compile against Debian
> ATLAS, here's the stack trace after:
>
> >>> import numpy; numpy.test()
> >>> # Ctrl-C
>
> https://gist.github.com/f6d8fb42f24689b39536a2416d717056
>
> Do you get this as well?

It's late here but I'll test again tomorrow. What do I need to do to get
comparable output?

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

Re: [Numpy-discussion] linux wheels coming soon

[Charles R Harris]

On Wed, Apr 13, 2016 at 1:15 PM, Matthew Brett 
wrote:

> On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett 
> wrote:
> > Hi,
> >
> > On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett 
> wrote:
> >> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock 
> wrote:
> >>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon <
> rmcgi...@gmail.com> wrote:
>  I suspect that many of the maintainers of major scipy-ecosystem
> projects are
>  aware of these (or other similar) travis wheel caches, but would
> guess that
>  the pool of travis-ci python users who weren't aware of these wheel
> caches
>  is much much larger. So there will still be a lot of travis-ci clock
> cycles
>  saved by manylinux wheels.
> 
>  -Robert
> >>>
> >>> Yes exactly. Availability of NumPy Linux wheels on PyPI is definitely
> something
> >>> I would suggest adding to the release notes. Hopefully this will help
> trigger
> >>> a general availability of wheels in the numpy-ecosystem :)
> >>>
> >>> In the case of Travis CI, their VM images for Python already have a
> version
> >>> of NumPy installed, but having the latest version of NumPy and SciPy
> etc
> >>> available as Linux wheels would be very nice.
> >>
> >> We're very nearly there now.
> >>
> >> The latest versions of numpy, scipy, scikit-image, pandas, numexpr,
> >> statsmodels wheels for testing at
> >>
> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/
> >>
> >> Please do test with:
> >>
> >> python -m pip install --upgrade pip
> >>
> >> pip install --trusted-host=
> ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
> >> --find-links=
> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
> >> numpy scipy scikit-learn numexpr
> >>
> >> python -c 'import numpy; numpy.test("full")'
> >> python -c 'import scipy; scipy.test("full")'
> >>
> >> We would love to get any feedback as to whether these work on your
> machines.
> >
> > I've just rebuilt these wheels with the just-released OpenBLAS 0.2.18.
> >
> > OpenBLAS is now passing all its own tests and tests on numpy / scipy /
> > scikit-learn at http://build.openblas.net/builders
> >
> > Our tests of the wheels look good too:
> >
> > http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian
> > http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian
> > https://travis-ci.org/matthew-brett/manylinux-testing
> >
> > So I think these are ready to go.  I propose uploading these wheels
> > for numpy and scipy to pypi tomorrow unless anyone has an objection.
>
> Done.  If y'all are on linux, and you have pip >= 8.11,  you should
> now see this kind of thing:
>
> $ pip install numpy scipy
> Collecting numpy
>   Downloading numpy-1.11.0-cp27-cp27mu-manylinux1_x86_64.whl (15.3MB)
> 100% || 15.3MB 61kB/s
> Collecting scipy
>   Downloading scipy-0.17.0-cp27-cp27mu-manylinux1_x86_64.whl (39.5MB)
> 100% || 39.5MB 24kB/s
> Installing collected packages: numpy, scipy
> Successfully installed numpy-1.11.0 scipy-0.17.0
>

Great work. It is nice that we are finally getting the Windows thing
squared away after all these years.

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

Re: [Numpy-discussion] Floor divison on int returns float

[Charles R Harris]

On Wed, Apr 13, 2016 at 2:48 PM, Nathaniel Smith  wrote:

> On Apr 13, 2016 9:08 AM, "Robert Kern"  wrote:
> >
> > On Wed, Apr 13, 2016 at 3:17 AM, Antony Lee 
> wrote:
> > >
> > > This kind of issue (see also
> https://github.com/numpy/numpy/issues/3511) has become more annoying now
> that indexing requires integers (indexing with a float raises a
> VisibleDeprecationWarning).  The argument "dividing an uint by an int may
> give a result that does not fit in an uint nor in an int" does not sound
> very convincing to me,
> >
> > It shouldn't because that's not the rule that numpy follows. The range
> of the result is never considered. Both *inputs* are cast to the same type
> that can represent the full range of either input type (for that matter,
> the actual *values* of the inputs are also never considered). In the case
> of uint64 and int64, there is no really good common type (the integer
> hierarchy has to top out somewhere), but float64 merely loses resolution
> rather than cutting off half of the range of uint64.
>
> Let me play devil's advocate for a moment, since I've just been
> playing out this debate in my own mind and you've done a good job of
> articulating the case for that side :-).
>
> The counter argument is: it doesn't really matter about having a
> common type or not; what matters is whether the operation can be
> defined sensibly. For uint64  int64, this is actually not a
> problem: we provide 2s complement signed ints, so uint64 and int64 are
> both integers-mod-2**64, just choosing different representatives for
> the equivalence classes in the upper half of the ring. In particular,
> the uint64 and int64 ranges are isomorphic to each other.
>
> or with less jargon: casting between uint64 and int64 commutes with
> all arithmetic operations, so you actually get the same result
> performing the operation in infinite precision and then casting to
> uint64 or int64, or casting both operations to uint64 or int64 and
> then casting the result to uint64 or int64. Basically the operations
> are totally well-defined even if we stick within integers, and the
> casting is just another form of integer wraparound; we're already
> happy to tolerate wraparound for int64  int64 or uint64 
> uint64, so it's not entirely clear why we go all the way to float to
> avoid it for uint64  int64.
>
> [On second thought... I'm actually not 100% sure that the
> all-operations-commute-with-casting thing is true in the case of //'s
> rounding behavior. I would have to squint a lot to figure that out. I
> guess comparison operations are another exception -- a < b !=
> np.uint64(a) < np.uint64(b) in general.]
>

I looked this up once, `C` returns unsigned in the scalar case when both
operands have the same width. See Usual Arithmetic Conversions
.
I think that is not a bad choice, but there is the back compatibility
problem, plus it is a bit exceptional.

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

Re: [Numpy-discussion] Floor divison on int returns float

[Nathaniel Smith]

On Apr 13, 2016 9:08 AM, "Robert Kern"  wrote:
>
> On Wed, Apr 13, 2016 at 3:17 AM, Antony Lee  wrote:
> >
> > This kind of issue (see also https://github.com/numpy/numpy/issues/3511) 
> > has become more annoying now that indexing requires integers (indexing with 
> > a float raises a VisibleDeprecationWarning).  The argument "dividing an 
> > uint by an int may give a result that does not fit in an uint nor in an 
> > int" does not sound very convincing to me,
>
> It shouldn't because that's not the rule that numpy follows. The range of the 
> result is never considered. Both *inputs* are cast to the same type that can 
> represent the full range of either input type (for that matter, the actual 
> *values* of the inputs are also never considered). In the case of uint64 and 
> int64, there is no really good common type (the integer hierarchy has to top 
> out somewhere), but float64 merely loses resolution rather than cutting off 
> half of the range of uint64.

Let me play devil's advocate for a moment, since I've just been
playing out this debate in my own mind and you've done a good job of
articulating the case for that side :-).

The counter argument is: it doesn't really matter about having a
common type or not; what matters is whether the operation can be
defined sensibly. For uint64  int64, this is actually not a
problem: we provide 2s complement signed ints, so uint64 and int64 are
both integers-mod-2**64, just choosing different representatives for
the equivalence classes in the upper half of the ring. In particular,
the uint64 and int64 ranges are isomorphic to each other.

or with less jargon: casting between uint64 and int64 commutes with
all arithmetic operations, so you actually get the same result
performing the operation in infinite precision and then casting to
uint64 or int64, or casting both operations to uint64 or int64 and
then casting the result to uint64 or int64. Basically the operations
are totally well-defined even if we stick within integers, and the
casting is just another form of integer wraparound; we're already
happy to tolerate wraparound for int64  int64 or uint64 
uint64, so it's not entirely clear why we go all the way to float to
avoid it for uint64  int64.

[On second thought... I'm actually not 100% sure that the
all-operations-commute-with-casting thing is true in the case of //'s
rounding behavior. I would have to squint a lot to figure that out. I
guess comparison operations are another exception -- a < b !=
np.uint64(a) < np.uint64(b) in general.]

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

Re: [Numpy-discussion] linux wheels coming soon

[Matthew Brett]

On Wed, Apr 13, 2016 at 1:29 PM, Oscar Benjamin
 wrote:
> On 13 April 2016 at 20:15, Matthew Brett  wrote:
>> Done.  If y'all are on linux, and you have pip >= 8.11,  you should
>> now see this kind of thing:
>
> That's fantastic. Thanks Matt!
>
> I just test installed this and ran numpy.test(). All tests passed but
> then I got a segfault at the end by (semi-accidentally) hitting Ctrl-C
> at the prompt:
>
> $ python
> Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> [GCC 4.9.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import numpy
 numpy.test()
> Running unit tests for numpy
> 
> Ran 5781 tests in 72.238s
>
> OK (KNOWNFAIL=6, SKIP=15)
> 
 Segmentation fault (core dumped)
>
> It was stopped at the prompt and then I did Ctrl-C and then the
> seg-fault message.
>
> $ uname -a
> Linux vnwulf 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:Ubuntu
> Description:Ubuntu 15.04
> Release:15.04
> Codename:vivid
>

Thanks so much for testing - that's very useful.

I get the same thing on my Debian Sid machine.

Actually I also get the same thing with a local compile against Debian
ATLAS, here's the stack trace after:

>>> import numpy; numpy.test()
>>> # Ctrl-C

https://gist.github.com/f6d8fb42f24689b39536a2416d717056

Do you get this as well?

Cheers,

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

Re: [Numpy-discussion] linux wheels coming soon

[Oscar Benjamin]

On 13 April 2016 at 20:15, Matthew Brett  wrote:
> Done.  If y'all are on linux, and you have pip >= 8.11,  you should
> now see this kind of thing:

That's fantastic. Thanks Matt!

I just test installed this and ran numpy.test(). All tests passed but
then I got a segfault at the end by (semi-accidentally) hitting Ctrl-C
at the prompt:

$ python
Python 2.7.9 (default, Apr  2 2015, 15:33:21)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.test()
Running unit tests for numpy

Ran 5781 tests in 72.238s

OK (KNOWNFAIL=6, SKIP=15)

>>> Segmentation fault (core dumped)

It was stopped at the prompt and then I did Ctrl-C and then the
seg-fault message.

$ uname -a
Linux vnwulf 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 15.04
Release:15.04
Codename:vivid

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

Re: [Numpy-discussion] linux wheels coming soon

[Nathaniel Smith]

Woot! \o/

On Wed, Apr 13, 2016 at 12:15 PM, Matthew Brett 
wrote:

> On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett 
> wrote:
> > Hi,
> >
> > On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett 
> wrote:
> >> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock 
> wrote:
> >>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon <
> rmcgi...@gmail.com> wrote:
>  I suspect that many of the maintainers of major scipy-ecosystem
> projects are
>  aware of these (or other similar) travis wheel caches, but would
> guess that
>  the pool of travis-ci python users who weren't aware of these wheel
> caches
>  is much much larger. So there will still be a lot of travis-ci clock
> cycles
>  saved by manylinux wheels.
> 
>  -Robert
> >>>
> >>> Yes exactly. Availability of NumPy Linux wheels on PyPI is definitely
> something
> >>> I would suggest adding to the release notes. Hopefully this will help
> trigger
> >>> a general availability of wheels in the numpy-ecosystem :)
> >>>
> >>> In the case of Travis CI, their VM images for Python already have a
> version
> >>> of NumPy installed, but having the latest version of NumPy and SciPy
> etc
> >>> available as Linux wheels would be very nice.
> >>
> >> We're very nearly there now.
> >>
> >> The latest versions of numpy, scipy, scikit-image, pandas, numexpr,
> >> statsmodels wheels for testing at
> >>
> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/
> >>
> >> Please do test with:
> >>
> >> python -m pip install --upgrade pip
> >>
> >> pip install --trusted-host=
> ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
> >> --find-links=
> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
> >> numpy scipy scikit-learn numexpr
> >>
> >> python -c 'import numpy; numpy.test("full")'
> >> python -c 'import scipy; scipy.test("full")'
> >>
> >> We would love to get any feedback as to whether these work on your
> machines.
> >
> > I've just rebuilt these wheels with the just-released OpenBLAS 0.2.18.
> >
> > OpenBLAS is now passing all its own tests and tests on numpy / scipy /
> > scikit-learn at http://build.openblas.net/builders
> >
> > Our tests of the wheels look good too:
> >
> > http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian
> > http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian
> > https://travis-ci.org/matthew-brett/manylinux-testing
> >
> > So I think these are ready to go.  I propose uploading these wheels
> > for numpy and scipy to pypi tomorrow unless anyone has an objection.
>
> Done.  If y'all are on linux, and you have pip >= 8.11,  you should
> now see this kind of thing:
>
> $ pip install numpy scipy
> Collecting numpy
>   Downloading numpy-1.11.0-cp27-cp27mu-manylinux1_x86_64.whl (15.3MB)
> 100% || 15.3MB 61kB/s
> Collecting scipy
>   Downloading scipy-0.17.0-cp27-cp27mu-manylinux1_x86_64.whl (39.5MB)
> 100% || 39.5MB 24kB/s
> Installing collected packages: numpy, scipy
> Successfully installed numpy-1.11.0 scipy-0.17.0
>
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Nathaniel J. Smith -- https://vorpus.org 
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] linux wheels coming soon

[Olivier Grisel]

\o/

Thank you very much Matthew. I will upload the scikit-learn wheels soon.

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

Re: [Numpy-discussion] linux wheels coming soon

[Matthew Brett]

On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett  wrote:
> Hi,
>
> On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett  wrote:
>> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock  
>> wrote:
>>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon  
>>> wrote:
 I suspect that many of the maintainers of major scipy-ecosystem projects 
 are
 aware of these (or other similar) travis wheel caches, but would guess that
 the pool of travis-ci python users who weren't aware of these wheel caches
 is much much larger. So there will still be a lot of travis-ci clock cycles
 saved by manylinux wheels.

 -Robert
>>>
>>> Yes exactly. Availability of NumPy Linux wheels on PyPI is definitely 
>>> something
>>> I would suggest adding to the release notes. Hopefully this will help 
>>> trigger
>>> a general availability of wheels in the numpy-ecosystem :)
>>>
>>> In the case of Travis CI, their VM images for Python already have a version
>>> of NumPy installed, but having the latest version of NumPy and SciPy etc
>>> available as Linux wheels would be very nice.
>>
>> We're very nearly there now.
>>
>> The latest versions of numpy, scipy, scikit-image, pandas, numexpr,
>> statsmodels wheels for testing at
>> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/
>>
>> Please do test with:
>>
>> python -m pip install --upgrade pip
>>
>> pip install 
>> --trusted-host=ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
>> --find-links=http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
>> numpy scipy scikit-learn numexpr
>>
>> python -c 'import numpy; numpy.test("full")'
>> python -c 'import scipy; scipy.test("full")'
>>
>> We would love to get any feedback as to whether these work on your machines.
>
> I've just rebuilt these wheels with the just-released OpenBLAS 0.2.18.
>
> OpenBLAS is now passing all its own tests and tests on numpy / scipy /
> scikit-learn at http://build.openblas.net/builders
>
> Our tests of the wheels look good too:
>
> http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian
> http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian
> https://travis-ci.org/matthew-brett/manylinux-testing
>
> So I think these are ready to go.  I propose uploading these wheels
> for numpy and scipy to pypi tomorrow unless anyone has an objection.

Done.  If y'all are on linux, and you have pip >= 8.11,  you should
now see this kind of thing:

$ pip install numpy scipy
Collecting numpy
  Downloading numpy-1.11.0-cp27-cp27mu-manylinux1_x86_64.whl (15.3MB)
100% || 15.3MB 61kB/s
Collecting scipy
  Downloading scipy-0.17.0-cp27-cp27mu-manylinux1_x86_64.whl (39.5MB)
100% || 39.5MB 24kB/s
Installing collected packages: numpy, scipy
Successfully installed numpy-1.11.0 scipy-0.17.0

Cheers,

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

Re: [Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

[Stephan Hoyer]

On Wed, Apr 13, 2016 at 8:06 AM,  wrote:
>
> The difference is that Python 3 has long ints, (and doesn't have to
> overflow, AFAICS)
>

This is a good point. But if your float is so big that rounding it to an
integer would overflow int64, rounding is already a no-op. I'm sure this
has been done before but I would guess it's quite rare. I would be OK
raising in this situation, especially because np.around will still be
around returning floats.


> what happens with nan?
> I guess inf would overflow?
>

builtins.round raises for both of these (in Python 3) and I would propose
copying this behavior:

In [52]: round(float('inf'))
---
OverflowError Traceback (most recent call last)
 in ()
> 1 round(float('inf'))

OverflowError: cannot convert float infinity to integer

In [53]: round(float('nan'))
---
ValueErrorTraceback (most recent call last)
 in ()
> 1 round(float('nan'))

ValueError: cannot convert float NaN to integer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Floor divison on int returns float

[Robert Kern]

On Wed, Apr 13, 2016 at 3:17 AM, Antony Lee  wrote:
>
> This kind of issue (see also https://github.com/numpy/numpy/issues/3511)
has become more annoying now that indexing requires integers (indexing with
a float raises a VisibleDeprecationWarning).  The argument "dividing an
uint by an int may give a result that does not fit in an uint nor in an
int" does not sound very convincing to me,

It shouldn't because that's not the rule that numpy follows. The range of
the result is never considered. Both *inputs* are cast to the same type
that can represent the full range of either input type (for that matter,
the actual *values* of the inputs are also never considered). In the case
of uint64 and int64, there is no really good common type (the integer
hierarchy has to top out somewhere), but float64 merely loses resolution
rather than cutting off half of the range of uint64.

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

Re: [Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

[josef.pktd]

On Wed, Apr 13, 2016 at 4:31 AM, Stephan Hoyer  wrote:

> On Wed, Apr 13, 2016 at 12:42 AM, Antony Lee 
> wrote:
>
>> (Note that I am suggesting to switch to the new behavior regardless of
>> the version of Python.)
>>
>
> I would lean towards making this change only for Python 3. This is
> arguably more consistent with Python than changing the behavior on Python
> 2.7, too.
>
> The most obvious way in which a float being surprisingly switched to an
> integer could cause silent bugs (rather than noisy TypeErrors) is if the
> number is used in division. True division in Python 3 eliminates this risk.
>
> Generally, I agree with your reasoning. It would be unfortunate to be
> stuck with this legacy behavior forever.
>
>
The difference is that Python 3 has long ints, (and doesn't have to
overflow, AFAICS)

what happens with nan?
I guess inf would overflow?

(nan and inf are preserved with np.round)

Josef



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

Re: [Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

[Stephan Hoyer]

On Wed, Apr 13, 2016 at 12:42 AM, Antony Lee 
wrote:

> (Note that I am suggesting to switch to the new behavior regardless of the
> version of Python.)
>

I would lean towards making this change only for Python 3. This is arguably
more consistent with Python than changing the behavior on Python 2.7, too.

The most obvious way in which a float being surprisingly switched to an
integer could cause silent bugs (rather than noisy TypeErrors) is if the
number is used in division. True division in Python 3 eliminates this risk.

Generally, I agree with your reasoning. It would be unfortunate to be stuck
with this legacy behavior forever.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

[Antony Lee]

https://github.com/numpy/numpy/issues/3511 proposed (nearly three years
ago) to return an integer when `builtins.round` (which calls the `__round__
dunder method, and thereafter called `round` (... not to be confused with
`np.round`)) is called with a single argument.  Currently, `round` returns
a floating scalar for numpy scalars, matching the Python2 behavior.

Python3 changed the behavior of `round` to return an int when it is called
with a single argument (otherwise, the return type matches the type of the
first argument).  I believe this is more intuitive, and is arguably
becoming more important now that numpy is deprecating (via a
VisibleDeprecationWarning) indexing with a float: having to write

array[int(round(some_float))]


is rather awkward.  (Note that I am suggesting to switch to the new
behavior regardless of the version of Python.)

Note that currently the `__round__` dunder is not implemented for arrays
(... see https://github.com/numpy/numpy/issues/6248) so it would be
feasible to always return a signed integer of the same size with an
OverflowError on overflow (at least, any floating point that is round-able
without loss of precision will be covered).  If `__round__` ends up being
implemented for ndarrays too, I guess the correct behavior will be whatever
we come up for signaling failure in integer operations (see current
behavior of `np.array([0, 1]) // np.array([0, 1])`).

Also note the comment posted by @njsmith on the github issue thread:

I'd be fine with matching python here, but we need to run it by the mailing
list.

Not clear what the right kind of deprecation is... Normally FutureWarning
since there's no error involved, but that would both be very annoying
(basically makes round unusable -- you get this noisy warning even if what
you're doing is round(a).astype(int)), and the change is relatively low
risk compared to most FutureWarning changes, since the actual values
returned are identical before and after the change.


Thoughts?

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