Minutes of the BCS Fortran Specialist Group Meeting
held at BCS HQ, 13 Mansfield Street, London on 28 June 1990
Present: Miles Ellis Oxford University
E Golton RAL
Carol Hewlett LSE
Peter Holland SSL
Chris Lazou ULCC
Brian Meek Kings College London
David Muxworthy University of Edinburgh
M J Roth AEA Technology
John Young PE-MOD
1. APOLOGIES FOR ABSENCE
Apologies for absence were received from Mike Nunn, Les
Russell, and John Wilson. In the absence of the Chairman, John
Wilson, the Vice-Chairman, Chris Lazou, chaired the meeting.
2. MINUTES OF THE LAST MEETING [10 May 1990]
The Secretary, John Young, apologised to the meeting for not
finishing the minutes of the last meeting due to pressure of
work. The meeting decided to postpone its discussions on the
minutes to the next meeting.
3. MATTERS ARISING
David Muxworthy announced that the Fortran Panel of the BSI
would be meeting on 10 July 1990 at 2 pm. He was seeking ideas
on the future of Fortran to present to the Panel. The meeting
decided to discuss this item in the afternoon session.
4. REPORT FROM X3J3 AND BSI REPRESENTATIVES
The X3J3 Representative, Miles Ellis, reported that there
had been work done on the draft Fortran standard in only one
area. All other technical issues in Fortran 90 had been
finalised. This one area is known as the Forward Reference issue
and has to do with the definition of procedures whether they are
external or internal. A similar problem occurs in Modules. If
the information on procedures is not available when calling a
procedure an extra pass on compiling may be necessary making less
efficient compilation. This item has become a major issue in
Fortran 90 and has to be included in this standard.
Miles re-iterated that the May meeting of X3J3 had completed
work on the Standard and that it had been passed to ISO but not
to ANSI. The DISC processing of the Standard was just starting.
The August meeting was being held in Oxford from 20th-24th August
1990 and would be mainly concerned with processing the public
comments from the second review.
The BSI representative, David Muxworthy, gave a brief
report. He said he was preparing for the WG5 meeting to be held
in Rotterdam in August. He was seeking suggestions for revising
Fortran. He also felt that it was essential to keep the Fortran
experience in X3J3.
Brian Meek then announced that Lawrie Schonfelder had been
appointed Chairman of the Programming Languages Committee for the
BSI. He then said that he felt the Forward Reference issue was
correcting an oversight at a late stage and that there was no
need for another ballot. New guidelines say that a new ballot
needs to be held for technical changes. On the future of Fortran
Brian said he felt it was a technical and tactical error to
immediately start revising Fortran 90. First WG5 needs to become
the new Fortran body with a small editorial group to produce
documentation on Fortran 90. New items he would like to see are
varying characters strings and event handling. Applications
could be modules in addition to Fortran 90 and there could be
"Incremental" Standards and Additional Standards.
21st Birthday Celebrations
In the absence of Mike Nunn, Chris Lazou reported on the
progress on the 21st Birthday Celebrations. It was reported that
the cost of the event at Imperial College would be around £25 a
head. The cost of the event at the Science Museum was definitely
too expensive. The celebration should be low-key but with a key-
note speaker. Various names were put forward and discussed.
There seemed to be a definite bias towards a day meeting with
lunch. The meeting decided that a day meeting would go ahead.
Mike Nunn was to be kept informed.
7. ANY OTHER BUSINESS
Specialist Group's Executive
It was announced that the Specialist Group's Executive,
Karen McPhilemy had left and that the post would be filled
temporarily until someone permanent could be found.
BCS HQ Move
It was still not known when the BCS would be moving its HQ.
Date of Next Meeting
The next meeting of the Group would be held at the
Rutherford Appleton Laboratory on 25 October 1990.
8. MEMBERS TALKS
In the afternoon, E Golton gave a short illustrated talk on
the collection and processing of Space data (summarised in
Appendix A). Then John Young briefly described the collection
and publication of Earthquake data emphasising the importance of
Fortran in Seismology (see Appendix B). Finally, David Muxworthy
led a discussion on the future standardisation of Fortran seeking
ideas from the meeting (summarised in Appendix C).
John Young, Secretary
15 October 1990
SOME ASPECTS OF SPACE DATA HANDLING
This is a brief summary of the talk on some aspects of space
data handling and some suggestions for extensions to Fortran 90.
The quantity of raw data produced by scientific experiments
continues to rise dramatically; in both remote sensing and astro-
nomical imaging from satellites and in nuclear physics rates of l
GB/week, sometimes per day, are common. Data often take the form
of 8 and 16 bit counts, but other lengths, eg. 6, 9, and 12 bits
are common. Traditionally, such data have had to be handled ini-
tially with specially written assembler code because of the limita-
tions of Fortran. Apart from having completely non-portable code,
this often results in storing unpacked data, occupying even more
space, before use in Fortran analysis programs. Also, the problem
of interchanging space data and accessing archive data, perhaps in
formats from machines which no longer exist, has led the major
space agencies to set up working groups charged with developing
powerful data description languages, encompassing many aspects of
data structure and also binary format descriptions (viewgraphs were
shown on this). Fortran 90 development has been very extensive in
particular directions, but perhaps now it should develop to help
the raw data handling community, by adding binary I/O facilities?
Before considering how this might be done, it is useful to
consider some related matters concerning the convenience and
efficiency of traditional processing methods. Raw data often
form continuous series, e.g. timeseries from instruments or series
of image lines. These are usually stored in a record form e.g. on
tape, perhaps blocked, then copied using disc I/O possibly with
some different record format: underneath this the computer operat-
ing system (OS) will store the data in physical disc sectors or
tracks along with error correction codes, etc. Thus in general we
may have a 3-level process to store the data and the reverse to use
it. What the user wants is usually the timeseries, or some section
of it, but he has to go through the reverse process of handling
records with complex code, spanning one record to the next as soon
as any multi-element operations such as filtering are needed,
possibly with double buffering and error checking as well. In two
or more dimensions with rolling buffers the code is an order of
magnitude more complicated (and expensive) than code using say an
array A(I,J) as passed to a subroutine. More importantly, it is
difficult to test such code thoroughly and difficult to maintain or
modify reliably. Alternatively, data can of course be copied into
one large array first, but this may be impossible or too expensive
because of size.
Two developments in computing are relevant to improving this situa-
tion; virtual memory (VM) and file mapping.
- VM enables only those sections of a large data array (or code)
needed at any one time to be held in real memory, the bulk being
held on disc and handled by demand paged I/O by the OS. Program
code can thus use address space much larger than the size of real
memory. VM may not be a panacea for all ills and there may be
situations where record oriented code can be more efficient. But
with sensible algorithm organisation and use of VM optimisation
user parameters available with the better OS, those cases should be
few and unlikely to outweigh the code advantages indicated above.
- File Mapping is a related facility which allows a disc file in
suitable form to be treated as part of VM space. Of course, not all
machines will provide such a facility and we require Fortran to be
machine independent; in such cases the default of copying into a
real array can be done.
Thus we arrive at the possibility of using raw data directly
from disc, mapped as a VM array e.g. A(I,J) in Fortran code. Such a V
process would by-pass completely the middle level of the 3-level
record-based model above, gaining in efficiency and simplicity.
This would work for data which happened to be in the form of a
standard machine word. But what about the question of 'non-
standard' binary data word lengths we first addressed? It would
seem quite straightforward, in principle, to handle these in a
similar very efficient, transparent way. Assuming the existence of
an 'n-bit' data type and arrays, a matching pointer, and a suitable
file definition, the following steps are needed:-
a) map the pointer to the data file on disc, using information
on data array size. In Fortran 90 terms, an 'array pointer'
plus 'shape' information would be matched to a file, instead
of doing an ALLOCATE operation;
e.g. FMAP (PBNARRAY,shape,stream)
b) a few machine instructions (set up by the compiler) unpack
the required next n bits 'on the fly' into a standard word
for use in the algorithm loop. The users code could use the ~
bit array element directly, or do explicit assignment;
i.e. I = PBNARRAY(K).
In the above way, raw binary data, or compact processed data
written out in binary form could be processed directly without
first copying into larger standard-word arrays and without inter-
mediate copying into record oriented disc files, and using much
simpler and more reliable code. In practise it would be much more
useful if the assumption above of a bit data type included defini-
tions relating to the outside world, and not just be a virtual type
with details known only to the machine; i.e. capable of handling
signed and unsigned, big and little-endian binary numbers. But here
we are back to data description languages, where we started.
A BRIEF HISTORY OF THE REPORTING OF WORLD-WIDE EARTHQUAKE DATA
IN THE TWENTIETH CENTURY
J. B. Young
The following is based on the notes used to describe the
publication of earthquake data and the use of Fortran programs.
(1) ISS - International Seismological Summary -
Based at Kew, England from about 1918 - 1963.
Hypocentres were computed by hand using globes, maps,
and tables, and published as a printed hard-cover book.
Data published some years in arrears
e.g. the 1918 data after WWI published in 1923,
the 1945 data after WWII published in 1955,
the 1963 data (the last year) published in 1969.
By the late 1950's the world-wide seismological community
felt this delay was unacceptable.
(2) ISC - International Seismological Centre -
Started in Edinburgh, Scotland from 1964 - 1975,
Moved to Newbury, England in 1975 and then to
Thatcham, near Newbury in 1986 in purpose built premises.
Hypocentres were computed using "electronic computing machines"
after a young programmer named van Raalte demonstrated that
Fortran programs could do the job previously done by hand
but many times faster.
Aim to publish all seismological data after a two year delay;
The 1964 data was published in 1967.
By 1972 the two year delay had been achieved and is still
maintained today. Currently, data has to be at the Centre
22 months after the event to be included.
(3) ISC - Some Facts and Figures -
All computational programs written in Fortran 77 for a DEC
International exchange of data - even with 22 month delay some
data is still missed.
Data published in a soft-cover book printed on 'bible' paper.
Every year over 30,000 hypocentres are computed from about
The 'Historical Earthquake File' dating from the early 1900's
contains nearly 400,000 events.
All data will soon be available on compact disks (CD-ROM).
Future plans include a large increase in the number of readings
published with large earthquakes.
Summary of discussion on future standardisation of Fortran
The meeting agreed in principle that Fortran should be further developed,
i.e. that the Fortran 90 standard should be revised. The reasons are
essentially the same as for the revision of Fortran 77. It was suggested
that it was too soon to put forward a new work item proposal, and that
the Summer 1991 WG5 meeting would be an appropriate time to attend to
this. Concern was expressed at the loss of knowledge about Fortran 90
should X3J3 be dispersed. It was suggested that members of X3J3 and WG5
should consider producing an Information Bulletin on why things have
developed as they did.
Topics members would like to see addressed in a revision were
(in no particular order):
- bit handling
- event handling, possible on the Ada model
- "real time" computing
- parallelism and multi-tasking, with reference to X3H5 work
~ extension of deprecation
- possible implementation of core and modules
- examination of features in other languages which cause them
be used in preference to Fortran
- more extensive notes in the Standard including advice on use
- retention of emphasis on efficiency and of independent
- ability to cross call other languages
- acknowledgement that the underlying hardware is likely to
change substantially in the lifetime of the Standard
- possible definition of graphics interface, e.g. for micros,
- ability to force serial execution, e.g. by compiler directly
- arbitrary character sets in identifiers
- register of character kinds in Fortran 90
- store mapping of files
BCS FORTRAN SPECIALIST GROUP - MEMBERSHIP RENEWAL FORM
Your subscription fee for membership of the BCS Fortran Specialist
Group is now due for the year 1990-91. Please complete as below :
* I am now a BCS member. My membership number is :
* I wish to continue my membership of the BCS Fortran
Specialist Group and enclose a cheque or postal order
for £5 made payable to "BCS Fortran Specialist Group".
* I no longer wish to be a member of the BCS Fortran
* Delete as applicable.
Please send this completed renewal form (and subscription
if appropriate) to :
Specialist Groups Executive,
British Computer Society,
13 Mansfield Street,
LONDON, WIM 0BP.