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

[Antony Lee]

Whatever the C rules are (which I don't know off the top of my head, but I
guess it must be one of uint64 or int64).  It's not as if conversion to
float64 was lossless:

In [38]: 2**63 - (np.int64(2**62-1) + np.uint64(2**62-1))
Out[38]: 0.0


Note that the result of (np.int64(2**62-1) + np.uint64(2**62-1)) would
actually fit in an int64 (or an uint64), so arguably the conversion to
float makes things worse.

Antony

2016-04-12 19:56 GMT-07:00 Nathaniel Smith :

> So what type should uint64 + int64 return?
> On Apr 12, 2016 7:17 PM, "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, after all even adding two
>> (sized) ints may give a result that does not fit in the same size, but
>> numpy does not upcast everything there:
>>
>> In [17]: np.int32(2**31 - 1) + np.int32(2**31 - 1)
>> Out[17]: -2
>>
>> In [18]: type(np.int32(2**31 - 1) + np.int32(2**31 - 1))
>> Out[18]: numpy.int32
>>
>>
>> I'd think that overflowing operations should just overflow (and possibly
>> raise a warning via the seterr mechanism), but their possibility should not
>> be an argument for modifying the output type.
>>
>> Antony
>>
>> 2016-04-12 17:57 GMT-07:00 T J :
>>
>>> Thanks Eric.
>>>
>>> Also relevant: https://github.com/numba/numba/issues/909
>>>
>>> Looks like Numba has found a way to avoid this edge case.
>>>
>>>
>>>
>>> On Monday, April 4, 2016, Eric Firing  wrote:
>>>
 On 2016/04/04 9:23 AM, T J wrote:

> I'm on NumPy 1.10.4 (mkl).
>
>  >>> np.uint(3) // 2   # 1.0
>  >>> 3 // 2   # 1
>
> Is this behavior expected? It's certainly not desired from my
> perspective. If this is not a bug, could someone explain the rationale
> to me.
>
> Thanks.
>

 I agree that it's almost always undesirable; one would reasonably
 expect some sort of int.  Here's what I think is going on:

 The odd behavior occurs only with np.uint, which is np.uint64, and when
 the denominator is a signed int.  The problem is that if the denominator is
 negative, the result will be negative, so it can't have the same type as
 the first numerator.  Furthermore, if the denominator is -1, the result
 will be minus the numerator, and that can't be represented by np.uint or
 np.int.  Therefore the result is returned as np.float64.  The
 promotion rules are based on what *could* happen in an operation, not on
 what *is* happening in a given instance.

 Eric

 ___
 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
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]

So what type should uint64 + int64 return?
On Apr 12, 2016 7:17 PM, "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, after all even adding two
> (sized) ints may give a result that does not fit in the same size, but
> numpy does not upcast everything there:
>
> In [17]: np.int32(2**31 - 1) + np.int32(2**31 - 1)
> Out[17]: -2
>
> In [18]: type(np.int32(2**31 - 1) + np.int32(2**31 - 1))
> Out[18]: numpy.int32
>
>
> I'd think that overflowing operations should just overflow (and possibly
> raise a warning via the seterr mechanism), but their possibility should not
> be an argument for modifying the output type.
>
> Antony
>
> 2016-04-12 17:57 GMT-07:00 T J :
>
>> Thanks Eric.
>>
>> Also relevant: https://github.com/numba/numba/issues/909
>>
>> Looks like Numba has found a way to avoid this edge case.
>>
>>
>>
>> On Monday, April 4, 2016, Eric Firing  wrote:
>>
>>> On 2016/04/04 9:23 AM, T J wrote:
>>>
 I'm on NumPy 1.10.4 (mkl).

  >>> np.uint(3) // 2   # 1.0
  >>> 3 // 2   # 1

 Is this behavior expected? It's certainly not desired from my
 perspective. If this is not a bug, could someone explain the rationale
 to me.

 Thanks.

>>>
>>> I agree that it's almost always undesirable; one would reasonably expect
>>> some sort of int.  Here's what I think is going on:
>>>
>>> The odd behavior occurs only with np.uint, which is np.uint64, and when
>>> the denominator is a signed int.  The problem is that if the denominator is
>>> negative, the result will be negative, so it can't have the same type as
>>> the first numerator.  Furthermore, if the denominator is -1, the result
>>> will be minus the numerator, and that can't be represented by np.uint or
>>> np.int.  Therefore the result is returned as np.float64.  The promotion
>>> rules are based on what *could* happen in an operation, not on what *is*
>>> happening in a given instance.
>>>
>>> Eric
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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] Floor divison on int returns float

