Re: [Numpy-discussion] Floor divison on int returns float
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
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
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
Hi, On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brettwrote: > 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
On Wed, Apr 6, 2016 at 6:47 AM, Olivier Griselwrote: > 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
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 Firingwrote: > 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
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