> - There are major projects like scikit-learn that simply have no
> alternative to using np.matrix, because of scipy.sparse.
Well, we have no love for np.matrix, we just use scipy.sparse and
np.ndarray.
> - After there's an alternative to scipy.sparse:
+1 for alternative to scipy.sparse before
Hi Nathaniel,
Thanks for the concrete suggestion: see
https://github.com/numpy/numpy/pull/10142
I think this is useful independent of exactly how the eventual move to
a new package would work; next step might be to collect all matrix
tests in the `libmatrix` sub-module.
All the best,
Marten
On Thu, Nov 30, 2017, at 16:15, Nathaniel Smith wrote:
> PendingDeprecationWarning in np.matrix.__init__ (unless it kills
> performance for scikit-learn and friends), and put a big warning box
> at the top of the docs. The idea here is to not actually break
> anyone's code, but start to get out the
On Thu, Nov 30, 2017 at 11:39 AM, Charles R Harris
wrote:
>
>
> On Thu, Nov 30, 2017 at 11:43 AM, Ralf Gommers
> wrote:
>> I'd suggest any release in the next couple of years is fine,but the one
>> where we drop Python 2 support is probably the worst choice. That's one of
>> the few things the co
An NEP on utility functions for structured array definitely sounds
appealing to me.
On Thu, Nov 30, 2017 at 2:00 PM, Stefan van der Walt
wrote:
> On Thu, Nov 30, 2017, at 12:02, Marten van Kerkwijk wrote:
>> I think Josef specifically meant `recarrays`, which give access to
>> elements of a struc
Unlike for matrix, it is not so much a problem as an unclear use case
- the main thing they bring to structured dtype arrays is access by
attribute, which is slower than just doing getting the field by its
key.
Anyway, I don't think anybody is suggesting to remove them - they're
not a problem in th
On 2017/11/30 12:00 PM, Stefan van der Walt wrote:
I think Josef specifically meant `recarrays`, which give access to
elements of a structured array via attribute access. I'd tend to agree
with him that those turned out not to be such a great idea. But (I
I have found recarrays to be useful, pr
On Thu, Nov 30, 2017, at 12:02, Marten van Kerkwijk wrote:
> I think Josef specifically meant `recarrays`, which give access to
> elements of a structured array via attribute access. I'd tend to agree
> with him that those turned out not to be such a great idea. But (I
> think) nobody is arguing we
On Thu, Nov 30, 2017 at 2:51 PM, Stefan van der Walt
wrote:
> On Thu, Nov 30, 2017, at 10:13, josef.p...@gmail.com wrote:
>
> recarrays are another half-hearted feature in numpy that is mostly
> obsolete with pandas and pandas_like DataFrames in other
> packages.
>
>
> I'm fully on board with fact
Hi Ralf,
Sorry not to have recalled the previous thread.
Your point about not doing things in the python 2->3 move makes sense;
handy for me is no reason to give users an incentive not to move to
python3 because their matrix-dependent code breaks.
It does sound like, given the use of sparse, a s
On Thu, Nov 30, 2017, at 11:39, Charles R Harris wrote:
> Agree, we don't want to pile in too many changes at once. I think the big
> sticking point is the sparse matrices in SciPy, even issuing a
> DeprecationWarning could be problematic as long as there are sparse matrices.
Could you explain w
On Thu, Nov 30, 2017, at 10:13, josef.p...@gmail.com wrote:
> recarrays are another half-hearted feature in numpy that is mostly
> obsolete with pandas and pandas_like DataFrames in other
> packages.
I'm fully on board with factoring out np.matrix into a subpackage.
But I would not touch structure
On Thu, Nov 30, 2017 at 11:43 AM, Ralf Gommers
wrote:
>
>
> On Fri, Dec 1, 2017 at 7:17 AM, Matthew Rocklin
> wrote:
>
>> How would the community handle the scipy.sparse matrix subclasses? These
>> are still in common use.
>>
>
> They're not going anywhere for quite a while (until the sparse nd
On Fri, Dec 1, 2017 at 7:17 AM, Matthew Rocklin wrote:
> How would the community handle the scipy.sparse matrix subclasses? These
> are still in common use.
>
They're not going anywhere for quite a while (until the sparse ndarrays
materialize at least). Hence np.matrix needs to be moved, not de
How would the community handle the scipy.sparse matrix subclasses? These
are still in common use.
Somewhat related: https://github.com/scipy/scipy/issues/8162
On Thu, Nov 30, 2017 at 1:13 PM, wrote:
>
>
> On Thu, Nov 30, 2017 at 9:23 AM, Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote
On Thu, Nov 30, 2017 at 9:23 AM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> I wondered if the move to python3-only starting with numpy 1.17 would
> be a good reason to act on what we all seem to agree: that the matrix
> class was a bad idea, with its overriding of multip
This would be really good to remove the apparent confusion. Moreover, I
think cleanly explaining why using "np.matrix" is not a good idea *before*
announcing the news would encourage people to accept this decision along
the way. That would greatly reduce the sporadic "the devs are deprecating
stuff
Moving to a subpackage may indeed make more sense, though it might not
help as much with getting rid of the hacks inside other parts of numpy
to keep matrix working. In that respect it seems a bit different at
least from weave.
Then again, independently of whether we remove or release a separate
p
This is exactly what we did with the bokeh.charts deprecation. Moving to a
separate projects was both a huge relief for the developers as well as a great
way to focus and clarify expectations for users.
Bryan
> On Nov 30, 2017, at 10:20, Chris Laumann wrote:
>
> +1 (not that my lurking vot
+1 (not that my lurking vote should necessarily carry much weight). Rip it out
asap.
The existence of the matrix class has been literally the single biggest source
of confusion and subtle bugs in my and my students' codes for years.
Best, Chris
> On Nov 30, 2017, at 9:23 AM, Marten van Kerkwi
On Nov 30, 2017 09:24, "Marten van Kerkwijk"
wrote:
Hi All,
I wondered if the move to python3-only starting with numpy 1.17 would
be a good reason to act on what we all seem to agree: that the matrix
class was a bad idea, with its overriding of multiplication and lack
of support for stacks of ma
Hi All,
I wondered if the move to python3-only starting with numpy 1.17 would
be a good reason to act on what we all seem to agree: that the matrix
class was a bad idea, with its overriding of multiplication and lack
of support for stacks of matrices. For 1.17, minimum python supposedly
is >=3.5,
22 matches
Mail list logo
