Hi all,
I have been taking a deep look at the sorting functionality in numpy, and I
think it could use a face lift in the form of a big code refactor, to get
rid of some of the ugliness in the code and make it easier to maintain.
What I have in mind basically amounts to:
1. Refactor _new_argso
Hello everyone,
I originally brought an optimized einsum routine forward a few weeks back that
attempts to contract numpy arrays together in an optimal way. This can greatly
reduce the scaling and overall cost of the einsum expression for the cost of a
few intermediate arrays. The current versio
Thank you Charles for the corrections.
Cheers,
N.Maniteja
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jan 15, 2015 at 10:41 PM, Charles R Harris <
charlesr.har...@gmail.co
On Thu, Jan 15, 2015 at 5:01 PM, Antoine Pitrou wrote:
>
> Hello,
>
> I see that the PyDataMem_* APIs call malloc()/free()/etc. directly,
> instead of going through PyMem_Malloc, etc. This means the memory
> allocated by those APIs won't be seen by tracemalloc. Is it deliberate?
> Am I missing som
On Thu, Jan 15, 2015 at 9:44 AM, Maniteja Nandana <
maniteja.modesty...@gmail.com> wrote:
> Hello everyone,
>
> I just wanted to highlight the point made by Charles, it would be great if
> he would clarify any mistakes in the points that I put forward.
>
> Quoting the documentation,
>
> In version
Hello,
I see that the PyDataMem_* APIs call malloc()/free()/etc. directly,
instead of going through PyMem_Malloc, etc. This means the memory
allocated by those APIs won't be seen by tracemalloc. Is it deliberate?
Am I missing something?
Regards
Antoine.
___
Hello everyone,
I just wanted to highlight the point made by Charles, it would be great if
he would clarify any mistakes in the points that I put forward.
Quoting the documentation,
In versions of NumPy prior to 1.7, this function always returned a
new,independent array containing a copy of the
