Python bindings for libkdtree: FIX of find_within_range...
Willi Richert
w.richert at gmx.net
Fri Mar 20 09:36:41 UTC 2009
Hi Gajda and Paul,
thanks for the testcase and the bugfix! We really should include this test
case for all the classes.
There is one thing, though. You use COORD_T for the range, which will pose
problems for non-float types, as the following test case shows:
def test_count_within_range(self):
nn = KDTree_2Int()
for p in [(0,0), (1,0), (0,1), (1,1)]:
print "add",p
nn.add((p, id(p)))
print "count"
res = nn.count_within_range((0,0), 1.0)
self.assertEqual(3, res, "Counted %i points instead of %i"%(res, 3))
print "count"
res = nn.count_within_range((0,0), 1.9)
# here it will break, as 1.9 is saved as int => 1.0
self.assertEqual(4, res, "Counted %i points instead of %i"%(res, 4))
It turns out that I have to rewrite some swig stuff. I will send the patch for
py-kdtree.i if I have finished it and then we can include Gajda's patch.
One more thing: The current state of having one explicit template realization
in the python/swig part annoys me a little bit. Some weeks ago there was a
discussion on the ML about whether or not dynamically supporting the
specification of the dimension and type. How is the status here, Paul? If you
have decided against it, I will provide a python file that generates all the
stuff for float, double and int for dim \in [1, .., 20]. That will ease the
maintenance a lot. In the other case the situation for the python bindings
will be much smoother. But the performance will maybe suffer. Can you shed
some light on this decision, Paul?
Regards,
wr
On Freitag 20 März 2009 00:45:09 Paul Harris wrote:
> What do you think of this, Willi ?
>
> On 19/03/2009, Gajda Michal <mgajda at embl-hamburg.de> wrote:
> > Dear Paul, Willi,
> >
> > Thanks a lot for your work on libkdtree, and especially Python bindings.
> > I'm using them and they work great for me.
> >
> > The thing that I found doesn't seem to work was find_within_range
> > routine. I attach a patch that seems to fix the situation. The problem
> > was both with TREE_T::distance type that seems to have no typemap to
> > Python types, and returning vector as a structure, not a pointer, which
> > also seems to give back an error.
> >
> > The corresponding error I've seen was:
> > In:
> > kdtree_structure.find_within_range((1,2,3), 2)
> > File
> > "/home/gajda/apps/site-python/lib/python2.5/site-packages/kdtree.py",
> > line 154, in find_within_range
> > def find_within_range(*args): return
> > _kdtree.KDTree_3Float_find_within_range(*args)
> > TypeError: in method 'KDTree_3Float_find_within_range', argument 3 of
> > type 'PyKDTree< 3,float,unsigned long long >::TREE_T::distance_type'
> >
> > The attached patch seems to fix it.
> > Unit test is made only for KDTree_6Float case. If you like this, I can
> > fill the remaining cases?
> > --
> > Best regards
> > Michal
<
More information about the libkdtree-devel
mailing list