Python operator implementation

Issue #25 resolved
Sam Preston created an issue

While using things like Add_I forces us to think about memory usage, there are plenty of instances where this is just painful and hard to read. We should definitely implement the unary operators +=, *=, etc (there's no downside since no new memory is needed), and should probably have binary operators implemented as long as python can correctly handle the memory. For large projects we should still stick with e.g. Add(...) and scratch vars for better memory management, but for prototyping or testing we can use the simpler syntax.

Comments (6)

  1. Sam Preston reporter

    OperImpl branch has been committed which implements some example operations. Also, to make swig stuff easier, there is now only a single swig-generated library named _PyCA_Core.so instead of a separate alg, math, types, etc. Unfortunately this caused the texture memory based functions to break again (see bug #9), so I just switched to the non-texture versions of these functions (just the Apply* operators in GImageFieldOpers)

  2. Caleb Rottman

    I think this is a great idea - will make code much more readable. Why would using Add_I be necessary? Wouldn't that be implemented exactly like += ?

  3. Jacob Hinkle

    This is pretty cool! It will be great for typing up quick prototypes. Compound statements get slow because you use a lot of temporary memory and copies that could be avoided (for instance like how Add_MulC_I avoids allocating anything). Still I think having the operators there is definitely useful and I'd probably use them by default in the non-compound cases.

    Now here's a thought. To improve the memory just slightly, what about having some sort of global memory stash (like a global MemoryManager) that's just for temps created in these compound arithmetic statements. It'd be almost as fast as the combined kernels I would imagine, if you had enough memory, and would allocate more if necessary.

  4. Log in to comment