[Antony Lee]

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, after all even adding two
(sized) ints may give a result that does not fit in the same size, but
numpy does not upcast everything there:

In [17]: np.int32(2**31 - 1) + np.int32(2**31 - 1)
Out[17]: -2

In [18]: type(np.int32(2**31 - 1) + np.int32(2**31 - 1))
Out[18]: numpy.int32


I'd think that overflowing operations should just overflow (and possibly
raise a warning via the seterr mechanism), but their possibility should not
be an argument for modifying the output type.

Antony

2016-04-12 17:57 GMT-07:00 T J :

> Thanks Eric.
>
> Also relevant: https://github.com/numba/numba/issues/909
>
> Looks like Numba has found a way to avoid this edge case.
>
>
>
> On Monday, April 4, 2016, Eric Firing  wrote:
>
>> On 2016/04/04 9:23 AM, T J wrote:
>>
>>> I'm on NumPy 1.10.4 (mkl).
>>>
>>>  >>> np.uint(3) // 2   # 1.0
>>>  >>> 3 // 2   # 1
>>>
>>> Is this behavior expected? It's certainly not desired from my
>>> perspective. If this is not a bug, could someone explain the rationale
>>> to me.
>>>
>>> Thanks.
>>>
>>
>> I agree that it's almost always undesirable; one would reasonably expect
>> some sort of int.  Here's what I think is going on:
>>
>> The odd behavior occurs only with np.uint, which is np.uint64, and when
>> the denominator is a signed int.  The problem is that if the denominator is
>> negative, the result will be negative, so it can't have the same type as
>> the first numerator.  Furthermore, if the denominator is -1, the result
>> will be minus the numerator, and that can't be represented by np.uint or
>> np.int.  Therefore the result is returned as np.float64.  The promotion
>> rules are based on what *could* happen in an operation, not on what *is*
>> happening in a given instance.
>>
>> Eric
>>
>> ___
>> 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
>
>
___
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]

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.

Cheers,

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

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

[Matthew Brett]

On Wed, Apr 6, 2016 at 6:47 AM, Olivier Grisel  wrote:
> I updated the issue:
>
> https://github.com/xianyi/OpenBLAS-CI/issues/10#issuecomment-206195714
>
> The random test_nanmedian_all_axis failure is unrelated to openblas
> and should be ignored.

It looks like all is well now, at least for the OpenBLAS buildbots :
http://build.openblas.net/builders

Matthew
___
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

[T J]

Thanks Eric.

Also relevant: https://github.com/numba/numba/issues/909

Looks like Numba has found a way to avoid this edge case.



On Monday, April 4, 2016, Eric Firing  wrote:

> On 2016/04/04 9:23 AM, T J wrote:
>
>> I'm on NumPy 1.10.4 (mkl).
>>
>>  >>> np.uint(3) // 2   # 1.0
>>  >>> 3 // 2   # 1
>>
>> Is this behavior expected? It's certainly not desired from my
>> perspective. If this is not a bug, could someone explain the rationale
>> to me.
>>
>> Thanks.
>>
>
> I agree that it's almost always undesirable; one would reasonably expect
> some sort of int.  Here's what I think is going on:
>
> The odd behavior occurs only with np.uint, which is np.uint64, and when
> the denominator is a signed int.  The problem is that if the denominator is
> negative, the result will be negative, so it can't have the same type as
> the first numerator.  Furthermore, if the denominator is -1, the result
> will be minus the numerator, and that can't be represented by np.uint or
> np.int.  Therefore the result is returned as np.float64.  The promotion
> rules are based on what *could* happen in an operation, not on what *is*
> happening in a given instance.
>
> Eric
>
> ___
> 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

[Numpy-discussion] NumpyDistribution has no object attribute include_package_deta

[Andersson, Patrik (S.E.)]

Hi,
I'm compiling Numpy 1.11.0 from source with python3.3, gcc-5.3.0, with 
LAPACK_SRC and BLAS_SRC set.
During the creating numpy.egg-info, an error occur with NumpyDistribution, it 
complains about it has not the attribute include_package_data.

Where shall I start look?

Kind regards
Patrik

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