The Perils of Polishing (LONG!)

The FPS4 compiler does not do a correct translation of the loop. It is only by examining the generated machine code that one can determine that the compiler made a mistake. There is nothing wrong with the Fortran program itself.

If this were an actively supported compiler, the test Fortran program would be reported to the compiler vendor as part of a bug report by the user.

I have wondered about that, as well. The SLATEC source code contains numerous references to IBM 360 and CDC 6000 series machines, which used 16 and 2 as the base. Along the same lines, why did Fortran 66 and 77 not provide intrinsic functions to pick apart/reassemble the mantissa and exponent of a real/double number? In C, the standard library had ldexp() and frexp().

In the lines of code that scale the determinant, they could have simply used the real multipliers 10.0 or 0.1 instead of cmplx(10.0, 0.0) and cmplx(0.1, 0.0).

My guess is that it was a combination of missing intrinsics, and less speedup. In the 80s multiplies were a lot slower than they are now so the manipulation mattered less.

Fortran 66 and 77 were primitive languages. The EXPONENT(), SCALE(), and SET_EXPONENT() functions were added in f90, and they might have even been in the early fortran 8x drafts a decade earlier. The related C functions you mention were not in K&R C, they appeared later in ANSI C, which was contemporaneous with f90. Back then, the C language mostly followed what fortran did regarding floating point conventions, and when it did deviate from fortran (e.g. like ignoring parentheses in floating point expressions, or automatically converting floats to double) it was usually wrong.

That would have simplified the source code, but the compiled instructions would be exactly the same. I think LINPACK was maintained with a utility program called TAMPR that did all of those source code conversions automatically for real, double precision, complex, and (nonstandard) double complex.

The internet archive (archive.org) has set up a wayback engine which – if the original web pages permit a recording a copy by a crawler – could be useful here to build a time capsule.

Instead of a manual copy-paste of the url into the box below save page now, there is an optional extension for e.g. the Firefox web browser with similar functionality by pull-down and right-click. For a set of interdependent web pages, it might be useful to read the documentation / get in touch with them; there might be a better simpler way to create «a complete backup». It evidently is possible (in some instances, the archived pages include pdf one still can access/download).

Thanks for that surprising tip - I had used the Wayback Machine a few times, but did not know that anyone could add a site for saving.

I tried adding SLATEC Common Mathematical Library , but after a few seconds of waiting I was told “job failed”.

UPDATE: I checked two hours later, and the Lahey SLATEC documentation pages seem to have been copied into the Wayback Machine. Please see if this works .

It does not quite work. You have to save all the pages the page refers to, it seems. So the trick is to follow the links and save the pages explicitly.

Thanks for pointing this out, Arjen. I wish I knew how to write scripts to do this, similar to writing a batch file to compile the SLATEC library!

To summarize my “reaction”, I agree entirely with the “If it ain’t broke, try harder!” lesson.

In a related perspective, the Fortran community will be far better off by adhering to the axioms

  1. All legacy FORTRAN codes are totally broke.
    (If you think they are not, you haven’t even remotely tried hard enough!)
  2. Do not worry about the consequences of breaking what is already broke!
    (That is, be brave and follow the scientific method to author new and better code and create better libraries, applications, and language.)

Separately, it appears to me many of the perils mentioned by @mecej4 in the original post have to do with attempts at “polishing” to a certain set of compilers who offer varying levels of bug-free/buggy support toward different Fortran standard revisions that offered varying levels of features that assist polishing. And perhaps due to focus on certain manageable sections of code/program units, rather than polishing to the current standard Fortran guided by language-agnostic scientific software design principles applied to the library viewed as a whole, or perhaps even a large set of libraries which may then open up an entire new unifying framework that brings together the various codes.

I find the latter pursuit toward refactoring and modernization to be more meaningful and rewarding and, personally, to be far less perilous in the long run, even as it is far more arduous of a journey because one may not encounter a current standard conforming processor for ages and one then has to resort to one’s own mental compiler vis-a-vis the current Fortran standard and be ready to file a ton of support requests with the compiler vendor(s)! I would like to think the Fortran stdlib initiative does and will incorporate a lot of this thinking.

1 Like

@mecej4 There are 1468 individual pages the SLATEC main page you indicate links to (first estimate). A tentative (recursive) harvest with wget2 failed because the server of Lahey Inc. is set up with a robot.txt file to hamper search engines to systematically index and crawl the pages – which equally hampers attempts to bring the pages to the attention of archive’s wayback machine with a Python based script. This equally were a plausible reason why your wayback snapshot launched earlier is incomplete and considers the top level only. Aiming for an improvement, yet unable to identify Mr Lahey as subscriber to this forum, I used a couple of guessed patterns of email addresses to reach out for his assistance.

1 Like

Are these docs really that compelling? They are just the code comments from the SLATEC source files converted to html. Probably somebody could write a script in 15 minutes to generate these. But why bother?

In current times, we can generate nice documentation from Fortran source code using tools such as Ford. Here’s an example of the docs for the modernized version of a routine that was once in SLATEC: defc. Using GitHub CI, when the code is changed, this page is automatically updated.

Compare to the Lahey doc which looks like it was typed on a typewriter 40 years ago.

15k now… I guess the discussion has been linked from some popular site(s)

1 Like

Yes, @Beliavsky said it was discussed on Hacker News:

But less than one third of that discussion thread is about Fortran.

And mostly nostalgic, so that feels better!

Actually this is now the most viewed Fortran Discourse post of all time!