Depreciating asfortranarray and ascontiguousarray

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Depreciating asfortranarray and ascontiguousarray

Alex Rogozhnikov
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Joe Kington
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 libraries or low-level file formats.  A significant advantage over asarray(..., order='C') is readability.  It makes the intention very clear.  Similarly, asfortranarray is quite readable for folks that aren't deeply familiar with numpy. 

Given that the use-cases they're primarily used for are likely to be read by developers working in other languages (i.e. ascontiguousarray gets used at a lot of "boundaries" with other systems), keeping function names that make intention very clear is important.

Just my $0.02, anyway.  Cheers,
-Joe

On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Joseph Fox-Rabinovitz
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 <[hidden email]> wrote:
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 libraries or low-level file formats.  A significant advantage over asarray(..., order='C') is readability.  It makes the intention very clear.  Similarly, asfortranarray is quite readable for folks that aren't deeply familiar with numpy. 

Given that the use-cases they're primarily used for are likely to be read by developers working in other languages (i.e. ascontiguousarray gets used at a lot of "boundaries" with other systems), keeping function names that make intention very clear is important.

Just my $0.02, anyway.  Cheers,
-Joe

On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Andras Deak
On Thu, Oct 25, 2018 at 11:48 PM Joseph Fox-Rabinovitz
<[hidden email]> 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 suggestion for _deprecation_ is only
because there's (a lot of) code relying on the current behaviour (or
at least there's risk).

András
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Stephan Hoyer-2
On Thu, Oct 25, 2018 at 3:10 PM Andras Deak <[hidden email]> wrote:
On Thu, Oct 25, 2018 at 11:48 PM Joseph Fox-Rabinovitz
<[hidden email]> 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 suggestion for _deprecation_ is only
because there's (a lot of) code relying on the current behaviour (or
at least there's risk).

I would also advocate for fixing these functions if possible (removing ndim=1). ascontiguousarray(...) is certainly more readable than asarray(... order='C').

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.

Cheers,
Stephan

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Alex Rogozhnikov
 
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" <[hidden email]>:
On Thu, Oct 25, 2018 at 3:10 PM Andras Deak <[hidden email]> wrote:
On Thu, Oct 25, 2018 at 11:48 PM Joseph Fox-Rabinovitz
<[hidden email]> 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 suggestion for _deprecation_ is only
because there's (a lot of) code relying on the current behaviour (or
at least there's risk).
 
I would also advocate for fixing these functions if possible (removing ndim=1). ascontiguousarray(...) is certainly more readable than asarray(... order='C').
 
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.
 
Cheers,
Stephan
,

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Stefan van der Walt
In reply to this post by Stephan Hoyer-2
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.

Stéfan
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Stephan Hoyer-2
In reply to this post by Alex Rogozhnikov
On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <[hidden email]> 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 scheduled for numpy 1.18?

Yes, that sounds about right to me.
 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Sebastian Berg
On Fri, 2018-10-26 at 13:25 -0700, Stephan Hoyer wrote:

> On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <
> [hidden email]> 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 scheduled for numpy 1.18?
> >
>
> Yes, that sounds about right to me.
>
Is there a way to avoid the future warning? An unavoidable warning in a
widely used function seems really annoying to me. Unless, the 0d thing
happens rarely, but then it might be the downstream users that get the
warning for no reason.

- Sebastian


>  
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Stephan Hoyer-2
On Fri, Oct 26, 2018 at 3:48 PM Sebastian Berg <[hidden email]> wrote:
On Fri, 2018-10-26 at 13:25 -0700, Stephan Hoyer wrote:
> On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <
> [hidden email]> 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 scheduled for numpy 1.18?
> >
>
> Yes, that sounds about right to me.
>

Is there a way to avoid the future warning? An unavoidable warning in a
widely used function seems really annoying to me. Unless, the 0d thing
happens rarely, but then it might be the downstream users that get the
warning for no reason.

- Sebastian

My suspicion is that 0d arrays are rarely used as arguments to ascontiguousarray / asfortranarray. But it's hard to say for sure...

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

teoliphant
In reply to this post by Alex Rogozhnikov
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.

If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 

0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  

The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  

There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  

-Travis


 

On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

