[SciPy-Dev] [ANN] Release of scikit-spatial package

[Tyler Reddy]

One more follow-up thought -- are_collinear() appears to provide a simple
bool return value for a set of coordinates in your Points class. But what
if you had an array of 2 million points and you wanted to know the
*indices* of *any* points that were collinear with any other?

That might be interesting if it could be done more efficiently than brute
force? Then you could exclude said collinear points and feed them into a
comp geo algorithm. Someone must have thought of this already.



On Fri, 26 Apr 2019 at 16:04, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> I've thought a little more about this. I didn't come up with a great first
> choice for migrating functionality into scipy.spatial just yet, but this
> was my thought process for one of your methods, are_collinear():
>
> - the boolean return value may be useful for assessments of general
> position in computational geometry, for rejection of array input to other
> algorithms / functions by fiat
> - the main problem is that the algorithm is effectively a NumPy one-liner
> on array-input: numpy.linalg.matrix_rank(input) <= 1
> - before I realized that, I also considered how you might transplant it if
> relative simplicity were not an issue for a new public SciPy function
> - I would suggest avoiding the object-oriented / ndarray subclassing
> approach used in the scikit & matching our scipy.spatial distance-style
> approach which generally takes an array-like into a simple function &
> operates on it / returns something directly; avoiding ndarray subclassing
> will probably reduce the controversy of a PR
>
> So, not sure how helpful that is. I think the initial assessment on
> collinear is: 1) very useful; but 2) perhaps a little too simple to justify
> an exposed / new SciPy function?
>
> Perhaps that evaluation strategy (usefulness + non-trivial implementation;
> avoiding ndarray subclasses) may help you select the right candidate for
> migrating over to SciPy? Others may have different thoughts though.
>
> On Wed, 10 Apr 2019 at 19:17, Andrew Hynes <andrewjhynes at gmail.com> wrote:
>
>> Hello Tyler,
>>
>> Some of the algorithms might be suitable for inclusion. Probably easier
>>> if there's a nice paper / source for algorithm citation and it is clear
>>> that we don't already have the functionality somewhere in SciPy.
>>>
>>
>> My main reference for the functions has been
>> http://mathworld.wolfram.com/. Some of the docstrings have a link to the
>> relevant webpage.
>>
>> I'd like to try making a pull request for scipy.spatial. Is there an area
>> of scikit-spatial that you think would be best to start?
>>
>> Also, would you prefer that the code is not object-oriented? For example,
>> the collinearity function is a method of the Points class, but I can adapt
>> it to be a regular function that takes a 2D ndarray as input. Or if you're
>> fine with the object oriented style, I can work on a pull request to
>> include the Point and Vector classes, which could be imported from a
>> scipy.spatial.objects module.
>>
>> Thanks,
>>
>> Andrew
>>
>>
>> On Tue, Apr 9, 2019 at 2:05 PM Tyler Reddy <tyler.je.reddy at gmail.com>
>> wrote:
>>
>>> Some of the algorithms might be suitable for inclusion. Probably easier
>>> if there's a nice paper / source for algorithm citation and it is clear
>>> that we don't already have the functionality somewhere in SciPy.
>>>
>>> To give one example, just browsing through, I see a collinearity
>>> algorithm. Since collinearity is often used in the assessment of general
>>> position prior to embarking on an algorithm in computational geometry,
>>> it may be sensible to check if the low-level library we vendor for many
>>> comp geo routines (Qhull) has a routine for this. Even if it does, it might
>>> not be easy to expose directly, but it is a consideration I think.
>>>
>>> Some of the operations, if ultimately suitable for inclusion, may fit in
>>> the scipy.spatial.transform namespace, but probably case-by-case basis is
>>> best in terms of assessing broad interest in the algorithm
>>> and its suitability for inclusion.
>>>
>>> On Mon, 8 Apr 2019 at 16:08, Andrew Hynes <andrewjhynes at gmail.com>
>>> wrote:
>>>
>>>> Hi Stéfan,
>>>>
>>>>> This looks neat!  It reminds me a bit of the following book which I
>>>>> enjoyed:
>>>>>
>>>>> http://www.geometricalgebra.net/
>>>>>
>>>>
>>>> Thanks for the link - it looks like a good source for expanding the
>>>> package.
>>>>
>>>> Can you tell us a bit more about how you see these functions typically
>>>>> being applied in practice?
>>>>>
>>>> Sure, I can give an example from my masters project. It involved
>>>> clinical gait analysis with a depth camera, so I used some of these
>>>> functions to calculate gait parameters from positions in space.
>>>>
>>>> A basic walking stride consists of three positions: The initial swing
>>>> foot, the stance foot, and the final swing foot. The stride length is the
>>>> distance from the initial to final swing foot. The stride width is the
>>>> length of the projection from the stance foot to the swing path (the line
>>>> from the initial swing foot to the final).
>>>>
>>>> Here's a snippet of code using scikit-spatial to calculate gait
>>>> parameters from three points: point_a_i (initial swing foot), point_b
>>>> (stance foot), and point_a_f (final swing foot).
>>>>
>>>> from skspatial.objects import Vector, Line
>>>>
>>>> vector_a = Vector.from_points(point_a_i, point_a_f)
>>>> line_a = Line(point=point_a_i, direction=vector_a)
>>>>
>>>> point_b_proj = line_a.project_point(point_b)
>>>>
>>>> stride_length = vector_a.norm()
>>>> absolute_step_length = Vector.from_points(point_b, point_a_f).norm()
>>>> step_length = Vector.from_points(point_b_proj, point_a_f).norm()
>>>> stride_width = line_a.distance_point(point_b)
>>>>
>>>>
>>>> Hopefully that gives an idea as to how the package can be used.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew
>>>>
>>>> P. S. Great job on scikit-image!
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190426/0a10d3c2/attachment-0001.html>