[SciPy-dev] scipy.distance

[Damian Eads]

Voronoi membership images seem like a good feature to have in there as
well. What do you think?

Damian

On Sun, Nov 2, 2008 at 11:02 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Sun, Nov 2, 2008 at 10:03 PM, Anne Archibald <aarchiba at physics.mcgill.ca>
> wrote:
>>
>> 2008/11/2 Jarrod Millman <millman at berkeley.edu>:
>> > On Sun, Nov 2, 2008 at 4:47 PM, Damian Eads
>> > <damian.eads.lists at gmail.com> wrote:
>> >> I had a chance to peruse the code in the spatial branch, and it looks
>> >> like there are a considerable number of tests for the kd-tree code. It
>> >> seems mature enough for it to be incorporated into the 0.7 release as
>> >> a technology preview. I think we should move that code over into the
>> >> trunk too, since this will give us more feedback from early adopters
>> >> and testers so we can better refine. It should also be noted, we are
>> >> changing the module index in the documentation to indicate those
>> >> modules/packages that are part of the technology preview.
>> >
>> > +1
>> > I think that it would be better to get the kd-tree code out in this
>> > release, but clearly mark it as a technology preview.  This will give
>> > us the opportunity to get more feedback and testing without any major
>> > restrictions on improving the API.  I know that there was some
>> > concerns that including new code could slow down the release of 0.7,
>> > but I don't think that has to be the case.  Since it is a technology
>> > preview and isn't changing current behavior; as long as it compiles
>> > and doesn't create a lot of noise for testing, I don't think I will be
>> > necessary to delay the release for it.
>> >
>> > Thoughts?
>>
>> I think for computing nearest neighbors of points, the code is
>> basically done. For other applications, well, it's not yet clear what
>> other applications people want. One aspect I do expect will change is
>> the API: there are many applications where a kd-tree is a useful data
>> structure (beyond simple point nearest neighbor), but for most of them
>> one needs to write a custom tree traversal and possibly annotate the
>> tree. I'm not sure how to set the kd-tree code up so that it can
>> easily (and efficiently) be used for that, but I think the only way to
>> find out is for users to actually go ahead and try to do it.
>
> I usually want a complete list of points in some neighborhood. I looked
> through your cython code and I think the loops can be improved a bit to make
> better use of low level C code.
>
> I'm working on some cover tree code with an eye to future inclusion unless
> someone beats me to it.
>
> Chuck
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>



-- 
-----------------------------------------------------
Damian Eads                             Ph.D. Student
Jack Baskin School of Engineering, UCSC        E2-489
1156 High Street                 Machine Learning Lab
Santa Cruz, CA 95064    http://www.soe.ucsc.edu/~eads