>>>>> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
Eric> John, I think we really need copy (and maybe deepcopy)
Eric> functions that work with all transforms, not just Separable
Eric> transforms. This looks fairly easy except for one thing:
Eric> the transform creation functions return objects that don't
Eric> provide any clean way of distinguishing among the types of
Eric> transform. type(trans) reports <type 'Affine'>, regardless
I've seen this, I thinki it's a problem with pycxx but am not sure
Eric> of what kind of transform it really is. I have not been
Eric> able to figure out where this is coming from. One can't
Eric> cleanly use hasattr(funcxy) to detect a Nonseparable
Eric> transform because all transforms have the attribute, whether
Eric> 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 .
Eric> and catch the exception, but that is ugly. (And the second
Eric> time I tried it, it hung ipython.)
Eric> I suspect you have thought about this already--do you have
Eric> any suggested solutions? Is there at least a simple way to
Eric> get type(trans) to work right? From the code it looks like
Eric> it should, so there appears to be a bug in the code or in
Eric> 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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
