On Fri, Nov 23, 2012 at 7:53 AM, Sebastian Berg <[email protected]>wrote:
> On Fri, 2012-11-23 at 10:49 +0000, Nathaniel Smith wrote: > > On 23 Nov 2012 03:34, "Charles R Harris" <[email protected]> > > wrote: > > > > > > Examples, > > > > > > In [13]: ones(()).flags.writeable > > > Out[13]: True > > > > > > In [14]: (-ones(())).flags.writeable > > > Out[14]: False > > > > > > In [15]: (-1*ones(())).flags.writeable > > > Out[15]: False > > > > > > In [16]: (1 + ones(())).flags.writeable > > > Out[16]: False > > > > > > In [17]: array(1) > > > Out[17]: array(1) > > > > > > In [18]: array(1).shape > > > Out[18]: () > > > > > > In [19]: array(1).flags.writeable > > > Out[19]: True > > > > Looks like a bug in the ufunc output value setup code or something? > > > It might be possible to rethink when (or if) to convert 0-d array to a > scalar. However, at the moment as far as I understand many functions > generally do not return 0-d arrays but scalars. Which makes sense > because mostly we would rather use scalars then 0-d arrays as they are > closer to typical python (hashable and subclasses of python types). > > Of course the way this is done is not aware of what is put in (scalar > vs. 0-d array), since all input is converted to an array normally, which > means that most (all?) functions either return 0-d arrays or scalars and > are never aware if the original input was a scalar or an array. Maybe > there could be a np.asarray_or_scalar or such so that its easier to give > the same output type as the original input type? > > Yes, that is what looks to be the case. It breaks the scalar + array -> array rule that applies to higher dimensional arrays. I'm not sure what should be done for this corner case, especially as the code in question is rather involved... Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
