On Mon, 2021-03-01 at 01:30 +0100, Michal Radwanski wrote:
> Hello,
>
> I'm not sure if it's expected behaviour or a bug, so I decided to
> write
> here. First an example:
> In [4]: array([2**63])
> Out[4]: array([9223372036854775808], dtype=uint64)
>
> In [5]: array([2**63-1, 2**63])
> Out[5]:
Hello,
I'm not sure if it's expected behaviour or a bug, so I decided to write
here. First an example:
In [4]: array([2**63])
Out[4]: array([9223372036854775808], dtype=uint64)
In [5]: array([2**63-1, 2**63])
Out[5]: array([9.22337204e+18, 9.22337204e+18])
The docs for `numpy.array` mention,
Sorry for bad naming, I hit the "send" button too fast. Intended title:
"Possible documentation bug for numpy.array".
Jatorrizko mezua: al., 2021-03-01 01:30 +0100, egilea: Michal Radwanski
> Hello,
>
> I'm not sure if it's expected behaviour or a bug, so I decided to
> write
> here. First an exa
On Tue, Aug 28, 2018 at 12:27 PM Ralf Gommers
wrote:
> On Tue, Aug 28, 2018 at 12:21 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>>
>>
>> On Mon, Aug 27, 2018 at 10:05 PM Stephan Hoyer wrote:
>>
>> - It appears in astropy, dask, pandas, pint, scipy and TensorFlow.
>>>
>>
>> Th
On Tue, Aug 28, 2018 at 12:21 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
>
>
> On Mon, Aug 27, 2018 at 10:05 PM Stephan Hoyer wrote:
>
> - It appears in astropy, dask, pandas, pint, scipy and TensorFlow.
>>
>
> The only reason it appears in astropy is because of tests that Quantit
On Mon, Aug 27, 2018 at 10:05 PM Stephan Hoyer wrote:
- It appears in astropy, dask, pandas, pint, scipy and TensorFlow.
>
The only reason it appears in astropy is because of tests that Quantity
works correctly with it; we do not actually use it...
So that's at least a few hits that do not coun
In the meantime I'll make a PR to get rid of it from SciPy. We can also
signal other libraries to do so. Anything frees up the already-very-crowded
namespace of NumPy dot is worth it in my opinion.
On Tue, Aug 28, 2018 at 7:40 PM Stephan Hoyer wrote:
>
>
> On Tue, Aug 28, 2018 at 9:03 AM Ralf Go
On Tue, Aug 28, 2018 at 9:03 AM Ralf Gommers wrote:
> Maybe we need a "NumpyObsoleteWarning" :) At the least, we should probably
>> have a list of obsolete functions in the documentation somewhere. My main
>> concern is that as we go forward we might end up supporting a bunch of
>> functions that
On Tue, Aug 28, 2018 at 8:04 AM Charles R Harris
wrote:
>
>
> On Mon, Aug 27, 2018 at 8:05 PM Stephan Hoyer wrote:
>
>> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
>> wrote:
>>
>>> Chuck suggested (
>>> https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that
>>> we may want to
On Mon, Aug 27, 2018 at 8:05 PM Stephan Hoyer wrote:
> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
> wrote:
>
>> Chuck suggested (
>> https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that
>> we may want to consider deprecating np.ediff1d, which is perhaps not much
>> more usef
On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
wrote:
> Chuck suggested (
> https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that
> we may want to consider deprecating np.ediff1d, which is perhaps not much
> more useful than np.diff, apart from having some arguably strange prepend
On Mon, Aug 27, 2018 at 1:46 PM, Charles R Harris wrote:
>
>
> On Mon, Aug 27, 2018 at 11:37 AM Robert Kern
> wrote:
>
>> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
>> wrote:
>>
>>> Chuck suggested ( https://github.com/numpy/
>>> numpy/pull/11805#issuecomment-416069436 ) that we may want to c
There is already a patch to add such a feature to np.diff at
https://github.com/numpy/numpy/pull/8206
On Mon, 27 Aug 2018 at 10:47 Charles R Harris
wrote:
> On Mon, Aug 27, 2018 at 11:37 AM Robert Kern
> wrote:
>
>> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
>> wrote:
>>
>>> Chuck suggeste
On Mon, Aug 27, 2018 at 11:37 AM Robert Kern wrote:
> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
> wrote:
>
>> Chuck suggested (
>> https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that
>> we may want to consider deprecating np.ediff1d, which is perhaps not much
>> more usefu
Hi,
it was originally used in other functions of arraysetops (culprit yours truly)
which used to use the padding functionality. Nowadays the only use I can see
git-grepping the numpy sources is in the tests, so +1 for deprecating.
Cheers,
r.
On 08/27/2018 07:28 PM, Tyler Reddy wrote:
Chuck
On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy
wrote:
> Chuck suggested (
> https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that
> we may want to consider deprecating np.ediff1d, which is perhaps not much
> more useful than np.diff, apart from having some arguably strange prepend
Chuck suggested (
https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that we
may want to consider deprecating np.ediff1d, which is perhaps not much more
useful than np.diff, apart from having some arguably strange prepend /
append behavior added in.
Related discussion on SO:
https:
On Tue, Apr 3, 2018 at 3:45 PM, Joseph Fox-Rabinovitz <
jfoxrabinov...@gmail.com> wrote:
> I recently asked a question on Stack Overflow about whether `np.array`
> could raise an error if not passed a dtype parameter:
> https://stackoverflow.com/q/49639414/2988730.
>
> Turns out it can:
>
> np
I recently asked a question on Stack Overflow about whether `np.array`
could raise an error if not passed a dtype parameter:
https://stackoverflow.com/q/49639414/2988730.
Turns out it can:
np.array([1, [2]])
raises `ValueError: setting an array element with a sequence.` Surprisingly
though,
19 matches
Mail list logo
