John, I think we really need copy (and maybe deepcopy)
> functions that work with all transforms, not just Separable
> transforms. This looks fairly easy except for one thing:
> the transform creation functions return objects that don't
> provide any clean way of distinguishing among the types of
> transform. type(trans) reports <type 'Affine'>, regardless
I've seen this, I thinki it's a problem with pycxx but am not sure
> of what kind of transform it really is. I have not been
> able to figure out where this is coming from. One can't
> cleanly use hasattr(funcxy) to detect a Nonseparable
> transform because all transforms have the attribute, whether
> they use it or not. I could use "try: trans.get_funcxy()"
Again, this is a problem with pycxx. You cannot do inheritance where
B and C inherit some methods from A unless all methods are in A, B and
C. It's ugly but that is the way it is for now. So I define all the
methods in the base class and raise if they are not available.
Unfortunately, pycxx is not actively developed so I doubt this will
change .
> and catch the exception, but that is ugly. (And the second
> time I tried it, it hung ipython.)
> I suspect you have thought about this already--do you have
> any suggested solutions? Is there at least a simple way to
> get type(trans) to work right? From the code it looks like
> it should, so there appears to be a bug in the code or in
> cxx.
The best way may be for the extension code to provide a shallowcopy
method and require derived transform classes to implement it. All
references will be preserved, but a new object will be created.
We only need this for SeparableTransformation and
NonseparableTransformation but the methods will also have to be
defined virtually in the base classes.
We have to think about what should be preserved in the shallow
copies. For the use case at hand, we want to preserve the references
to the values but not the offset transform.
I'm not so sure that deepcopy is really needed. I can't think of a
use case off hand.
As I respond, I wonder if we are applying the right solution to the
wrong problem. I think these changes are worth doing because they are
easy and work with the existing code and are useful. But in the
longer run, I think the offsets, while useful, can be better
accomplished by developing a transform chain as Jouni suggested.
Normal affine multiplication doesn't work since the transformations
may be nonlinear. But we should be able to do something like (here in
python but this would probably be in the extension code)
class CompositeTransform:
def __init__(self, transforms):
self._transforms = transforms
def xy_tup(self, xy):
for transform in self._transforms:
xy = transform.xy_tup(xy)
return xy
Removing the offset transforms would break internal and external code,
but would probably be a cleaner solution in the long run.
JDH