AndrewAnnex / SpiceyPy

SpiceyPy: a Pythonic Wrapper for the SPICE Toolkit.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow np.ndarray inputs for subpnt, subslr, and pxform

medley56 opened this issue · comments

I often find myself writing np.vectorize calls to allow SpiceyPy functions to take vector inputs. I'd like to see this moved into SpiceyPy itself.

AFAIK, all array input handling is done on the Python side as CSPICE functions never accept array inputs. An example is spkezr, which loops through the array input values in Python, iteratively calling spkezr_c. However, not all wrappers have implemented this convenience.

There are many other routines which would benefit from this type of array input handling. As a start, I suggest pxform, subslr, and subpnt, possibly accepting user suggestions for others.

An alternative implementation could be to write a C extension library that performs these loops in C rather than python to improve performance but that would probably add a lot of additional installation and maintenance headache for @AndrewAnnex.

PR's are certainly welcome to add additional functions to accept arrays using the style we developed for spekezr but the speed ups are marginal relative to a simple for loop or using np.vectorize. I'd say these additions make easy PRs for me to accept, but they are relatively low priority for me to work on by myself as they only provide slight convenience. You can look at #192 #310 #317 and #324 for examples.

The other topic you raise is an important one but something that will take a lot more time and I want to see if I can apply to get funding for. Issue #363 sort of tracks this issue, I've found that the most likely way I will implement this is by using cython as it may simplify some of the other build tooling when combined with Cmake. But there is also a rust cspice library that could be wrapped with python. Other than these two ideas just implementing them as pure c files in the codebase could also work and present less of a headache, but I am trying to avoid memory management. Theoretically the NAIF could supply these also... In any case, dropping the loops to a lower level language is certainly of interest but it's tricky to do that and reuse the existing ctypes code at the same time.