I need to try to put a user-friendly GUI and some graphical output onto an old command-line FORTRAN number cruncher, and have been provided with around 130 KB of FORTRAN source code. A quick scan of documentation seems to suggest that this is possible using gfortran and the C calling conventions (if someone knows differently, please say so right now!) :)

My knowledge of FORTRAN-77 is sound, if rather rusty, but I know almost nothing about C programming, having been brought up as a chemist before I was dragged across to programming (I learned to program on Algol-60, BASIC and FORTRAN-IV, yes, that long ago ): ).

Anyone with any past experience here? It seems I have two choices, to try to call the FORTRAN subroutines from FreePascal or to port the FORTRAN code to Pascal, I'm looking for advice...

Thanks,

Brian.

brian wrote

I need to try to put a user-friendly GUI and some graphical outputonto an old command-line FORTRAN number cruncher, and have beenprovided with around 130 KB of FORTRAN source code. A quick scan ofdocumentation seems to suggest that this is possible using gfortranand the C calling conventions (if someone knows differently, pleasesay so right now!) :) My knowledge of FORTRAN-77 is sound, if rather rusty, but I knowalmost nothing about C programming, having been brought up as achemist before I was dragged across to programming (I learned toprogram on Algol-60, BASIC and FORTRAN-IV, yes, that long ago ): ). Anyone with any past experience here? It seems I have two choices, totry to call the FORTRAN subroutines from FreePascal or to port theFORTRAN code to Pascal, I'm looking for advice...

If the FORTRAN can be called from C as distinct from being able to call C subroutines, then I'd have thought that you'd be able to replace the main part of the program (that reads the data cards or whatever) with something written in Pascal. That would potentially allow you to put together a UI using Lazarus etc.

