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