you're actually using a different implementation you may see a different
> behavior.
> - CPython deals with small objects in a special way, not actually
> releasing allocated memory. For more info:
> http://deeplearning.net/software/theano/tutorial/python-memory-management.html#inter
eported as free.
I'll just assume that everything is in order and carry on. Thanks!
Austin
On Tue, Nov 13, 2012 at 9:41 AM, Nathaniel Smith wrote:
> On Tue, Nov 13, 2012 at 8:26 AM, Austin Bingham
> wrote:
> > I'm trying to understand how numpy decides when to release me
I'm trying to understand how numpy decides when to release memory and
whether it's possible to exert any control over that. The situation is that
I'm profiling memory usage on a system in which a great deal of the overall
memory is tied up in ndarrays. Since numpy manages ndarray memory on its
own
>> they'd likely crash.
>
> Really?
I base that on the assumption that they'd not know to call
import_array() in that translation unit. This seems like a reasonable
assumption because, by defining the macros as such, they are strongly
implying that they expect the API functions to be imported for
> I still don't understand why you cannot just include the header file as
> is (without defining any of NO_IMPORT/PY_ARRAY_UNIQUE_SYMBOL).
I guess the real point is that no matter what definition (or lack
thereof) that I have for these macros, I still introduce header order
dependencies to users o
On Tue, May 4, 2010 at 7:05 AM, David Cournapeau wrote:
> On Mon, May 3, 2010 at 7:23 PM, Austin Bingham
> wrote:
>> Hi everyone,
>>
>> I've recently been developing a python module and C++ library in
>> parallel, with core functionality in python and C++ la
Hi everyone,
I've recently been developing a python module and C++ library in
parallel, with core functionality in python and C++ largely just
layered on top of the python (with boost.python.) In some cases,
however, for performance reasons, the C++ API "reaches into" the
python code via the C API
