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) +
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
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"
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
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
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 #
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