[SciPy-dev] [Numpy-discussion] Proposal: scipy.spatial

[Anne Archibald]

2008/10/1 Prabhu Ramachandran <prabhu at aero.iitb.ac.in>:
> Anne Archibald wrote:
>> 2008/9/30 Peter <numpy-discussion at maubp.freeserve.co.uk>:
>> I think the profusion of different implementations is an argument for
>> including this in scipy. I think it is also an argument for providing
>> a standard interface with (at least potentially) several different
>> implementations. At the moment, that proposed interface looks like:
> [...]
>> In the first two cases, missing neighbors are represented with an
>> infinite distance and an invalid index. In the last case, distances
>> and indices are both either lists (if there's only one query point) or
>> object arrays of lists (if there are many query points). If only one
>> neighbor is requested, the array does not have a dimension of length 1
>> in the which-neighbor position. If (potentially) many neighbors are
>> returned, they are sorted by distance, nearest first.
>>
>> What do you think of this interface?
>
> This is nice.  How about a keyword argument "sort=True" that lets people
> choose if they want the results sorted by distance or not?  I have seen
> cases where unsorted results are useful.

That is a possibility. My current code produces results that are in a
heap, so sorting can in principle be an O(n) activity. Since the
number of results returned is rarely going to be large, I'm not sure
the gain in efficiency is worth the loss in determinism. And
additional API complexity does have a cost - in an ideal world it
should at the least double the number of unit tests. I think perhaps
this should wait on a C implementation.

Anne