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? Regards, Sebastian > -n > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
