Hi Ralf, Thanks for getting back to me. I'd also be interested in the comparison between scikit-spatial and

scipy.spatial. It would probably be useful if you added that, as well as the SymPy comparison, to the readme of your repo and/or the first page of your docs.

From what I can see, there is no overlap between scipy.spatial functions and those in my package. Do you think my code could be added to scipy.spatial? I'd be happy to go that route instead of maintaining a scikit.

Thanks, Andrew On Fri, Apr 5, 2019 at 4:20 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:

Hi Andrew,

On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes@gmail.com> wrote:

...

Hello everyone,

I'm completing my master's in computer engineering, and it involved writing several functions for computations in 3D space, such as finding the line of best fit from multiple points and projecting a point onto a line. I decided to package my code into 'scikit-spatial', which provides objects for points, vectors, lines and planes, and computations between them.

Looks interesting.

...

I know SymPy has similar objects in their geometry package, but my package is based on NumPy for the objects and computations. The Point and Vector objects are actually subclasses of the NumPy ndarray.

I'd also be interested in the comparison between scikit-spatial and scipy.spatial. It would probably be useful if you added that, as well as the SymPy comparison, to the readme of your repo and/or the first page of your docs.

...

It's my first Python package, so any feedback or contributions would be greatly appreciated. The code is at https://github.com/ajhynes7/scikit-spatial.

I apologize if this is the wrong mailing list to post this. The "Scikits" page (https://www.scipy.org/scikits.html) just says "It can however be useful to let people know about it by discussing the new project e.g. on the Scipy mailing lists.", but it doesn't specify which one. Maybe the website can be edited to specify a mailing list for future reference?

Yeah, that website needs some maintenance. An announcement and first discussion here is fine. If there's regular discussion happening going forward, then it would be good to set up a dedicated list (very easy with Google Groups for exampple).

Cheers, Ralf

...

Thanks,

Andrew Hynes _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

I'm not sure. Features like the intersections between planes seems to be similar in nature to the scipy.spatial.rotation or https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.Ha.... I'm not an expert though and don't have much of a vision what does and does not belong in scipy.spatial. So I'll let others answer that question.

Ok, I will ask. Should I start a new thread on this mailing list or make a pull request on github? Andrew On Sun, Apr 7, 2019 at 2:07 PM Ralf Gommers <ralf.gommers@gmail.com> wrote:

On Sat, Apr 6, 2019 at 4:05 PM Andrew Hynes <andrewjhynes@gmail.com> wrote:

...

Hi Ralf,

Thanks for getting back to me.

I'd also be interested in the comparison between scikit-spatial and

...

scipy.spatial. It would probably be useful if you added that, as well as the SymPy comparison, to the readme of your repo and/or the first page of your docs.

From what I can see, there is no overlap between scipy.spatial functions and those in my package. Do you think my code could be added to scipy.spatial?

I'm not sure. Features like the intersections between planes seems to be similar in nature to the scipy.spatial.rotation or https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.spatial.Ha.... I'm not an expert though and don't have much of a vision what does and does not belong in scipy.spatial. So I'll let others answer that question.

Cheers, Ralf

...

I'd be happy to go that route instead of maintaining a scikit.

Thanks,

Andrew

On Fri, Apr 5, 2019 at 4:20 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:

...

Hi Andrew,

On Thu, Apr 4, 2019 at 11:29 PM Andrew Hynes <andrewjhynes@gmail.com> wrote:

...

Hello everyone,

I'm completing my master's in computer engineering, and it involved writing several functions for computations in 3D space, such as finding the line of best fit from multiple points and projecting a point onto a line. I decided to package my code into 'scikit-spatial', which provides objects for points, vectors, lines and planes, and computations between them.

Looks interesting.

...

I know SymPy has similar objects in their geometry package, but my package is based on NumPy for the objects and computations. The Point and Vector objects are actually subclasses of the NumPy ndarray.

I'd also be interested in the comparison between scikit-spatial and scipy.spatial. It would probably be useful if you added that, as well as the SymPy comparison, to the readme of your repo and/or the first page of your docs.

...

It's my first Python package, so any feedback or contributions would be greatly appreciated. The code is at https://github.com/ajhynes7/scikit-spatial.

I apologize if this is the wrong mailing list to post this. The "Scikits" page (https://www.scipy.org/scikits.html) just says "It can however be useful to let people know about it by discussing the new project e.g. on the Scipy mailing lists.", but it doesn't specify which one. Maybe the website can be edited to specify a mailing list for future reference?

Yeah, that website needs some maintenance. An announcement and first discussion here is fine. If there's regular discussion happening going forward, then it would be good to set up a dedicated list (very easy with Google Groups for exampple).

Cheers, Ralf

...

Thanks,

Andrew Hynes _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

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@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev

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@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@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@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

Hello Tyler, Thanks for your detailed comments. I'll keep working on the scikit for now, but if I find something that I think meets the criteria you mentioned, I can start a new thread on this mailing list to ask about adding it to scipy. That ability with are_collinear() sounds very useful, but unfortunately I don't know how it could be done. Regards, Andrew On Sat, Apr 27, 2019 at 4:30 PM Tyler Reddy <tyler.je.reddy@gmail.com> wrote:

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@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@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@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@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev