I agree with Number 2 and 4.
On Sat, Oct 27, 2018 at 12:38 AM Eric Wieser
wrote:
> in order to be used prior to calling C or Fortran code that expected at
> least a 1-d array
>
> I’d argue that the behavior for these functions should have just been to
> raise an error saying “this function does
I would also argue against deprecating these functions that we are using
increasingly in several projects that I am involved in.
On Sat, Oct 27, 2018, 01:28 Travis Oliphant wrote:
> What is the justification for deprecation exactly? These functions have
> been well documented and have had the
On Sat, Oct 27, 2018 at 6:37 PM Eric Wieser
wrote:
> in order to be used prior to calling C or Fortran code that expected at
> least a 1-d array
>
> I’d argue that the behavior for these functions should have just been to
> raise an error saying “this function does not support 0d arrays”, rather
in order to be used prior to calling C or Fortran code that expected at
least a 1-d array
I’d argue that the behavior for these functions should have just been to
raise an error saying “this function does not support 0d arrays”, rather
than silently inserting extra dimensions. As a bonus, that
On Fri, Oct 26, 2018 at 7:14 PM Alex Rogozhnikov
wrote:
> > If the desire is to shrink the API of NumPy, I could see that.
>
> Very good desire, but my goal was different.
>
> > For some users this is exactly what is wanted.
>
> Maybe so, but I didn't face such example (and nobody mentioned
> If the desire is to shrink the API of NumPy, I could see that. Very good desire, but my goal was different. > For some users this is exactly what is wanted. Maybe so, but I didn't face such example (and nobody mentioned those so far in the discussion).The opposite (according to the issue)
I see now the original motivation as the unfortunate situation that mxnet
authors did not understand that np.ascontiguousarray returned an array of
at least one dimension and perhaps used that one API to assume that NumPy
did not support 0-d arrays --- which NumPy does indeed support.
Certainly
What is the justification for deprecation exactly? These functions have
been well documented and have had the intended behavior of producing arrays
with dimension at least 1 for some time. Why is it unexpected to produce
arrays of at least 1 dimension? For some users this is exactly what is
On Fri, Oct 26, 2018 at 3:48 PM Sebastian Berg
wrote:
> On Fri, 2018-10-26 at 13:25 -0700, Stephan Hoyer wrote:
> > On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <
> > alex.rogozhni...@yandex.ru> wrote:
> > >
> > > The conservative way to handle this would be to do a deprecation
> > > cycle,
On Fri, 2018-10-26 at 13:25 -0700, Stephan Hoyer wrote:
> On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <
> alex.rogozhni...@yandex.ru> wrote:
> >
> > The conservative way to handle this would be to do a deprecation
> > cycle, specifically by issuing FutureWarning when scalars or 0d
> >
On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <
alex.rogozhni...@yandex.ru> wrote:
>
> The conservative way to handle this would be to do a deprecation cycle,
> specifically by issuing FutureWarning when scalars or 0d arrays are
> encountered as inputs.
> Sounds good to me. Behavior should be
On Thu, 25 Oct 2018 19:02:20 -0700, Stephan Hoyer wrote:
> I would also advocate for fixing these functions if possible (removing
> ndim=1). ascontiguousarray(...) is certainly more readable than asarray(...
> order='C').
I agree; these are widely used, and makes intuitive sense as part of the
The conservative way to handle this would be to do a deprecation cycle, specifically by issuing FutureWarning when scalars or 0d arrays are encountered as inputs.Sounds good to me. Behavior should be scheduled for numpy 1.18? 26.10.2018, 05:02, "Stephan Hoyer" :On Thu, Oct 25, 2018 at 3:10 PM
On Thu, Oct 25, 2018 at 3:10 PM Andras Deak wrote:
> On Thu, Oct 25, 2018 at 11:48 PM Joseph Fox-Rabinovitz
> wrote:
> >
> > In that vein, would it be advisable to re-implement them as aliases for
> the correctly behaving functions instead?
> >
> > - Joe
>
> Wouldn't "probably, can't be changed
On Thu, Oct 25, 2018 at 11:48 PM Joseph Fox-Rabinovitz
wrote:
>
> In that vein, would it be advisable to re-implement them as aliases for the
> correctly behaving functions instead?
>
> - Joe
Wouldn't "probably, can't be changed without breaking external code"
still apply? As I understand the
In that vein, would it be advisable to re-implement them as aliases for the
correctly behaving functions instead?
- Joe
On Thu, Oct 25, 2018 at 5:01 PM Joe Kington wrote:
> For what it's worth, these are fairly widely used functions. From a user
> standpoint, I'd gently argue against
For what it's worth, these are fairly widely used functions. From a user
standpoint, I'd gently argue against deprecating them. Documenting the
inconsistency with scalars seems like a less invasive approach.
In particular ascontiguousarray is a very common check to make when working
with C
17 matches
Mail list logo
