-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Python binding #52
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jschueller,
Thank you very much for this PR. This is a great work.
I put some comments in the files, they sometimes refer to different lines in the files. Let me know if some are not clear.
Cheers,
Tom.
Hi @jschueller , Thank you for your immense efforts again! I am totally ignorant about Python. So I could only give very rough comments, which may very likely be wrong. I am open to discussions.
Many thanks for everything! Also thank Tom @ragonneau for looking into this PR. Our opinions are similar in most cases thanks to our long-term collaboration. Best regards, |
|
Sorry, I do not think we are talking about the same thing --- we are talking about the opposite. The first and foremost goal of the Python binding should be integrating the Fortran version of Yes, there will be eventually a Python implementation, but I do foresee a mature Python implementation will be possible in the near future (e.g., within 2 years, if not longer) given the high complexity of these algorithms. However, the community should not continue to use the buggy F77 version for such a long time. I have worked on these solvers in all the details, so I know how hard they are. As a reference, Tom has been developing a solver of the same kind named COBYQA for exactly two years (the first commit was on 2 Sept 2021), full time. Tom is quite capable and diligent, but I do not think COBYQA is mature yet (sorry Tom, it is close). In addition, a new implementation should go through extensive verification and tests before it is safe to use in production (recall how many users SciPy has), which will take time. That said, the Fortran-Python binding is quite important. It is not something temporary. For the interest of the SciPy community, the pure Python implementation will have to achieve the same performance and robustness as the modern Fortran version before it takes the place of the latter. Thanks. |
Probably we are not talking about the same thing again. What I mean is the building system for compiling the Fortran code and making it callable in Python. The SciPy community has announced that they will move to Meson (see also comments from the Fortran community). We have to use Meson as the building system for the Python binding if we want it to be accepted by SciPy. Thanks. |
we dont have to move to meson, integrating into scipy will consist in copying the sources there into their own build system, and even if we moved to meson I doubt much would be reusable anyways. |
Sorry, I believe this matters a lot, especially to the SciPy maintainers. A mixture of Fortran and Python is already considered unpleasant. Getting another language involved will make things much more complicated --- maybe not to ourselves, but remember that other people may have to maintain our code in the (not very far) future. Above all, it is not necessary to traverse the C interface if Python wants to communicate with iso_c_binding Fortran subroutines. So I do not see why the C interface should be invited into the play.
Is it the compiled version or the source code that has to be moved? Thanks. |
Sorry, this is beyond my knowledge again. So we do not need to provide or contribute to the building facility that "compiles the Fortran code and makes it callable in Python", in order to get Python binding integrated into SciPy? I thought preparing such a building system and ensuring it works on all platforms was the most challenging part. |
I guess all the c/bobyqa_c.f90, c/cintrf.f90, ... source files should be moved to /fortran, else the wont be compiled into libprimaf.so and in turn we wont be able to use it in the Python layer instead of libprimac.so like it is done now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check-spelling found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Comments by @andyfaff, copied from scipy/scipy#18118
|
temporarily delete other tests Please remember to get them back before we merge the PR :) Thank you. |
This comment has been minimized.
This comment has been minimized.
Hi @jschueller Julien, This is for your reference: https://github.com/orgs/libprima/discussions/79 . I suppose we are currently working on the basic interface defined there, which will be sufficient for the inclusion of PRIMA in SciPy. Thanks. |
This comment has been minimized.
This comment has been minimized.
yes, lets keep things things basic here |
Thank you @jschueller Julien for the huge efforts! This is very nice. Things I have noted
I am ignorant about Python, so @ragonneau Tom please review. |
This comment has been minimized.
This comment has been minimized.
|
So this interface is not for the integration with SciPy? |
its a basic layer, including in scipy will require more functions on top of that |
Will this binding include such functions as well? |
no, just the api will change |
Sorry, I did not get it. Could you elaborate a bit more? How will it change, and how will that facilitate the integration with SciPy? Thank you. |
No description provided.