On Wed, Jan 2, 2019 at 2:24 PM Sebastian Berg wrote:
>
> On Wed, 2019-01-02 at 11:27 +0100, Matthias Geier wrote:
> > Hi Sebastian.
> >
> > Thanks for the clarification.
> >
>
> > > print(arr.shape) # also (5, 2)
> > >
> > > so the arr container (shape, dtype) is changed/muted. I think we
> > > e
Hi,
Was it ever brought up the possibility of a new array class (ndrefonly,
ndview) that is strictly no copy?
All operations on ndrefonly will return ndrefonly and if the operation
cannot be completed without making a copy, it shall throw an error.
On the implementation there are two choices if
@Matthias:
Most of the time I would not assign to arr.shape, but in some rare
occasions I find it very useful.
And one of those rare occasions is when you want guaranteed no-copy
behavior.
Can you come up with any other example?
The only real argument you seem to have here is “my code uses arr.s
On Mon, 2019-01-07 at 20:04 +0100, Matthias Geier wrote:
> On Wed, Jan 2, 2019 at 2:24 PM Sebastian Berg wrote:
> > On Wed, 2019-01-02 at 11:27 +0100, Matthias Geier wrote:
> > > Hi Sebastian.
> > >
> > > Thanks for the clarification.
> > >
> >
> > > > print(arr.shape) # also (5, 2)
> > > >
>
Numpy uses pairwise summation along the fast axis if that axis contains no
more than 8192 elements. How was 8192 chosen?
Doubling to 16384 would result in a lot more function call overhead due to
the recursion. Is it a speed issue? Memory? Or something else entirely?
__
On Mon, 2019-01-07 at 12:15 -0800, Keith Goodman wrote:
> Numpy uses pairwise summation along the fast axis if that axis
> contains no more than 8192 elements. How was 8192 chosen?
>
It is simply a constant used throughout the ufunc machinery (and
iteration) for cache friendliness.
However, that