teoliphant
In reply to this post by Stephan Hoyer-2
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 that situation would motivate a documentation change to help steer other future users from making the same incorrect assumption, but deprecation is a separate question entirely.  I do not agree at all with the trend to remove functions from NumPy API prior to a dedicated NumPy 2.0 effort.  This breaks the idea of semantic versioning for NumPy.

These functions do, in fact, have a use and were very much intended to produce one-dimensional arrays --- in order to be used prior to calling C or Fortran code that expected at least a 1-d array.    A lot of the SciPy wrapping code needed this behavior.  It is a misinterpretation to assume this is buggy or unintended.  

Improving the documentation to warn about the behavior for 0-d arrays could indeed be useful.

-Travis


On Fri, Oct 26, 2018 at 6:27 PM Stephan Hoyer <[hidden email]> wrote:
On Fri, Oct 26, 2018 at 3:48 PM Sebastian Berg <[hidden email]> wrote:
On Fri, 2018-10-26 at 13:25 -0700, Stephan Hoyer wrote:
> On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov <
> [hidden email]> 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 scheduled for numpy 1.18?
> >
>
> Yes, that sounds about right to me.
>

Is there a way to avoid the future warning? An unavoidable warning in a
widely used function seems really annoying to me. Unless, the 0d thing
happens rarely, but then it might be the downstream users that get the
warning for no reason.

- Sebastian

My suspicion is that 0d arrays are rarely used as arguments to ascontiguousarray / asfortranarray. But it's hard to say for sure...
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Alex Rogozhnikov
In reply to this post by teoliphant
> 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) happened. Mxnet example is sufficient in my opinion.
 
Simple example:
x = np.zeros([])
assert(x.flags.c_contiguous)
assert(np.ascontiguousarray(x).shape == x.shape)
 
Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)
 
If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),
we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.
 
Alex.
 
 
27.10.2018, 02:27, "Travis Oliphant" <[hidden email]>:
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.
 
If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 
 
0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  
 
The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  
 
There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  
 
-Travis
 
 
 
 
On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
,

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

teoliphant


On Fri, Oct 26, 2018 at 7:14 PM Alex Rogozhnikov <[hidden email]> 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 those so far in the discussion).
The opposite (according to the issue) happened. Mxnet example is sufficient in my opinion.

I agree that the old motivation of APIs that would make it easy to create SciPy is no longer a major motivation for most users and even developers and so these reasons would not be very present (as well as why it wasn't even mentioned in the documentation).  

 
Simple example:
x = np.zeros([])
assert(x.flags.c_contiguous)
assert(np.ascontiguousarray(x).shape == x.shape)
 
Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)
 
If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),
we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.

I understand the lack of being convinced.  This is ultimately a problem of 0-d arrays not being fully embraced and accepted by the Numeric community originally (which NumPy inherited during the early days).   Is there a way to document functions that will be removed on a major version increase which don't print warnings on use? I would support this.

I'm a big supporter of making a NumPy 2.0 and have been for several years. Now that Python 3 transition has happened, I think we could seriously discuss this.  I'm trying to raise funding for maintenance and progress for NumPy and SciPy right now via Quansight Labs http://www.quansight.com/labs and I hope to be able to help find grants to support the wonderful efforts that have been happening for some time. 

While I'm thrilled and impressed by the number of amazing devs who have kept NumPy and SciPy going in mostly their spare time, it has created challenges that we have not had continuous maintenance funding to allow continuous paid development so that several people who know about the early decisions could not be retained to spend time on helping the transition.  

Your bringing the problem of mxnet devs is most appreciated.  I will make a documentation PR.

-Travis



 
Alex.
 
 
27.10.2018, 02:27, "Travis Oliphant" <[hidden email]>:
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.
 
If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 
 
0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  
 
The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  
 
There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  
 
-Travis
 
 
 
 
On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
,

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Eric Wieser

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 would push the function developers to add support for 0d. Obviously we can’t make it do that now, but what we can do is have it emit a warning in those cases.

