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
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 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)
> > > >
>
@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
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
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
