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
What exactly would you like Cython wrappers for? Some of the C++ code
in scipy/sparse/sparsetools?
I see you have COO.from_scipy_sparse(x) in some pydata/sparse code paths,
which presumably you'd like to avoid or improve?
On Thu, 25 Oct 2018 at 03:41, Hameer Abbasi
wrote:
> Hi!
>
> Sorry to
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
Dear numpy community, I'm planning to depreciate np.asfortranarray and np.ascontiguousarrayfunctions due to their misbehavior on scalar (0-D tensors) with PR #12244. Current behavior (converting scalars to 1-d array with single element)- is unexpected and contradicts to documentation- probably,
Hi!
Sorry to miss this week’s meeting.
If I may point out an inaccuracy in the notes: in PyData/Sparse most things are
implemented from the ground up without relying on scipy.sparse. The only part
that does rely on it is `sparse.matmul`, `sparse.dot` and `sparse.tensordot`,
as well as a few