I think our options are:

  1. Deprecate the entire function
  2. Deprecate and eventually(?) throw an error upon calling the function on 0d arrays, with a message like “in future using ascontiguousarray to promote 0d arrays to 1d arrays will not be supported. If promotion is intentional, use ascontiguousarray(atleast1d(x)) to silence this warning and keep the old behavior, and if not use asarray(x, order='C') to preserve 0d arrays”
  3. Deprecate (future-warning) when passed 0d arrays, and eventually skip the upcast to 1d.
    If the calling code really needed a 1d array, then it will probably fail, which is not really different to 2, but has the advantage that the names are less surprising.
  4. Only improve the documentation

My preference would be 3

Eric

On Fri, 26 Oct 2018 at 17:35 Travis Oliphant <[hidden email]> wrote:

On Fri, Oct 26, 2018 at 7:14 PM Alex Rogozhnikov <[hidden email]> 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 those so far in the discussion).
The opposite (according to the issue) happened. Mxnet example is sufficient in my opinion.

I agree that the old motivation of APIs that would make it easy to create SciPy is no longer a major motivation for most users and even developers and so these reasons would not be very present (as well as why it wasn't even mentioned in the documentation).  

 
Simple example:
x = np.zeros([])
assert(x.flags.c_contiguous)
assert(np.ascontiguousarray(x).shape == x.shape)
 
Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)
 
If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),
we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.

I understand the lack of being convinced.  This is ultimately a problem of 0-d arrays not being fully embraced and accepted by the Numeric community originally (which NumPy inherited during the early days).   Is there a way to document functions that will be removed on a major version increase which don't print warnings on use? I would support this.

I'm a big supporter of making a NumPy 2.0 and have been for several years. Now that Python 3 transition has happened, I think we could seriously discuss this.  I'm trying to raise funding for maintenance and progress for NumPy and SciPy right now via Quansight Labs http://www.quansight.com/labs and I hope to be able to help find grants to support the wonderful efforts that have been happening for some time. 

While I'm thrilled and impressed by the number of amazing devs who have kept NumPy and SciPy going in mostly their spare time, it has created challenges that we have not had continuous maintenance funding to allow continuous paid development so that several people who know about the early decisions could not be retained to spend time on helping the transition.  

Your bringing the problem of mxnet devs is most appreciated.  I will make a documentation PR.

-Travis



 
Alex.
 
 
27.10.2018, 02:27, "Travis Oliphant" <[hidden email]>:
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.
 
If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 
 
0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  
 
The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  
 
There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  
 
-Travis
 
 
 
 
On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
,

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

ralfgommers


On Sat, Oct 27, 2018 at 6:37 PM Eric Wieser <[hidden email]> 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 than silently inserting extra dimensions. As a bonus, that would push the function developers to add support for 0d. Obviously we can’t make it do that now, but what we can do is have it emit a warning in those cases.

I think our options are:

  1. Deprecate the entire function
  2. Deprecate and eventually(?) throw an error upon calling the function on 0d arrays, with a message like “in future using ascontiguousarray to promote 0d arrays to 1d arrays will not be supported. If promotion is intentional, use ascontiguousarray(atleast1d(x)) to silence this warning and keep the old behavior, and if not use asarray(x, order='C') to preserve 0d arrays”
  3. Deprecate (future-warning) when passed 0d arrays, and eventually skip the upcast to 1d.
    If the calling code really needed a 1d array, then it will probably fail, which is not really different to 2, but has the advantage that the names are less surprising.
  4. Only improve the documentation

My preference would be 3

I'd go for 4, or alternatively for the warning in 2 (which can be left in place indefinitely). 1 is unwarranted, and 3 will change behavior which is worse than just warning or stopping to support existing behavior (= 2).

Eric

On Fri, 26 Oct 2018 at 17:35 Travis Oliphant <[hidden email]> wrote:

On Fri, Oct 26, 2018 at 7:14 PM Alex Rogozhnikov <[hidden email]> 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 those so far in the discussion).
The opposite (according to the issue) happened. Mxnet example is sufficient in my opinion.

I agree that the old motivation of APIs that would make it easy to create SciPy is no longer a major motivation for most users and even developers and so these reasons would not be very present (as well as why it wasn't even mentioned in the documentation).  

 
Simple example:
x = np.zeros([])
assert(x.flags.c_contiguous)
assert(np.ascontiguousarray(x).shape == x.shape)
 
Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)
 
If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),
we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.

