Update on PRIMA: A Julia interface is available

I have made a few posts here about PRIMA, which is a package for solving general nonlinear optimization problems without using derivatives, providing the modern-Fortran reference implementation for Powell’s derivative-free optimization methods, i.e., COBYLA, UOBYQA, NEWUOA, BOBYQA, and LINCOA.

I am glad to mention that PRIMA now has a Julia interface.

In addition, a Python interface for the Fortran implementation of PRIMA and a native Python implementation are under development, both making remarkable progress.

In my opinion, one of the approaches to (re)popularizing Fortran is to produce quality modern-Fortran packages and make them available to users beyond the Fortran community. PRIMA represents such an effort.


Congrats on the progress, @zaikunzhang.

a native Python implementation of PRIMA are under development, both making remarkable progress.

My past efforts in having multiple project implementations natively in different programming languages have failed. The underlying reason for such failures was simple: As soon as there are two copies of a project in two different languages, they are guaranteed to diverge in functionality, interface, and implementation. Change is inevitable, and when it happens, it is practically impossible to keep multiple implementations in sync. I am convinced by experience that code duplication is pure evil, even within a single language. Despite all the negative comments here and there, in my experience, FPPs and wrappers are the only viable options to keep projects maintainable. I’d be eager to learn about your experience in this regard and others’ insights.


I agree with @shahmoradi, and can add that the last thing to want is to fix the same bug in multiple implementations. Indeed, having 1 reference implementation with multiple interfaces is the way to go.


I hope this were the case, and I understand the difficulty in maintaining several implementations.

However, unfortunately, people have repeatedly told me that they do not want to depend on libraries written in another language, (sometimes) in particular Fortran. A recent example is Including Powell's derivative-free optimization methods? · Issue #225 · robertfeldt/BlackBoxOptim.jl · GitHub.

It seems inevitable to me to have multiple implementations in different languages if I want to make the PRIMA solvers easily available to users in their favorite languages, which is the goal of the PRIMA project.

Unfortunately, this approach doesn’t look that succesful if at the end

Right. But Rome was not built in one day, I guess.

It is hard for me to see how the opposite of this approach (i.e., “do not produce quality modern-Fortran packages” OR “restrict the availability of good Fortran packages to the Fortran community only”) could help to repopularize Fortran. I am eager to learn if anyone could teach.

In addition, no matter how popular Fortran were, there would always be users who do not want to use it, not to mention that Fortran is not so popular (yet / anymore).

If you code for yourself only, you may simply ignore those people. But I develop software for others to use, which I hope is not a strange situation.

What really matters to me is that my package is easily available to its end users in their favorite languages. I do not have a preference for languages. Fortran was chosen due to historical reasons — it was not a choice made by me.


To be clear, this isn’t a purely ideological stance. Libraries written in Fortran are inherently limiting for higher level languages because they don’t work on types that Fortran doesn’t know how to deal with. Have a function that returns an array of posits? everything breaks. If the library was re-implemented in Julia? Everything now works.


This is a completely legitimate approach, and my comment was definitely not meant to be a negative critique of your choice to port your library to other languages (your work, your choice, anyway). I’m just saying that, as a matter of fact, it defeats the initial statement about repopularization of Fortran.

1 Like

That’s understandable. On the positive side, PRIMA focuses on one class of algorithms, and therefore I wouldn’t expect too much development once it’s completed, except for the occasional bug fix or nice to have feature. The other nice aspect is that it might serve as a Rosetta stone of how good codes should be written, and showcase the strengths and limitations of each language :slightly_smiling_face:

1 Like

Thank you @ricriv for your encouraging words.

This is a nice perspective that I have never thought about before. I will keep it in mind and make efforts in this direction.

1 Like

Sure, netizens of the computing world will do whatever and that will include duplication (and reinventing the wheel, etc.).

In the case of the topic here, such duplication will extend to “native” implementations in Python, Julia, etc. of codes written in other languages, especially FORTRAN and Fortran! It is absolutely silly, particularly when it comes to Python, but that’s just how it is.

But modern Fortran packages with well-designed APIs and performant code and with readiliy available and easy-to-use bindings with a few other languages and platforms including C, C++, Python, MATLAB, .NET (C#, Visual Basic), and increasingly Julia can minimize (but not prevent) code duplication. Basically these are the languages and platforms that rank high at Tiobe Index, IEES Spectrum survey on programming, etc. - “usual supects”

@zaikunzhang (and team?) have made strong attempts to establish this with their PRIMA effort - mega kudos to them in this regard.

But those in the Python, Julia, C++, etc. spaces will pursue duplication, and the more powerful and successful the algorithms are (such as with Powell in PRIMA), the stronger will be the driving forces to pursue duplication!