Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
A Modern Fortran Scientific Programming Ecosystem
186 views
Skip to first unread message
Beliavsky
Oct 13, 2022, 2:41:38 PM10/13/22
to
https://degenerateconic.com/a-modern-fortran-scientific-programming-ecosystem.html
A Modern Fortran Scientific Programming Ecosystem
Oct 12, 2022
Historically, large general-purpose libraries have formed the core of the Fortran scientific ecosystem (e.g., SLATEC, or the various PACKS). Unfortunately, as I have mentioned here before, these libraries were written in FORTRAN 77 (or earlier) and remained unmodified for decades. The amazing algorithms continued within them imprisoned in a terrible format that nobody wants to deal with anymore. At the time they were written, they were state of the art. Now they are relics of the past, a reminder of what might have been if they had continued to be maintained and Fortran had continued to remain the primary scientific and technical programming language.
Over the last few years, I've managed to build up a pretty good set of modern Fortran libraries for technical computing. Some are original, but a lot of them include modernized code from the libraries written decades ago. The codes still work great (polyroots-fortran contains a modernized version of a routine written 50 years old), but they just needed a little bit of cleanup and polish to be presentable to modern programmers as something other than ancient legacy to be tolerated but not well maintained (which is how Fortran is treated in the SciPy ecosystem).
...
A Modern Fortran Scientific Programming Ecosystem
Oct 12, 2022
Historically, large general-purpose libraries have formed the core of the Fortran scientific ecosystem (e.g., SLATEC, or the various PACKS). Unfortunately, as I have mentioned here before, these libraries were written in FORTRAN 77 (or earlier) and remained unmodified for decades. The amazing algorithms continued within them imprisoned in a terrible format that nobody wants to deal with anymore. At the time they were written, they were state of the art. Now they are relics of the past, a reminder of what might have been if they had continued to be maintained and Fortran had continued to remain the primary scientific and technical programming language.
Over the last few years, I've managed to build up a pretty good set of modern Fortran libraries for technical computing. Some are original, but a lot of them include modernized code from the libraries written decades ago. The codes still work great (polyroots-fortran contains a modernized version of a routine written 50 years old), but they just needed a little bit of cleanup and polish to be presentable to modern programmers as something other than ancient legacy to be tolerated but not well maintained (which is how Fortran is treated in the SciPy ecosystem).
...
Lynn McGuire
Oct 13, 2022, 8:44:18 PM10/13/22
to
nowaday ? IDE ?
Thanks,
Lynn
Beliavsky
Oct 13, 2022, 11:11:57 PM10/13/22
to
On Thursday, October 13, 2022 at 8:44:18 PM UTC-4, Lynn McGuire wrote:
...
> Which Fortran compiler and linker on which platform do you work with
> nowaday ? IDE ?
>
> Thanks,
> Lynn
I'm the OP but not the author of the linked blog post or of the software discussed.
...
> Which Fortran compiler and linker on which platform do you work with
> nowaday ? IDE ?
>
> Thanks,
> Lynn
I use gfortran and Intel Fortran on Windows and WSL2 using Emacs or Epsilon, a commercial Emacs-like editor.
pehache
Oct 14, 2022, 3:15:14 AM10/14/22
to
Le 13/10/2022 à 20:41, Beliavsky a écrit :
>
> a lot of them include modernized code from the libraries written decades ago. The codes still work great (polyroots-fortran contains a modernized version of a routine written 50 years old), but they just needed a little bit of cleanup and polish to be presentable to modern programmers
Actually I don't the point updating legacy code, even if it is
>
> a lot of them include modernized code from the libraries written decades ago. The codes still work great (polyroots-fortran contains a modernized version of a routine written 50 years old), but they just needed a little bit of cleanup and polish to be presentable to modern programmers
fixed-form pure F77, unless one wants to add new features/options/etc...
Especially when the authors also writes:
"[Fortran] is great for technical and numerical codes that need to run
fast and are intended to be used for decades. The libraries listed above
will not stop working in a few years. An extremely complicated Fortran
application can be recompiled with just a Fortran compiler. You cannot
say the same for anything written in the Python scientific ecosystem,
which is a Frankenstein hybrid of a scripting language hacked together
with a pile of C/C++/Fortran libraries compiled by somebody else. Good
luck trying to run Python you write now 20 years from now (or trying to
run something written 20 years ago)."
Which is true... In fact all Fortran evolution is tied to be able to
continue using legacy codes without constantly having to update them.
Hence "what's the point updating them?".
What the legacy libraries deserve are modern interfaces and possibly
wrappers, which does not require updating the core codes.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2h...@mid.individual.net>
Nasser M. Abbasi
Oct 14, 2022, 1:56:54 PM10/14/22
to
On 10/14/2022 2:15 AM, pehache wrote:
> What the legacy libraries deserve are modern interfaces and possibly
> wrappers, which does not require updating the core codes.
>
But isn't this what Matlab does?
> What the legacy libraries deserve are modern interfaces and possibly
> wrappers, which does not require updating the core codes.
>
Matlab basically makes it easy to use Fortran, which is
what most Matlab calls end up doing under the cover.
That what made Matlab so popular.
--Nasser
Amir Shahmoradi
Oct 15, 2022, 1:51:32 AM10/15/22
to
On Friday, October 14, 2022 at 2:15:14 AM UTC-5, pehache wrote:
> Actually I don't the point updating legacy code, even if it is
fixed-form pure F77, unless one wants to add new features/options/etc...
If the codes are not modernized, no one dares improve them. Instead, people tend to start new projects from scratch in different languages, cursing Fortran (77) on the way out. IMO, Jacob's work is quite a valuable first step toward the further development of these dormant packages. Of course, it takes a lot of testing and time to bring confidence into the modernized libraries and more to extend the existing functionalities.
> Actually I don't the point updating legacy code, even if it is
fixed-form pure F77, unless one wants to add new features/options/etc...
pehache
Oct 16, 2022, 11:08:42 AM10/16/22
to
Le 15/10/2022 à 07:51, Amir Shahmoradi a écrit :
>
> Of course, it takes a lot of testing and time to bring confidence into
the modernized libraries...
>
> Of course, it takes a lot of testing and time to bring confidence into
That's a big part of the problem. I use LAPACK on a regular basis, and I
wouldn't really want to use a "modernized" version (I mean with a
rewritten code) that would not bring a feature that I need.
0 new messages