I understand the lack of being convinced.  This is ultimately a problem of 0-d arrays not being fully embraced and accepted by the Numeric community originally (which NumPy inherited during the early days).   Is there a way to document functions that will be removed on a major version increase which don't print warnings on use? I would support this.

No, there's no such thing at the moment - the closest thing is https://github.com/numpy/numpy/wiki/Backwards-incompatible-ideas-for-a-major-release. I doubt we want such a thing anyway - removing functions without deprecation warnings first doesn't seem quite right.

 

I'm a big supporter of making a NumPy 2.0 and have been for several years. Now that Python 3 transition has happened, I think we could seriously discuss this.

I think it's more helpful to discuss goals and concrete plans for those, rather than a "NumPy 2.0" label. The latter never worked in the past, and not just because of lack of time/funding - it just means different things to different people. We now have a good start on what our major goals are (http://www.numpy.org/neps/#roadmap), let's build on that.

  I'm trying to raise funding for maintenance and progress for NumPy and SciPy right now via Quansight Labs http://www.quansight.com/labs and I hope to be able to help find grants to support the wonderful efforts that have been happening for some time. 

The NumPy grant and having Tyler/Matti/Stefan at BIDS is a great start to funded development; more and more diverse funding sources would be awesome.

Cheers,
Ralf


While I'm thrilled and impressed by the number of amazing devs who have kept NumPy and SciPy going in mostly their spare time, it has created challenges that we have not had continuous maintenance funding to allow continuous paid development so that several people who know about the early decisions could not be retained to spend time on helping the transition.  

Your bringing the problem of mxnet devs is most appreciated.  I will make a documentation PR.

-Travis



 
Alex.
 
 
27.10.2018, 02:27, "Travis Oliphant" <[hidden email]>:
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.
 
If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 
 
0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  
 
The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  
 
There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  
 
-Travis
 
 
 
 
On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
,

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Sylvain Corlay
In reply to this post by teoliphant
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 <[hidden email]> wrote:
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.

If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 

0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  

The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  

There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  

-Travis


 

On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

teoliphant
In reply to this post by Eric Wieser
I agree with Number 2 and 4.  

On Sat, Oct 27, 2018 at 12:38 AM Eric Wieser <[hidden email]> 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 than silently inserting extra dimensions. As a bonus, that would push the function developers to add support for 0d. Obviously we can’t make it do that now, but what we can do is have it emit a warning in those cases.

I think our options are:

  1. Deprecate the entire function
  2. Deprecate and eventually(?) throw an error upon calling the function on 0d arrays, with a message like “in future using ascontiguousarray to promote 0d arrays to 1d arrays will not be supported. If promotion is intentional, use ascontiguousarray(atleast1d(x)) to silence this warning and keep the old behavior, and if not use asarray(x, order='C') to preserve 0d arrays”
  3. Deprecate (future-warning) when passed 0d arrays, and eventually skip the upcast to 1d.
    If the calling code really needed a 1d array, then it will probably fail, which is not really different to 2, but has the advantage that the names are less surprising.
  4. Only improve the documentation

My preference would be 3

Eric

On Fri, 26 Oct 2018 at 17:35 Travis Oliphant <[hidden email]> wrote:

On Fri, Oct 26, 2018 at 7:14 PM Alex Rogozhnikov <[hidden email]> 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 those so far in the discussion).
The opposite (according to the issue) happened. Mxnet example is sufficient in my opinion.

I agree that the old motivation of APIs that would make it easy to create SciPy is no longer a major motivation for most users and even developers and so these reasons would not be very present (as well as why it wasn't even mentioned in the documentation).  

 
Simple example:
x = np.zeros([])
assert(x.flags.c_contiguous)
assert(np.ascontiguousarray(x).shape == x.shape)
 
Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)
 
If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),
we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.

I understand the lack of being convinced.  This is ultimately a problem of 0-d arrays not being fully embraced and accepted by the Numeric community originally (which NumPy inherited during the early days).   Is there a way to document functions that will be removed on a major version increase which don't print warnings on use? I would support this.

I'm a big supporter of making a NumPy 2.0 and have been for several years. Now that Python 3 transition has happened, I think we could seriously discuss this.  I'm trying to raise funding for maintenance and progress for NumPy and SciPy right now via Quansight Labs http://www.quansight.com/labs and I hope to be able to help find grants to support the wonderful efforts that have been happening for some time. 

