TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

SciPy: Interested in adopting PRIMA, but little appetite for more Fortran code

126 pointsby zaikunzhangabout 2 years ago

10 comments

bouchardabout 2 years ago
I understand the lack of appetite for old FORTRAN 77 code, but PRIMA is a modern Fortran implementation.<p>You only need Python&#x27;s ctypes module to load the compiled Fortran library thanks to Fortran&#x27;s iso_c_binding module.<p>Using f2c as suggested seems like a worse alternative, not a solution.
评论 #35990463 未加载
评论 #35989064 未加载
adastra22about 2 years ago
This is crazy. Get over yourself! Whether you like it or not, Fortran is still THE industry standard for scientific codes, and the fastest compiled language on many architectures.
评论 #35989615 未加载
评论 #35992351 未加载
domcoltdabout 2 years ago
Hopefully, the SciPy community can stay open-minded about modern Fortran libraries.<p>Modern Fortran is quite different from Fortran 77, while being as powerful, if not more.<p>In addition, there has been a significant community effort on improving and modernising the legacy packages, the ecosystem, and the language itself.<p>With projects like LFortran (<a href="https:&#x2F;&#x2F;lfortran.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lfortran.org&#x2F;</a>), fpm (<a href="https:&#x2F;&#x2F;github.com&#x2F;fortran-lang&#x2F;fpm">https:&#x2F;&#x2F;github.com&#x2F;fortran-lang&#x2F;fpm</a>), and stdlib (<a href="https:&#x2F;&#x2F;github.com&#x2F;fortran-lang&#x2F;stdlib">https:&#x2F;&#x2F;github.com&#x2F;fortran-lang&#x2F;stdlib</a>), I believe that Fortran will enjoy prosperity again.
评论 #35993622 未加载
评论 #35993509 未加载
zaikunzhangabout 2 years ago
see also<p>Optimization Without Derivatives: PRIMA Fortran Version and Inclusion in SciPy, <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35959991" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35959991</a><p>SciPy enhancement: The Fortran 77 implementation of COBYLA is buggy and challenging to maintain. Switch to the PRIMA implementation? #18118, <a href="https:&#x2F;&#x2F;github.com&#x2F;scipy&#x2F;scipy&#x2F;issues&#x2F;18118#issuecomment-1552057125">https:&#x2F;&#x2F;github.com&#x2F;scipy&#x2F;scipy&#x2F;issues&#x2F;18118#issuecomment-155...</a>
tomr_stargazerabout 2 years ago
I thought that the PRIMA developer’s comment in this thread was really mature and thoughtful. Reproduced below (minus some formatting):<p>&gt; My goal is to make Professor Powell 12’s solvers as accessible as possible to scientists, engineers, and algorithm researchers. I am not particularly in favor of or against any language. I hope that everyone can easily use Powell’s solvers in her&#x2F;his favorite languages.<p>&gt; The first implementation of PRIMA is in modern Fortran simply because Powell’s implementation was in Fortran 77. Using Fortran, I can systematically verify the bit-to-bit faithfulness of the modernized implementation (not only “faithful up to an epsilon”). In addition, the intrinsic support for matrix-vector calculations is a strong advantage when developing reference implementations (or templates) of numerical solvers — most numerical algorithms are combinations of such calculations anyway.<p>&gt; The major motivation for developing the modern Fortran version is to provide a reference for the implementation in other languages, namely Python, MATLAB, C++, Julia, and R. A reference implementation must be structured, modularized, readable, understandable, and extendable. The original Fortran 77 code is a true masterpiece, but it is not proper at all for being used as a reference implementation. You do not want to use a spaghetti-style codebase with 244 GOTOs as a reference, or your implementation will be of the same style.<p>&gt; Putting it more straightforwardly, I implemented the modern-Fortran version of PRIMA in order to develop versions that are entirely Fortran-free 3.<p>&gt; Coming back to the point, I fully understand why the SciPy community has “little appetite for taking on more Fortran code”. The reputation of Fortran has been damaged over the years. I do not agree with the damaged reputation, and I feel sorry for those who do not have a chance to know (or refuse to know) modern Fortran due to this false reputation, but I do not blame them. It is the responsibility of the Fortran community to re-establish the reputation. I do not regard it as a bully to request non-Fortran implementations. It is not a question of surrendering or not.<p>&gt; I do consider myself a member of the Fortran community. Taking my share of the aforementioned responsibilty, I will try to promote the usage of modern Fortran via the PRIMA project. There is nothing more convincing than a successful real-life project.<p>&gt; For the inclusion of PRIMA in SciPy, I will keep communicating with both the SciPy and the Fortran community (e.g., those on this discourse), trying to find the best route. As pointed out by others, f2c is not an option due to its incapability of handling modern Fortran. Official C++ and Python implementations are being planned, but they will not be delivered in the near future. The most probable and practical solution, as suggested here and under the other thread, is to wrap the modern Fortran implementation of PRIMA using iso_c_bindings + ctypes or similar facilities. I hope the SciPy maintainers will accept this solution.
评论 #35990360 未加载
评论 #35991926 未加载
whinvikabout 2 years ago
Even though it&#x27;s not great but I understand why this maybe the direction SciPy maintainers want to go in. They have limited capacity and I think focusing on a single language makes sense especially if there are way more developers in that language, C.<p>One way to solve this would be of course, to have more people from the Fortran community being part of the SciPy community. But I don&#x27;t know how big the Fortran community really is to be able to do that.
评论 #35997649 未加载
cozzydabout 2 years ago
Looking at the original issue, scipy maintainers don&#x27;t want to use LGPL code (why?!?) but they use code that appears in Numerical Recipes (which has super onerous licensing)?!?
评论 #35992723 未加载
ChrisRackauckasabout 2 years ago
Interesting response. I develop the Julia SciML organization <a href="https:&#x2F;&#x2F;sciml.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sciml.ai&#x2F;</a> and we&#x27;d be more than happy to work with you to get wrappers for PRIMA into Optimization.jl&#x27;s general interface (<a href="https:&#x2F;&#x2F;docs.sciml.ai&#x2F;Optimization&#x2F;stable&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.sciml.ai&#x2F;Optimization&#x2F;stable&#x2F;</a>). Please get in touch and we can figure out how to set this all up. I personally would be curious to try this out and do some benchmarks against nlopt methods.
radarsat1about 2 years ago
I wonder why not just try to use more Pythonic solutions such as numba within scipy. I realize that maybe not in all cases can the same performance as Fortran be achieved but it strikes me as much more hackable for Python programmers than having to learn an new (old) language just for certain core algorithms. One of the principal reasons for switching to C implementations is because more people understand C than Fortran. This seems doubly true for Python-based jit solutions like numba or jax, so why not just skip C altogether and go for a more native port?
评论 #35989577 未加载
评论 #35988672 未加载
travisporterabout 2 years ago
Who is this insane developer who links twitter to every text selection on this page!@