Python operator implementation
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)
-
reporter -
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 += ?
-
reporter (Reply via js...@sci.utah.edu):
Yes, sorry, that should just be Add.
On Wed, Feb 6, 2013 at 10:51 AM, Caleb Rottman issues-reply@bitbucket.org wrote:
-
reporter - edited description
-
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.
-
reporter - changed status to resolved
Merged in OperImpl (pull request #6)
Operator implementation
Implementation of basic math operators for PyCA types Image3D, Field3D, and Vec3D[i,f].
This closes issue
#25→ <<cset 9ad22395fb72>>
- Log in to comment
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)