While I'm thrilled and impressed by the number of amazing devs who have kept NumPy and SciPy going in mostly their spare time, it has created challenges that we have not had continuous maintenance funding to allow continuous paid development so that several people who know about the early decisions could not be retained to spend time on helping the transition.  

Your bringing the problem of mxnet devs is most appreciated.  I will make a documentation PR.

-Travis



 
Alex.
 
 
27.10.2018, 02:27, "Travis Oliphant" <[hidden email]>:
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 wanted.  I don't understand the statement that behavior with 0-d arrays is unexpected.
 
If the desire is to shrink the API of NumPy, I could see that.   But, it seems odd to me to remove a much-used function with an established behavior except as part of a wider API-shrinkage effort. 
 
0-d arrays in NumPy are a separate conversation.  At this point, I think it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some sense 0-d arrays *are* scalars at least conceptually and for JIT-producing systems that exist now and will be growing in the future, they can be equivalent to scalars.  
 
The array scalars should become how you define what is *in* a NumPy array making them true Python types, rather than Python 1-style "instances" of a single "Dtype" object.  You would then have 0-d arrays and these Python "memory" types describing what is *in* the array.  
 
There is a clear way to do this, some of which has been outlined by Nathaniel, and the rest I have an outline for how to implement.  I can advise someone on how to do this.  
 
-Travis
 
 
 
 
On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <[hidden email]> wrote:
Dear numpy community,
 
I'm planning to depreciate np.asfortranarray and np.ascontiguousarray
functions 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, can't be changed without breaking external code
- I believe, this was a cause for poor support of 0-d arrays in mxnet.
- both functions are easily replaced with asarray(..., order='...'), which has expected behavior
 
There is no timeline for removal - we just need to discourage from using this functions in new code.
 
Function naming may be related to how numpy treats 0-d tensors specially,  
and those probably should not be called arrays.
However, as a user I never thought about 0-d arrays being special and being "not arrays".
 
 
Please see original discussion at github for more details
 
Your comments welcome,
Alex Rogozhnikov
 
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
,

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Depreciating asfortranarray and ascontiguousarray

Sebastian Berg
In reply to this post by ralfgommers
On Sat, 2018-10-27 at 19:29 +1300, Ralf Gommers wrote:
>
>
> On Sat, Oct 27, 2018 at 6:37 PM Eric Wieser <
> [hidden email]> wrote:
> > > in order to be used prior to calling C or Fortran code that
> > > expected at least a 1-d array
> > >
> >
<snip>

