Re: [Plplot-devel] Re: Update concerning FORTRAN 77 examples

[Alan W. I. <ai...@us...>]

On 2003-10-27 08:33+0100 Arjen Markus wrote:

> As I am not familiar with m4 (I know of it, I do not _know_ it)

Same here.

> I did
> not
> want to invent new stuff - for instance to solve a problem with the
> interface
> to sleep(). If you want to consider an alternative to sed, you might
> think
> of "coco" - it is a solution for conditional programming in Fortran. I
> have not
> really looked at it yet, but it sounds interesting enough.

I had never heard of coco, but I had a quick look, and it seems quite
interesting.  Thanks for drawing it to my attention.

>
> Another way around some platform-dependent issues is to use include
> files:
> - Have the configuration script copy the right implementation of certain
> functions
>   or data to the standard name
> - Let the compiler do its job as usual.
>
> For instance: provide a standard interface to sleep() (example x17) and
> implement
> that as:
>
>    subroutine sleepf( seconds )
>    real seconds
>    include 'sleep.inc'
>    return
>    end
>

For now, I am willing to settle for making double work on Linux g77, and
later single with the aid of sed.  That approach could be expanded further;
at the last place where I performed a fortran contract they used sed
exclusively to massage the fortran source (250 000 lines of it!) to make it
work on their several different fortran compilers/hardware platforms.
However, I also agree that configured include files will also work nicely in
many cases when sed is not up to the task, and now there is also the
possibility of going with coco.  Lots of food for thought here, and for
now I think we should just concentrate on double-precision Linux g77 for
the examples.

N.B. My above remarks only pertain to the examples; the fortran API wrapper
in bindings/f77 that we have now has a much simpler task to do, and it has
worked pretty well for many different compilers in the past.  Nevertheless,
I intend to change that current m4 based approach to a sed based one when I
get a chance.

> > All we really need is clean double-precision fortran example programmes with
> > absolutely no single-precision in them at all.  (Also no references to m4 in
> > them as well.) Then we can use that as default and use a sed script to
> > convert to single-precision when necessary.
> >
>
> This means: any floating-point number should be annotated with "d0",
> like
> 1.0d0 instead of 1.0.

Yes!

> And the REAL type should become DOUBLE PRECISION
> (This is the FORTRAN 77 standard).

Please not.  I prefer some of useful Vax/VMS extensions to that standard
which allow you to, for example, drop all statement numbers so you can have
clean looking fortran code; DO ....ENDDO, being the primary example.  Also,
real*8 rather than DOUBLE PRECISION.  vax/vms fortran was so ubiquitous that
it essentially formed its own standard, and most modern "f77" fortran
compilers (e.g., g77) comform to that standard (at least the parts that were
used by nearly everybody in the vax/vms heyday in the 1980's and early
90's).

It's my vax/vms fortran background showing here, but my first reaction when
I see "DOUBLE PRECISION" in fortran source is this code is really old and
poorly maintained.

>
> For me the steps right now are:
> - Get the CVS head and work from there
> - Get the FORTRAN version of PLplot working
> - Get the other examples into shape
>
> I will do that the coming few weeks (but time is precious :)

Understood.  Anything you can do will be much appreciated.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________