Granted that various companies have long had translators from FORTRAN to ALGOL (particularly in the case of B who I don't think had a native compiler) or other languages, but I'd have thought that a full translation would be best avoided if possible.

brian wrote

Anyone with any past experience here? It seems I have two choices, to try to call the FORTRAN subroutines from FreePascal or to port the FORTRAN code to Pascal, I'm looking for advice...

It is no problem calling FORTRAN from either C or FreePascal (or at least not on UNIX-like platforms like Mac OS X, havn't tried for Windows). The LAPACK package <http://www.netlib.org/lapack/> for example (also installed in the Mac system software) is written in Fortran. Some key points:

1. Lapack Fortran arrays are column-major (where column elements are contiguous in memory)
2. Lapack Fortran arrays are 1-base indexed
3. Lapack Fortran parameters are always passed by reference, even if they are value parameters

So, for example, DGETRF

===================================================================== SUBROUTINE DGETRF( M, N, A, LDA, IPIV, INFO )
*
* -- LAPACK computational routine (version 3.X) --
* -- LAPACK is a software package provided by Univ. of Tennessee, --
* -- Univ. of California Berkeley, Univ. of Colorado Denver and NAG Ltd..--
* November 2011
*
* .. Scalar Arguments ..
INTEGER INFO, LDA, M, N
* ..
* .. Array Arguments ..
INTEGER IPIV( * )
DOUBLE PRECISION A( LDA, * )
* ..

  function dgetrf_
    ( constref theNumRows              : LapackInt;
      constref theNumColumns           : LapackInt;
               theMatrixPtr            : LapackArrayOfDoublePtr;
      constref theLeadingDimension     : LapackInt;
               thePivotIndicesPtr      : LapackArrayOfIntPtr;
           var theInfo                 : LapackInt): LapackResult; cdecl; external;

where (it's just an example)

     LapackInt                         = Int32;
     LapackLongBool                    = Int32;
     LapackResult                      = Int32;
     LapackDouble                      = double;
     LapackArrayOfIntPtr               = ^Int32;
     LapackArrayOfLongBoolPtr          = ^Int32;
     LapackArrayOfDoublePtr            = ^double;

The "constref" for value parameters makes sure they are passed by reference, which is what Fortram requires.

Etcetera.

Regards,

Adriaan van Os

Thanks, Adriaan, that's exactly what I needed. :) I'm going to be writing for a Debian platform (I should have mentioned that, the original code is from a Unix minicomputer) so there hopefully shouldn't be a problem. If I can just chunk up some of the FORTRAN code and re-use the calculation routines (which I don't understand anyway, the statistics are at a level that's over my head) then it will make life a lot easier.

Brian.

brian wrote

Anyone with any past experience here? It seems I have two choices, to try to call the FORTRAN subroutines from FreePascal or to port the FORTRAN code to Pascal, I'm looking for advice...

I have a similar problem, a Delphi7 GUI program, which makes tomographic inversions and presents the data in graphic form to the user.
It was created back in 2002 and the developer put the advanced math into 4 different DLL:s which were programmed in FORTRAN. The compiler from Intel was plugged into MS Visual Studio 6 to create the Windows DLL:s, which were subsequently called from within the main Delphi 7 code.
Later the developer quit and we were stuck with the DLL:s. Noone here has touched FORTRAN ever, but we do have the FORTRAN sources in CVS.
I would very much want to convert them into DLL:s programmed in Pascal instead so they can be maintained for new Windows versions (and use 64 bit for example).

Any ideas on how to do this?

This sounds like a major job. For a starting or reference point on linux/macos I would put the existing thing together in 64bit with gfortran and fpc/lazarus. Setting up gfortran on Windows may be a bit more involved, but should not be too hard.

my 2 cents - Michael.

Bo Berglund wrote

I would very much want to convert them into DLL:s programmed in Pascal instead so they can be maintained for new Windows versions (and use 64 bit for example).

Well, you would have to do that by hand. And you need sufficient understanding of Fortran to know what you are doing. I am not aware of a Fortran to Pascal converter. But why do that if Fortran compilers are available ? And even if a Fortran compiler wouldn't exist, there is a Fortran to C converter, named f2c. See for example <http://www.netlib.org/clapack/readme.maintain> where it reads

This README file describes how we transform LAPACK from FORTRAN into ANSI C, and how to maintain it.

In addition to the routines translated from SRC, one needs to have f2c.h available to compile C source; this is in F2CLIBS. The library F2CLIBS/libF77.a needs to be linked with all routines as well. The library F2CLIB/libI77.a needs to be linked when running the TESTING or TIMING code, but not when using SRC code alone.

The basic translation is done by the Fortran-to-C translator f2c, which was written by David Gay at Bell Labs, with subsequent cleanup to improve readability. The software in the SRC directory, which contains the LAPACK library proper (i.e. no testing code, timing code, or BLAS), is cleaned up most completely, and so is easiest to read. We exploit the facts that these routines do almost no I/O (the few lines of I/O in xLAMCH and XERBLA have the ungainly f2c output replaced by hand; see below), and that they have a standard format for leading comments. The routines in TESTING, TIMING and BLAS are translated, but not cleaned up completely, and so they work but are not as easy to read.

etcetera.

Regards,

Adriaan van Os

I find myself wondering, in part due to conversations elsewhere: can the Lazarus IDE do anything at all sane with a FORTRAN routine called from Pascal?

Mark Morgan Lloyd wrote

I find myself wondering, in part due to conversations elsewhere: can the Lazarus IDE do anything at all sane with a FORTRAN routine called from Pascal?

It's not different from a call to C or any other compiled language. And with regard to debugging, I think it will be no problem either, apart from Windows, where there are different object formats, different debuggign formats and diffferent linkers for various languages.

Regards,

Adriaan van Os

Mark Morgan Lloyd wrote

I find myself wondering, in part due to conversations elsewhere: can the Lazarus IDE do anything at all sane with a FORTRAN routine called from Pascal?

In the D7 application written in ObjectPascal calls were made into the FORTRAN created DLL:s referencing multi-dimensional arrays of data. Fortran processes the inversion and returns modified/new array output. So as long as the interface is like this and the calling conventions are OK it should work also from Lazarus/FPC.

Bo Berglund wrote

On Sat, 18 Nov 2017 17:06:25 +0000, Mark Morgan Lloyd wrote: > I find myself wondering, in part due to conversations elsewhere: can the >Lazarus IDE do anything at all sane with a FORTRAN routine called from >Pascal? In the D7 application written in ObjectPascal calls were made into theFORTRAN created DLL:s referencing multi-dimensional arrays of data.Fortran processes the inversion and returns modified/new array output.So as long as the interface is like this and the calling conventionsare OK it should work also from Lazarus/FPC.

Except that when you're calling into a DLL (.so on Linux etc.) I don't think you have much chance of seeing the inside of the library code. With a statically-linked program it should be possible.

A friend-of-a-friend has a certain amount of legacy FORTRAN, so this is something that I really must find the time to try at some point.

I think that conventional wisdom is that if somebody's written numerical analysis code you don't change it gratuitously, since any alterations will change rounding errors etc. For some reason, that seems to apply particularly to FORTRAN programs :-)

Mark Morgan Lloyd wrote

I think that conventional wisdom is that if somebody's written numerical analysis code you don't change it gratuitously, since any alterations will change rounding errors etc. For some reason, that seems to apply particularly to FORTRAN programs :-)

If you have no working knowledge of the language it is written in conventional wisdom is that you don't change anything, gratuitously or otherwise.

to make any use of this code without understanding any of it, you will need some pretty thorough documentation of what it does, including accuracy, limitations and caveats.

My reaction to being presented with such a situation would be to dust off my 1980s punch card FORTRAN IV code, get up to speed and try to understand the code before attempting to use it.

Either that or you pay someone with the requisite knowledge to do the job.

my2c.

Mark Morgan Lloyd wrote

Except that when you're calling into a DLL (.so on Linux etc.) I don't think you have much chance of seeing the inside of the library code.

On Mac OS X, which is actually a BSD UNIX, I debug plug-in code all the time. Not an ,

Adriaan van Os

Mark Morgan Lloyd wrote

I think that conventional wisdom is that if somebody's written numerical analysis code you don't change it gratuitously, since any alterations will change rounding errors etc. For some reason, that seems to apply particularly to FORTRAN programs :-)

The reason being explained here
<https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Floating_002dpoint-Errors.html>

Regards,

Adriaan van Os

That obviously applies to all languages, I've never come across something which can represent 1/3 or pi exactly. But FORTRAN- or rather the way that people use it- has always seemed peculiarly sensitive, the classic problem being that recompiling with the optimising variant of the compiler produces significantly different results.

Elsewhere I came across discussion of (I think it was) a DEC FORTRAN compiler which produced the wrong results in a block of code only if it followed a comment. There's always been something grubby about FORTRAN compilers, and by now I find myself wondering whether people should even be attempting to design languages which don't compile easily (i.e. using recursive descent or whatever).

Mark Morgan Lloyd wrote

That obviously applies to all languages, I've never come across something which can represent 1/3 or pi exactly.

If you do read what is written in the link - that is not the issue. The issue is how to interpret floating-point constants and how to convert single-precision floating-point to decimal. In BCD, that conversion is exact.

But FORTRAN- or rather the way that people use it- has always seemed peculiarly sensitive, the classic problem being that recompiling with the optimising variant of the compiler produces significantly different results.

This is nonsense too. The issue is whether to use IEEE-754 math or not. And there are (or should be) compiler switches for that purpose. Not just in Fortran.

People who don't understand Pascal, find it grubby too. Of course, languages must be well designed and compilers shouldn't contain errors producing the wrong code. But that is a non-statement.

I really don't think Fortran is a well-designed language. But criticism must be precise and factual, not hear-say emotional.

Regards,

Adriaan van Os

I read the link before posting. You aren't going to represent 1/3 or Pi exactly in BCD either.

Oh really? Well I'll let you travel back in time and argue with numerous former colleagues who've routinely found differences between their "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in those days tended to be separate programs even if supplied together.

I stick to my position: a "tidy" language (I'm not going to fall into the trap of using a word like "regular" here) generally results in a tidy compiler design, and that should go a long way towards avoiding implementation errors.

I think we're in broad agreement though: don't try converting backend code unless you know exactly what you're doing, and Pascal (including Lazarus/LCL etc.) can be valuable when implementing a C21st frontend :-)

Mark Morgan Lloyd wrote

I think we're in broad agreement though: don't try converting backend code unless you know exactly what you're doing, and Pascal (including Lazarus/LCL etc.) can be valuable when implementing a C21st frontend :-)

We do have the original Fortran code and only really want to be able to handle changes in operating system needs (like changing Windows requirements) or even porting to Linux.
But currently we are not able to compile new DLL:s even since we don't have a Fortran compiler. Can GNU Fortran be used for testing?

For example is GNU Fortran (https://gcc.gnu.org/fortran/) possible to build on Windows? I have very limited experience in compiler building except for FreePascal, which I have built many times...

AFICT the *sources* are available via SVN:
https://gcc.gnu.org/svn.html

https://gcc.gnu.org/wiki/GFortranBinaries

Mark Morgan Lloyd wrote

I read the link before posting. You aren't going to represent 1/3 or Pi exactly in BCD either.

Again, that is not the point. Read the technical docs before posting.

Adriaan van Os

Mark Morgan Lloyd wrote

Oh really? Well I'll let you travel back in time and argue with numerous former colleagues who've routinely found differences between their "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in those days tended to be separate programs even if supplied together.

What contributes to a discussion are precise technical facts, not hear-say talk. If these former colleagues are/were capable engineers, they know the technical specs and peculiarities of the languages and compilers they are working with. If they don't, they must find themselves another profession.

A. van Os

Wasn't the problem somewhat different? There have always been "fast-math" version of some costly function. So, the point was, whether the faster routines could be used at the price of their larger numerical errors. Similarly, the choice of the optimization level of a compiler needed to be checked.

Furthermore, the wide spread use of fortran for numerical intense simulation up to this date stands in contrast to your statement, in particular in the field called high performance computing.

MiSchi.

Schindler Karl-Michael wrote

> Am 20.11.2017 um 12:00 schrieb > > Date: Sun, 19 Nov 2017 11:14:50 +0000> From: Mark Morgan Lloyd > To: > Subject: Re: [fpc-pascal] FORTRAN from FreePascal> Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed> > Oh really? Well I'll let you travel back in time and argue with numerous > former colleagues who've routinely found differences between their > "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in > those days tended to be separate programs even if supplied together. Wasn't the problem somewhat different? There have always been "fast-math" version of some costly function. So, the point was, whether the faster routines could be used at the price of their larger numerical errors. Similarly, the choice of the optimization level of a compiler needed to be checked. Furthermore, the wide spread use of fortran for numerical intense simulation up to this date stands in contrast to your statement, in particular in the field called high performance computing.

Possibly. It might be that the "fast" variant of the compiler was actually pulling in different libraries.

However, the situation as described to me has always been in terms of "if you have problems don't use the 'fast' compiler" or, with more recent development tools "the first thing to try is turning optimisation off". And this advice seems to /particularly/ apply to FORTRAN.

And leaving aside for the moment a small number of specialists who I only know from subscription online services etc. (such things do still exist), I've had this in most detail from well-respected senior academic colleagues one of whom had been involved with the design of the Manchester computers back when 2K words was "more than a man can keep track of".

Oh, and the story about Turing suggesting using gin in the delay lines is inaccurate. He merely observed that gin, as an aqueous alcohol mixture with trace oil content, was excellent for cleaning the transducers before the line was filled with mercury.

But this is getting way off topic and we'll get a "moderatorial cough" any moment :-)

No. It is not.

n := 1 - (1/3) - (1/3) - (1/3);
n:=1.000000 - 0.333333 - 0.333333 - 0.333333;

n is never zero, no matter what representation you pick, unless you have  infinite digits.

The problem is that periodic numbers can't be stored without infinite digits. And the second problem is that depending upon the base, binary, decimal, hex, have different periodic numbers and, unfortunately, 1/10, in base 10, is periodic number in binary.

So you are right 0.10 can't be represented with an exact value in floating-point, but it can be represented with exact value in BCD (nevertheless,  you can represent 1/10 with an exact constant but not 1/3) . But internal operations won't be executed in BCD but using the floating-point processor representation, so, the aftermath is the same.

Once I played with fraction representation, just for fun

TFraction=record
   Negative:boolean;
    IntPart:Integer;
    Numerator:Integer;
    Denominator:Integer;
end;

Except for irrational numbers pi, e, etc, it had full precision. Obviously  it was too slow. And, by the way, BCD is also too slow for numeric operations.