>
>  
> > > I'm a big supporter of making a NumPy 2.0 and have been for
> > > several years. Now that Python 3 transition has happened, I think
> > > we could seriously discuss this.
>
> I think it's more helpful to discuss goals and concrete plans for
> those, rather than a "NumPy 2.0" label. The latter never worked in
> the past, and not just because of lack of time/funding - it just
> means different things to different people. We now have a good start
> on what our major goals are (http://www.numpy.org/neps/#roadmap),
> let's build on that.
I agree. I do think that we should not be scared of a major release.
But, I would rather see it as a step towards, for example, better
dtypes. Aiming for a large cleanup seems like it might be a can of
worms [0].

About the asfortranarray/ascontiguousarray thing. I am not sure I like
FutureWarnings in the edge cases, it seems likely they arise randomly
on functions where the devs may not even be aware of it.
I do not like spamming the the API, but if we cannot agree on a nice
way forward, maybe this is a point where creating new names is an
options:

 * ascorderarray/asforderarray
 * asccontiguousarray/asfcontigouousarray
 * np.asarray(..., order='C'), is somewhat the same I guess

not sure I like the names too much, but I think we could find new names
here.
And then putting warnings is IMO OK, if there is a an easy/nice enough
way to avoid them (sure we can start in documentation if it helps).
We can wait for the actual removal for very long and at least until the
next major release or so, I do not think it matters much as long as
visible deprecation warnings exist to push downstream into changing
habits/code, the maintenance burden is pretty much zero after all.

Discussing how to approach larger changes is important, but I doubt
that these particular functions are problematic enough!

- Sebastian


[0] Happy to be shown wrong, but I seriously fear that aiming too high
will hinder progress -- unless maybe there is some very good funding
and skilled devs, but even then it might be too ambitious? -- and I am
not even sure it is easier on downstream.


>
> > >   I'm trying to raise funding for maintenance and progress for
> > > NumPy and SciPy right now via Quansight Labs
> > > http://www.quansight.com/labs and I hope to be able to help find
> > > grants to support the wonderful efforts that have been happening
> > > for some time.
>
> The NumPy grant and having Tyler/Matti/Stefan at BIDS is a great
> start to funded development; more and more diverse funding sources
> would be awesome.
Yes, that is very cool news!

- Sebastian

>
> Cheers,
> Ralf
>
> > > While I'm thrilled and impressed by the number of amazing devs
> > > who have kept NumPy and SciPy going in mostly their spare time,
> > > it has created challenges that we have not had continuous
> > > maintenance funding to allow continuous paid development so that
> > > several people who know about the early decisions could not be
> > > retained to spend time on helping the transition.  
> > >
> > > Your bringing the problem of mxnet devs is most appreciated.  I
> > > will make a documentation PR.
> > >
> > > -Travis
> > >
> > >
> > >
> > > >  
> > > > Alex.
> > > >  
> > > >  
> > > > 27.10.2018, 02:27, "Travis Oliphant" <[hidden email]>:
> > > > > 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
> > > > > wanted.  I don't understand the statement that behavior with
> > > > > 0-d arrays is unexpected.
> > > > >  
> > > > > If the desire is to shrink the API of NumPy, I could see
> > > > > that.   But, it seems odd to me to remove a much-used
> > > > > function with an established behavior except as part of a
> > > > > wider API-shrinkage effort.
> > > > >  
> > > > > 0-d arrays in NumPy are a separate conversation.  At this
> > > > > point, I think it was a mistake not to embrace 0-d arrays in
> > > > > NumPy from day one.  In some sense 0-d arrays *are* scalars
> > > > > at least conceptually and for JIT-producing systems that
> > > > > exist now and will be growing in the future, they can be
> > > > > equivalent to scalars.  
> > > > >  
> > > > > The array scalars should become how you define what is *in* a
> > > > > NumPy array making them true Python types, rather than Python
> > > > > 1-style "instances" of a single "Dtype" object.  You would
> > > > > then have 0-d arrays and these Python "memory" types
> > > > > describing what is *in* the array.  
> > > > >  
> > > > > There is a clear way to do this, some of which has been
> > > > > outlined by Nathaniel, and the rest I have an outline for how
> > > > > to implement.  I can advise someone on how to do this.  
> > > > >  
> > > > > -Travis
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <
> > > > > [hidden email]> wrote:
> > > > > > Dear numpy community,
> > > > > >  
> > > > > > I'm planning to depreciate np.asfortranarray and
> > > > > > np.ascontiguousarray
> > > > > > functions 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, can't be changed without breaking external code
> > > > > > - I believe, this was a cause for poor support of 0-d
> > > > > > arrays in mxnet.
> > > > > > - both functions are easily replaced with asarray(...,
> > > > > > order='...'), which has expected behavior
> > > > > >  
> > > > > > There is no timeline for removal - we just need to
> > > > > > discourage from using this functions in new code.
> > > > > >  
> > > > > > Function naming may be related to how numpy treats 0-d
> > > > > > tensors specially,  
> > > > > > and those probably should not be called arrays.
> > > > > > https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html
> > > > > > However, as a user I never thought about 0-d arrays being
> > > > > > special and being "not arrays".
> > > > > >  
> > > > > >  
> > > > > > Please see original discussion at github for more details
> > > > > > https://github.com/numpy/numpy/issues/5300
> > > > > >  
> > > > > > Your comments welcome,
> > > > > > Alex Rogozhnikov
> > > > > >  
> > > > > > _______________________________________________
> > > > > > NumPy-Discussion mailing list
> > > > > > [hidden email]
> > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > > >
> > > > > ,
> > > > > _______________________________________________
> > > > > NumPy-Discussion mailing list
> > > > > [hidden email]
> > > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > > _______________________________________________
> > > > NumPy-Discussion mailing list
> > > > [hidden email]
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > [hidden email]
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > >
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment