On Fri, Oct 17, 2008 at 10:25 PM, Michael George
<mdgeorge@xxxxxxxxxxxxxx> wrote:
Here are the files. It turns out the actual convolution is much simpler than the one I sent out before, since I learned about the bitmask_draw method and just use that internally. It might be slightly slower, but it's more likely to be correct.
As I was coding it up, I realized I'm still not completely happy with the interface. Which of the following two possibilities do people prefer?
== Option 1 ==
Mask.convolve(othermask, outputmask = None, offset = (0,0)): return Mask
Returns a mask with the (i-offset[0],j-offset[1]) bit set if shifting othermask
so that it's lower right corner pixel is at (i,j) would cause it to overlap
with self.
If outputmask is not None, then the output is drawn onto outputmask and
outputmask is returned. Otherwise a mask of size self.get_size() +
othermask.get_size() - (1,1) is created.
== Option 2 ==
Mask.convolve(othermask, outputmask, offset = (0,0)): return Mask
Sets the ((i, j) - offset) bit of outputmask if overlap(self, othermask, (i,j)) is true. Returns outputmask.
Mask.convolve(othermask): return Mask
Creates a mask just big enough to hold the convolution of self and other, and shifts the output so that it fits in the mask. Equivalent to
self.convolve(other, Mask(self.get_size() + othermask.get_size() - (1,1)), othermask.get_size() - (1,1))
====
The difference between the two is how the offset is treated. Both return the same result in the single-argument case, but Option 1 explains the multi-argument variant in terms of the single-argument variant, whereas Option 2 explains the single-argument variant in terms of the multi-argument invariant. I think Option 2 is simpler to explain/understand (the lower-right corner of Option 1 just screams "off-by-one"). Option 1 is slightly more flexible, because you can call it with 2 arguments, although I don't think there would be any reason to do that (except that the unit tests do that). Option 1 is implemented in this tarball, although it would be trivial to switch it to option 2 (and the code might even be infinitestimally nicer).
It's splitting hairs I know, but I figure the hairs should be split before the API becomes public.
--Mike
Nirav Patel wrote:
You can use the diff command to generate patches, but if its easier
for you, you can just upload or email the files you changed.
Nirav