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 wou
On Sat, Oct 27, 2018 at 11:10 AM Stefan van der Walt
wrote:
> On Sat, 27 Oct 2018 10:27:49 +1300, Ralf Gommers wrote:
> > Just to make sure we're talking about the same things here: Stefan, I
> think
> > with "sparray" you mean "an n-D sparse array implementation that lives in
> > SciPy", nothing
On Fri, Oct 19, 2018 at 8:24 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> It seems there are two extreme possibilities for general functions:
> 1. Put `asarray` everywhere. The main benefit that I can see is that even
> if people put in list instead of arrays, one is gu
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 thos
> 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) happene
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 th
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
want
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
> > array
On Sat, 27 Oct 2018 10:27:49 +1300, Ralf Gommers wrote:
> Just to make sure we're talking about the same things here: Stefan, I think
> with "sparray" you mean "an n-D sparse array implementation that lives in
> SciPy", nothing more specific? In that case pydata/sparse is the one
> implementation,
On Sat, Oct 27, 2018 at 6:10 AM Hameer Abbasi
wrote:
> Hi Stefan!
>
> PyData/Sparse is pretty far along, by January or so we should have a
> CSR/CSC replacement that is ND. It needs optimisation in a lot of cases but
> the API is compatible with NumPy and works pretty well already IMO.
>
> PyData
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
API
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 An
Hi Stefan!
PyData/Sparse is pretty far along, by January or so we should have a CSR/CSC
replacement that is ND. It needs optimisation in a lot of cases but the API is
compatible with NumPy and works pretty well already IMO.
PyData/Sparse is pretty much independent of any changes to scipy.sparse
Hi Hameer,
On Fri, 26 Oct 2018 10:47:09 +0200, Hameer Abbasi wrote:
> The only core functionality dependent on scipy.sparse is matrix
> multiplication and the like. Everything else is for inter-operability.
Thank you for commenting here.
As you know, I am enthusiastic about seeing an `sparray` e
Hi everyone,
Like I said, we just use those to coerce SciPy arrays to native ones for
compatibility. You could remove all those and the package would work fine, as
long as you were using native PyData/Sparse arrays.
The only core functionality dependent on scipy.sparse is matrix multiplication
18 matches
Mail list logo