You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just wanted to know if it would be possible to package the code for the FFTFIT algorithm bundled with PRESTO into a separate Python package under the MIT License? PRESTO already uses f2py to bind the code to Python, but I thought it would be nice to have it as a small Python package that is independent of PRESTO's Python installation. Is it fine if I go ahead with this? I thought this might also be useful for other software, like PINT (ref: nanograv/PINT#231; while they have implemented a native implementation for FFTFIT here: nanograv/PINT#777, I still think it would be nice to have a separate package, because it could be used to test their implementation against the original code as well).
The text was updated successfully, but these errors were encountered:
That's great @scottransom 👍🏾 ! I have already started the work here: https://github.com/astrogewgaw/fftfit. Currently the code installs without a hitch (at least on my machine) and does what I think it should. I am using the same method that PRESTO uses to bind the code to Python, via f2py and numpy.disutils. There is a single method on the Python side, also called fftfit, that is just a renamed form of the measure_phase function from the get_TOAs.py script. Right now the code is just licensed in my name, but feel free to tell me how I should change that appropriately to give credit where it is due 😅 . The repo is open to pull requests, if you want to contribute any of the changes directly. Thanks for both the prompt response, and the re-licensing 😁 !
I just wanted to know if it would be possible to package the code for the
FFTFIT
algorithm bundled withPRESTO
into a separate Python package under the MIT License?PRESTO
already usesf2py
to bind the code to Python, but I thought it would be nice to have it as a small Python package that is independent ofPRESTO
's Python installation. Is it fine if I go ahead with this? I thought this might also be useful for other software, likePINT
(ref: nanograv/PINT#231; while they have implemented a native implementation forFFTFIT
here: nanograv/PINT#777, I still think it would be nice to have a separate package, because it could be used to test their implementation against the original code as well).The text was updated successfully, but these errors were encountered: