Fcalva/OpenLibm
1
0
Fork 0
mirror of https://git.planet-casio.com/Lephenixnoir/OpenLibm.git synced 2025-01-01 06:23:39 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
OpenLibm/slatec/guide
Viral B. Shah c977aa998f Add Makefile.extras to build libopenlibm-extras. 
Replace amos with slatec
2012-12-31 16:37:05 -05:00

2768 lines
112 KiB
Text
Raw Blame History

*********************************************************
* *
* Guide to the SLATEC Common Mathematical Library *
* *
*********************************************************
Kirby W. Fong
National Magnetic Fusion Energy Computer Center
Lawrence Livermore National Laboratory
Thomas H. Jefferson
Operating Systems Division
Sandia National Laboratories Livermore
Tokihiko Suyehiro
Computing and Mathematics Research Division
Lawrence Livermore National Laboratory
Lee Walton
Network Analysis Division
Sandia National Laboratories Albuquerque
July 1993
*******************************************************************************
Table of Contents
SECTION 1. ABSTRACT
SECTION 2. BACKGROUND
SECTION 3. MEMBERS OF THE SLATEC COMMON MATHEMATICAL LIBRARY SUBCOMMITTEE
SECTION 4. OBTAINING THE LIBRARY
SECTION 5. CODE SUBMISSION PROCEDURES
SECTION 6. CODING GUIDELINES--GENERAL REQUIREMENTS FOR SLATEC
SECTION 7. SOURCE CODE FORMAT
SECTION 8. PROLOGUE FORMAT FOR SUBPROGRAMS
SECTION 9. EXAMPLES OF PROLOGUES
SECTION 10. SLATEC QUICK CHECK PHILOSOPHY
SECTION 11. SPECIFIC PROGRAMMING STANDARDS FOR SLATEC QUICK CHECKS
SECTION 12. QUICK CHECK DRIVERS (MAIN PROGRAMS)
SECTION 13. QUICK CHECK SUBROUTINE EXAMPLE
SECTION 14. QUICK CHECK MAIN PROGRAM EXAMPLE
APPENDIX A. GAMS (AND SLATEC) CLASSIFICATION SCHEME
APPENDIX B. MACHINE CONSTANTS
APPENDIX C. ERROR HANDLING
APPENDIX D. DISTRIBUTION FILE STRUCTURE
APPENDIX E. SUGGESTED FORMAT FOR A SLATEC SUBPROGRAM
ACKNOWLEDGEMENT
REFERENCES
*******************************************************************************
SECTION 1. ABSTRACT
This document is a guide to the SLATEC Common Mathematical Library (CML) [1].
The SLATEC CML is written in FORTRAN 77 (ANSI standard FORTRAN as defined by
ANSI X3.9-1978, reference [6]) and contains general purpose mathematical and
statistical routines. Included in this document are a Library description,
code submission procedures, and a detailed description of the source file
format. This report serves as a guide for programmers who are preparing codes
for inclusion in the library. It also provides the information needed to
process the source file automatically for purposes such as extracting
documentation or inserting usage monitoring calls. This guide will be updated
periodically, so be sure to contact a SLATEC CML subcommittee member to ensure
you have the latest version.
*******************************************************************************
SECTION 2. BACKGROUND
SLATEC is the acronym for the Sandia, Los Alamos, Air Force Weapons Laboratory
Technical Exchange Committee. This organization was formed in 1974 by the
computer centers of Sandia National Laboratories Albuquerque, Los Alamos
National Laboratory, and Air Force Weapons Laboratory to foster the exchange of
technical information. The parent committee established several subcommittees
to deal with various computing specialties. The SLATEC Common Mathematical
Library (CML) Subcommittee decided in 1977 to construct a mathematical FORTRAN
subprogram library that could be used on a variety of computers at the three
sites. A primary impetus for the library development was to provide portable,
non-proprietary, mathematical software for member sites' supercomputers.
In l980 the computer centers of Sandia National Laboratories Livermore and the
Lawrence Livermore National Laboratory were admitted as members of the parent
committee and subcommittees. Lawrence Livermore National Laboratory, unlike the
others, has two separate computer centers: the National Magnetic Fusion Energy
Computer Center (NMFECC) and the Livermore Computer Center (LCC). In 1981 the
National Bureau of Standards (now the National Institute of Standards and
Technology) and the Oak Ridge National Laboratory were invited to participate
in the math library subcommittee because of their great interest in the
project.
Version 1.0 of the CML was released in April 1982 with 114,328 records and 491
user-callable routines. In May 1984 Version 2.0, with 151,864 records and 646
user-callable routines was released. This was followed in April 1986 by
Version 3.0 with 196,013 records and 704 user-callable routines. Version 3.1
followed in August 1987 with 197,931 records and 707 user-callable routines
and Version 3.2 in August 1989 with 203,587 records and 709 user-callable
routines. The committee released Version 4.0 in December 1992 with 298,954
records and 901 user-callable routines. Finally, on July 1, 1993, Version 4.1
was released with 290,907 records and 902 user-callable routines.
The sole documentation provided by SLATEC for the routines of the SLATEC
Library is via comment lines in the source code. Although the library comes
with portable documentation programs to help users access the documentation in
the source code, various installations may wish to use their own documentation
programs. To facilitate automatic extraction of documentation or further
processing by other computer programs, the source file for each routine must
be arranged in a precise format. This document describes that format for the
benefit of potential library contributors and for those interested in
extracting library documentation from the source code.
*******************************************************************************
SECTION 3. MEMBERS OF THE SLATEC COMMON MATHEMATICAL LIBRARY SUBCOMMITTEE
Current member sites and voting members of the subcommittee are the
following.
Air Force Phillips Laboratory, Kirtland (PLK) Reginald Clemens
Lawrence Livermore National Laboratory (LCC) Fred N. Fritsch
Lawrence Livermore National Laboratory (NERSC) Steve Buonincontri
Los Alamos National Laboratory (LANL) W. Robert Boland
(Chairman)
National Institute of Standards and Technology (NIST) Daniel W. Lozier
Oak Ridge National Laboratory (ORNL) Thomas H. Rowan
Sandia National Laboratories/California (SNL/CA) Thomas H. Jefferson
Sandia National Laboratories/New Mexico (SNL/NM) Sue Goudy
*******************************************************************************
SECTION 4. OBTAINING THE LIBRARY
The Library is in the public domain and distributed by the Energy Science
and Technology Software Center.
Energy Science and Technology Software Center
P.O. Box 1020
Oak Ridge, TN 37831
Telephone 615-576-2606
E-mail estsc%a1.adonis.mrouter@zeus.osti.gov
*******************************************************************************
SECTION 5. CODE SUBMISSION PROCEDURES
The SLATEC Library is continuously searching for portable high-quality routines
written in FORTRAN 77 that would be of interest to the member sites. The
subcommittee meets several times annually with the member sites rotating as
meeting hosts. At these meetings new routines are introduced, discussed, and
eventually voted on for inclusion in the library. Some of the factors that are
considered in deciding whether to accept a routine into the Library are the
following:
1. Usefulness. Does the routine fill a void in the Library? Will the routine
have widespread appeal? Will it add a new capability?
2. Robustness. Does the routine give accurate results over a wide range of
problems? Does it diagnose errors? Is the routine well tested?
3. Maintainability. Is the author willing to respond to bugs in the routine?
Does the source code follow good programming practices?
4. Adherence to SLATEC standards and coding guidelines. These standards
are described further in this guide and include such things as the order
of subprogram arguments, the presence of a correctly formatted prologue at
the start of each routine, and the naming of routines.
5. Good documentation. Is clear, concise computer readable documentation
built into the source code?
6. Freely distributable. Is the program in the public domain?
A typical submission procedure begins with contact between an author and a
Library committee member. Preliminary discussions with the member are
encouraged for initial screening of any code and to gain insight into the
workings of SLATEC. This member champions the routine to be considered. The
code is introduced at a meeting where the author or committee member describes
the code and explains why it would be suitable for SLATEC. Copies of the code
are distributed to all committee members. Hopefully, the code already adheres
to SLATEC standards. However, most codes do not. At this first formal
discussion, the committee members are able to provide some useful suggestions
for improving the code and revising it for SLATEC.
Between meetings, changes are made to the code and the modified code is
distributed in machine readable format for testing. The code is then
considered at a subsequent meeting, to be voted on and accepted. However,
because committee members and authors do not always see eye to eye, and because
time constraints affect all, the code is usually discussed at several meetings.
If codes adhered to the programming practices and formatting described in this
guide, the time for acceptance could be greatly reduced.
*******************************************************************************
SECTION 6. CODING GUIDELINES--GENERAL REQUIREMENTS FOR SLATEC
A software collection of the size of the SLATEC Library that is designed to run
on a variety of computers demands uniformity in handling machine dependencies,
in handling error conditions, and in installation procedures. Thus, while the
decision to add a new subroutine to the library depends mostly on its quality
and whether it fills a gap in the library, these are not the only
considerations. Programming style must also be considered, so that the library
as a whole behaves in a consistent manner. We now list the stylistic and
documentational recommendations and requirements for routines to be
incorporated into the library.
1. The SLATEC Library is intended to have no restriction on its distribution;
therefore, new routines must be in the public domain. This is generally
not a problem since most authors are proud of their work and would like
their routines to be used widely.
2. Routines must be written in FORTRAN 77 (ANSI standard FORTRAN as
defined by ANSI X3.9-1978, reference [6]). Care must be taken so that
machine dependent features are not used.
3. To enhance maintainability codes are to be modular in structure. Codes
must be composed of reasonably small subprograms which in turn are made
up of easily understandable blocks.
4. Equivalent routines of different precision are to look the same where
possible. That is, the logical structure, statement numbers, variable
names, etc. are to be as close to identical as possible. This implies
that generic intrinsics must be used instead of specific intrinsics.
Extraneous use of INT, REAL and DBLE are strongly discouraged; use
mixed-mode expressions in accordance with the Fortran 77 standard.
5. New routines must build on existing routines in the Library, unless
there are compelling reasons to do otherwise. For example, the SLATEC
Library contains the LINPACK and EISPACK routines, so new routines
should use the existing linear system and eigensystem routines rather
than introduce new ones.
6. System or machine dependent values must be obtained by calling routines
D1MACH, I1MACH, and R1MACH. The SLATEC Library has adopted these routines
from the Bell Laboratories' PORT Library [2] [3]. See Appendix B
for a description of these machine dependent routines.
7. The SLATEC Library has a set of routines for handling error messages.
Each user-callable routine, if it can detect errors, must have as one
of its arguments an error flag, whose value upon exiting the routine
indicates the success or failure of the routine. It is acceptable for a
routine to set the error flag and RETURN; however, if the routine wishes
to write an error message, it must call XERMSG (see Appendix C) rather
than use WRITE or PRINT statements. In general, all errors (even serious
ones) should be designated as "recoverable" rather than "fatal," and the
routine should RETURN to the user. This permits the user to try an
alternate strategy if a routine decides a particular calculation is
inappropriate. A description of the entire original error handling
package appears in reference [4].
8. Each user-callable routine (and subsidiary routine if appropriate) must
have a small demonstration routine that can be used as a quick check. This
demonstration routine can be more exhaustive, but in general, it should be
structured to provide a "pass" or "fail" answer on whether the library
routine appears to be functioning properly. A more detailed description
of the required format of the quick checks appears later in this document.
9. Common blocks and SAVEd variables must be avoided. Use subprogram
arguments for interprogram communication. The use of these constructs
often obstructs multiprocessing.
Variables that are statically allocated in memory and are used as
working storage cannot be used simultaneously by several processors.
SAVEd variables and common block variables are most likely to fall into
this category. Such variables are acceptable if they are DATA loaded or
set at run time to values that are to be read (but not written) since it
does not matter in what order multiple processors read the values.
However, such variables should not be used as working storage since no
processor can use the work space while some other processor is using it.
Library routines should ask the user to provide any needed work space
by passing it in as an argument. The user is then responsible for
giving each processor a different work space even though each processor
may be executing the same library routine.
10. Complete self-contained documentation must be supplied as comments in
user-callable routines. This documentation must be self-contained because
SLATEC provides no other documentation for using the routines. This
documentation is called the "prologue" for the routine. The rigid prologue
format for user-callable routines is described below. The prologue must
tell the user how to call the routine but need not go into algorithmic
details since such explanations often require diagrams or non-ASCII
symbols. Subsidiary routines are those called by other library routines
but which are not intended to be called directly by the user. Subsidiary
routines also have prologues, but these prologues are considerably less
elaborate than those of user-callable routines.
11. No output should be printed. Instead, information should be returned
to the user via the subprogram arguments or function values. If there is
some overriding reason that printed output is necessary, the user must be
able to suppress all output by means of a subprogram input variable.
*******************************************************************************
SECTION 7. SOURCE CODE FORMAT
In this section and the two sections on prologues, we use the caret (^)
character to indicate a position in which a single blank character must
appear. Upper case letters are used for information that appears literally.
Lower case is used for material specific to the routine.
1. The first line of a subprogram must start with one of:
SUBROUTINE^name^(arg1,^arg2,^...argn)
FUNCTION^name^(arg1,^arg2,^...argn)
COMPLEX^FUNCTION^name^(arg1,^arg2,^...argn)
DOUBLE^PRECISION^FUNCTION^name^(arg1,^arg2,^...argn)
INTEGER^FUNCTION^name^(arg1,^arg2,^...argn)
REAL^FUNCTION^name^(arg1,^arg2,^...argn)
LOGICAL^FUNCTION^name^(arg1,^arg2,^...argn)
CHARACTER[*len]^FUNCTION^name^(arg1,^arg2,^...argn)
Each of the above lines starts in column 7. If there is an argument
list, then there is exactly one blank after the subprogram name and
after each comma (except if the comma appears in column 72). There is
no embedded blank in any formal parameter, after the leading left
parenthesis, before the trailing right parenthesis, or before any
comma. Formal parameters are never split across lines. Any line to be
continued must end with a comma.
For continuation lines, any legal continuation character may be used in
column 6, columns 7-9 must be blank and arguments or formal parameters
start in column 10 of a continuation line and continue up to the right
parenthesis (or comma if another continuation line is needed). The
brackets in the CHARACTER declaration do not appear literally but
indicate the optional length specification described in the FORTRAN 77
standard.
2. The author must supply a prologue for each subprogram. The prologue
must be in the format that will subsequently be described. The
prologue begins with the first line after the subprogram declaration
(including continuation lines for long argument lists).
3. Except for the "C***" lines (to be described) in the prologue and
the "C***" line marking the first executable statement, no other line
may begin with "C***".
4. The first line of the prologue is the comment line
C***BEGIN^PROLOGUE^^name
where "name", starting in column 21, is the name of the subprogram.
5. The last line of a subprogram is the word "END" starting in column 7.
6. All alphabetic characters, except for those on comment lines or in
character constants, must be upper case, as specified by the FORTRAN 77
standard (see [6]).
7. In the prologue, the comment character in column 1 must be the upper
case "C".
8. All subprogram, common block, and any formal parameter names mentioned in
the prologue must be in upper case.
9. Neither FORTRAN statements nor comment lines can extend beyond column 72.
Columns 73 through 80 are reserved for identification or sequence numbers.
10. Before the first executable statement of every subprogram, user-callable
or not, is the line
C***FIRST^EXECUTABLE^STATEMENT^^name
where "name" (starting in column 33) is the name of the subprogram.
Only comment lines may appear between the C***FIRST EXECUTABLE
STATEMENT line and the first executable statement.
11. The subprogram name consists of a maximum of six characters. Authors
should choose unusual and distinctive subprogram names to minimize
possible name conflicts. Double precision routines should begin with
"D". Subprograms of type complex should begin with "C". The letter "Z"
is reserved for future use by possible double precision complex
subprograms. No other subprograms should begin with either "D", "C", or
"Z".
12. The recommended order for the formal parameters is:
1. Names of external subprograms.
2. Input variables.
3. Variables that are both input and output (except error flags).
4. Output variables.
5. Work arrays.
6. Error flags.
However, array dimensioning parameters should immediately follow the
associated array name.
*******************************************************************************
SECTION 8. PROLOGUE FORMAT FOR SUBPROGRAMS
Each subprogram has a section called a prologue that gives standardized
information about the routine. The prologue consists of comment lines only. A
subsidiary subprogram is one that is usually called by another SLATEC Library
subprogram only and is not meant to be called by a user's routine. The
prologue for a user-callable subprogram is more extensive than the prologue for
a subsidiary subprogram. The prologue for a user-callable subprogram has up to
14 sections, of which 12 are required and one is required if and only if a
common block is present. Several of these sections are optional in subsidiary
programs and in the quick check routines. The sections are always in the
order described in the table below.
Section User-callable Subsidiary Quick Checks
1. BEGIN PROLOGUE Required Required Required
2. SUBSIDIARY Not present Required Optional
3. PURPOSE Required Required Required
4. LIBRARY SLATEC Required Required Required
5. CATEGORY Required Optional Optional
6. TYPE Required Required Required
7. KEYWORDS Required Optional Optional
8. AUTHOR Required Required Required
9. DESCRIPTION Required Optional Optional
10. SEE ALSO Optional Optional Optional
11. REFERENCES Required Optional Optional
12. ROUTINES CALLED Required Required Required
13. COMMON BLOCKS Required*** Required*** Required***
14. REVISION HISTORY Required Required Required
15. END PROLOGUE Required Required Required
***Note: The COMMON BLOCKS section appears in a subprogram prologue
if and only if the subprogram contains a common block.
In the prologue section descriptions that follow, the caret (^)
character is used for emphasis to indicate a required blank character.
1. BEGIN PROLOGUE
This section is a single line that immediately follows the subprogram
declaration and its continuation lines. It is
C***BEGIN^PROLOGUE^^name
where "name" (beginning in column 21) is the name of the subprogram.
2. SUBSIDIARY
This section is the single line
C***SUBSIDIARY
and indicates the routine in which this appears is not intended to be
user-callable.
3. PURPOSE
This section gives one to six lines of information on the purpose of the
subprogram. The letters may be in upper or lower case. There are no blank
lines in the purpose section; i.e., there are no lines consisting solely of
a "C" in column 1. The format for the first line and any continuation
lines is
C***PURPOSE^^information
C^^^^^^^^^^^^more information
Information begins in column 14 of the first line and no earlier than
column 14 of continuation lines.
4. LIBRARY SLATEC
The section is a single line used to show that the routine is a part
of the SLATEC library and, optionally, to indicate other libraries,
collections, or packages (sublibraries) of which the routine is a part
or from which the routine has been derived. The format is
C***LIBRARY^^^SLATEC
or
C***LIBRARY^^^SLATEC^(sublib1,^sublib2,^...sublibn)
The leading left parenthesis is immediately followed by the first member
of the list. Each member, except for the last, is immediately followed by
a comma and a single blank. The last member is immediately followed by
the trailing right parenthesis.
5. CATEGORY
This section is a list of classification system categories to which
this subprogram might reasonably be assigned. There must be at least
one list item. The first category listed is termed the primary
category, and others, if given, should be listed in monotonically
decreasing order of importance. Categories must be chosen from the
classification scheme listed in Appendix A. The required format for the
initial line and any continuation lines is
C***CATEGORY^^cat1,^cat2,^cat3,^...catn,
C^^^^^^^^^^^^^continued list
All alphabetic characters are in upper case.
Items in the list are separated by the two characters, comma and space.
If the list will not fit on one line, the line may be ended at a comma
(with zero or more trailing spaces), and be continued on the next line.
The list and any continuations of the list begin with a nonblank character
in column 15.
6. TYPE
This section gives the datatype of the routine and indicates which
routines, including itself, are equivalent (except possibly for type) to
the routine. The format for this section is
C***TYPE^^^^^^routine_type^(equivalence list
C^^^^^^^^^^^^^continued equivalence list
C^^^^^^^^^^^^^continued equivalence list)
Routine_type, starting in column 15, is the data type of the routine,
and is either SINGLE PRECISION, DOUBLE PRECISION, COMPLEX, INTEGER,
CHARACTER, LOGICAL, or ALL. ALL is a pseudo-type given to routines that
could not reasonably be converted to some other type. Their purpose is
typeless. An example would be the SLATEC routine that prints error
messages.
Equivalence list is a list of the routines (including this one) that are
equivalent to this one, but perhaps of a different type. Each item in the
list consists of a routine name followed by the "-" character and then
followed by the first letter of the type (except use "H" for type
CHARACTER) of the equivalent routine. The order of the items is S, D, C,
I, H, L and A.
The initial item in the list is immediately preceded by a blank and a
left parenthesis and the final item is immediately followed by a right
parenthesis. Items in the list are separated by the two characters,
comma and space. If the list will not fit on one line, the line may be
ended at a comma (with zero or more trailing spaces), and be continued
on the next line. The list and any continuations of the list begin with
a nonblank character in column 15.
All alphabetic characters in this section are in upper case.
Example
C***TYPE SINGLE PRECISION (ACOSH-S, DACOSH-D, CACOSH-C)
7. KEYWORDS
This section gives keywords or keyphrases that can be used by
information retrieval systems to identify subprograms that pertain to
the topic suggested by the keywords. There must be at least one
keyword. Keywords can have embedded blanks but may not have leading or
trailing blanks. A keyword cannot be continued on the next line; it
must be short enough to fit on one line. No keyword can have an embedded
comma. Characters are limited to the FORTRAN 77 character set (in
particular, no lower case letters). There is no comma after the last
keyword in the list. It is suggested that keywords be in either
alphabetical order or decreasing order of importance. The format for
the initial line and any continuation lines is
C***KEYWORDS^^list
C^^^^^^^^^^^^^continued list
Items in the list are separated by the two characters, comma and space.
If the list will not fit on one line, the line may be ended at a comma
(with zero or more trailing spaces), and be continued on the next line.
The list and any continuations of the list begin with a nonblank character
in column 15.
8. AUTHOR
This required section gives the author's name. There must be at least one
author, and there may be coauthors. At least the last name of the author
must be given. The first name (or initials) is optional. The company,
organization, or affiliation of the author is also optional. The brackets
below indicate optional information. Note that if an organization is to be
listed, the remainder of the author's name must also be given. If the
remainder of the author's name is given, the last name is immediately
followed by a comma. If the organization is given, the first name (or
initials) is immediately followed by a comma. The remainder of the name
and the organization name may have embedded blanks. The remainder of the
name may not have embedded commas. This makes it possible for an
information retrieval system to count commas to identify the remainder of
the name and the name of an organization. Additional information about the
author (e.g., address or telephone number) may be given on subsequent
lines. The templates used are
C***AUTHOR^^last-name[,^first-name[,^(org)]]
C^^^^^^^^^^^^^more information
C^^^^^^^^^^^^^more information
.
.
.
C^^^^^^^^^^^last-name[,^first-name[,^(org)]]
C^^^^^^^^^^^^^more information
.
.
.
Each author's name starts in column 13. Continued information starts in
column 15.
9. DESCRIPTION
This section is a description giving the program abstract, method used,
argument descriptions, dimension information, consultants, etc. The
description of the arguments is in exactly the same order in which the
arguments appear in the calling sequence. The description section may use
standard, 7-bit ASCII graphic characters, i.e., the 94 printing characters
plus the blank. Names of subprograms, common blocks, externals, and formal
parameters are all in upper case. Names of variables are also in upper
case. The first line of this section is "C***DESCRIPTION" starting in
column 1. All subsequent lines in this section start with a "C" in column
1 and no character other than a blank in column 2. Lines with only a "C"
in column 1 may be used to improve the appearance of the description.
A suggested format for the DESCRIPTION section is given in Appendix E.
10. SEE ALSO
This section is used for listing other SLATEC routines whose prologues
contain documentation on the routine in which this section appears.
The form is
C***SEE ALSO^^name,^name,^name
where each "name" is the name of a user-callable SLATEC CML subprogram
whose prologue provides a description of this routine. The names are
given as a list (starting in column 15), with successive names separated
by a comma and a single blank.
11. REFERENCES
This section is for references. Any of the 94 ASCII printing characters
plus the blank may be used. There may be more than one reference. If there
are no references, the section will consist of the single line
C***REFERENCES^^(NONE)
If there are references, they will be in the following format:
C***REFERENCES^^reference 1
C^^^^^^^^^^^^^^^^^continuation of reference 1
.
.
.
C^^^^^^^^^^^^^^^reference 2
C^^^^^^^^^^^^^^^^^continuation of reference 2
.
.
.
Information starts in column 17 of the first line of a reference and no
earlier than column 19 of continuation lines.
References should be listed in either alphabetical order by last name or
order of citation. They should be in upper and lower case, have initials
or first names ahead of last names, and (for multiple authors) have
"and" ahead of the last author's name instead of just a comma. The first
word of the title of journal articles should be capitalized as should all
important words in titles of books, pamphlets, research reports, and
proceedings. Titles should be given without quotation marks. The names
of journals should be spelled out completely, or nearly so, because
software users may not be familiar with them.
A complete example of a journal reference is:
C F. N. Fritsch and R. E. Carlson, Monotone piecewise
C cubic interpolation, SIAM Journal on Numerical Ana-
C lysis, 17 (1980), pp. 238-246.
A complete example of a book reference is:
C Carl de Boor, A Practical Guide to Splines, Applied
C Mathematics Series 27, Springer-Verlag, New York,
C 1978.
12. ROUTINES CALLED
This section gives the names of routines in the SLATEC Common Mathematical
Library that are either directly referenced or declared in an EXTERNAL
statement and passed as an argument to a subprogram. Note that the FORTRAN
intrinsics and other formal parameters that represent externals are not
listed. A list is always given for routines called; however, if no routine
is called, the list will be the single item "(NONE)" where the parentheses
are included. If there are genuine items in the list, the items are in
alphabetical order. The collating sequence has "0" through "9" first, then
"A" through "Z". The format is
C***ROUTINES^CALLED^^name,^name,^name,^name,
C^^^^^^^^^^^^^^^^^^^^name,^name,^name
Items in the list are separated by the two characters, comma and space.
If the list will not fit on one line, the line may be ended at a comma
(with zero or more trailing spaces), and be continued on the next line.
The list and any continuations of the list begin with a nonblank character
in column 22.
13. COMMON BLOCKS
This section, that may or may not be required, tells what common blocks are
used by this subprogram. If this subprogram uses no common blocks, this
section does not appear. If this subprogram does use common blocks, this
section must appear. The list of common blocks is in exactly the same
format as the list of routines called and uses the same collating sequence.
In addition, the name of blank common is "(BLANK)" where the parentheses
are included. Blank common should be last in the list if it appears. The
format for this section is
C***COMMON^BLOCKS^^^^name,^name,^name,^name,
C^^^^^^^^^^^^^^^^^^^^name,^name,^name^
The list starts in column 22.
14. REVISION HISTORY
This section provides a summary of the revisions made to this code.
Revision dates and brief reasons for revisions are given. The format is
C***REVISION^HISTORY^^(YYMMDD)
C^^^yymmdd^^DATE^WRITTEN
C^^^yymmdd^^revision description
C^^^^^^^^^^^more revision description
C^^^^^^^^^^^...
C^^^yymmdd^^revision description
C^^^^^^^^^^^more revision description
C^^^^^^^^^^^...
C^^^^^^^^^^^...
where, for each revision, "yy" (starting in column 5) is the last two
digits of the year, "mm" is the month (01, 02, ..., 12), and "dd" is the
day of the month (01, 02, ..., 31). Because this ANSI standard form for
the date may not be familiar to some people, the character string
"(YYMMDD)" (starting in column 23) is included in the first line of the
section to assist in interpreting the sequence of digits. Each line of the
revision descriptions starts in column 13. The second line of this section
contains the date the routine was written, with the characters "DATE
WRITTEN" beginning in column 13. These items must be in chronological
order.
15. END PROLOGUE
The last section is the single line
C***END^PROLOGUE^^name
where "name" is the name of the subprogram.
*******************************************************************************
SECTION 9. EXAMPLES OF PROLOGUES
This section contains examples of prologues for both user-callable
and subsidiary routines. The routines are not from the SLATEC CML and
should be used only as guidelines for preparing routines for SLATEC.
Note that the C***DESCRIPTION sections follow the suggested LDOC format that
is described in Appendix E. Following the suggested LDOC format with its
"C *"subsections helps to ensure that all necessary descriptive information is
provided.
SUBROUTINE ADDXY (X, Y, Z, IERR)
C***BEGIN PROLOGUE ADDXY
C***PURPOSE This routine adds two single precision numbers together
C after forcing both operands to be stored in memory.
C***LIBRARY SLATEC
C***CATEGORY A3A
C***TYPE SINGLE PRECISION (ADDXY-S, DADDXY-D)
C***KEYWORDS ADD, ADDITION, ARITHMETIC, REAL, SUM,
C SUMMATION
C***AUTHOR Fong, K. W., (NMFECC)
C Mail Code L-560
C Lawrence Livermore National Laboratory
C Post Office Box 5509
C Livermore, CA 94550
C Jefferson, T. H., (SNLL)
C Org. 8235
C Sandia National Laboratories Livermore
C Livermore, CA 94550
C Suyehiro, T., (LLNL)
C Mail Code L-316
C Lawrence Livermore National Laboratory
C Post Office Box 808
C Livermore, CA 94550
C***DESCRIPTION
C
C *Usage:
C
C INTEGER IERR
C REAL X, Y, Z
C
C CALL ADDXY (X, Y, Z, IERR)
C
C *Arguments:
C
C X :IN This is one of the operands to be added. It will not
C be modified by ADDXY.
C
C Y :IN This is the other operand to be added. It will not be
C modified by ADDXY.
C
C Z :OUT This is the sum of X and Y. In case of an error,
C this argument will not be modified.
C
C IERR:OUT This argument will be set to 0 if ADDXY added the two
C operands. It will be set to 1 if it appears the addition
C would generate a result that might overflow.
C
C *Description:
C
C ADDXY first divides X and Y by the largest single precision number
C and then adds the quotients. If the absolute value of the sum is
C greater than 1.0, ADDXY returns with IERR set to 1. Otherwise
C ADDXY stores X and Y into an internal array and calls ADDZZ to add
C them. This increases the probability (but does not guarantee) that
C operands and result are stored into memory to avoid retention of
C extra bits in overlength registers or cache.
C
C***REFERENCES W. M. Gentleman and S. B. Marovich, More on algorithms
C that reveal properties of floating point arithmetic
C units, Communications of the ACM, 17 (1974), pp.
C 276-277.
C***ROUTINES CALLED ADDZZ, R1MACH, XERMSG
C***REVISION HISTORY (YYMMDD)
C 831109 DATE WRITTEN
C 880325 Modified to meet new SLATEC prologue standards. Only
C comment lines were modified.
C 881103 Brought DESCRIPTION section up to Appendix E standards.
C 921215 REFERENCE section modified to reflect recommended style.
C***END PROLOGUE ADDXY
DIMENSION R(3)
C***FIRST EXECUTABLE STATEMENT ADDXY
BIG = R1MACH( 2 )
C
C This is an example program, not meant to be taken seriously. The
C following illustrates the use of XERMSG to send an error message.
C
IF ( (ABS((X/BIG)+(Y/BIG))-1.0) .GT. 0.0 ) THEN
IERR = 1
CALL XERMSG ( 'SLATEC', 'ADDXY', 'Addition of the operands '//
* 'is likely to cause overflow', IERR, 1 )
ELSE
IERR = 0
R(1) = X
R(2) = Y
CALL ADDZZ( R )
Z = R(3)
ENDIF
RETURN
END
SUBROUTINE ADDZZ (R)
C***BEGIN PROLOGUE ADDZZ
C***SUBSIDIARY
C***PURPOSE This routine adds two single precision numbers.
C***LIBRARY SLATEC
C***AUTHOR Fong, K. W., (NMFECC)
C Mail Code L-560
C Lawrence Livermore National Laboratory
C Post Office Box 5509
C Livermore, CA 94550
C Jefferson, T. H., (SNLL)
C Org. 8235
C Sandia National Laboratories Livermore
C Livermore, CA 94550
C Suyehiro, T., (LLNL)
C Mail Code L-316
C Lawrence Livermore National Laboratory
C Post Office Box 808
C Livermore, CA 94550
C***SEE ALSO ADDXY
C***ROUTINES CALLED (NONE)
C***REVISION HISTORY (YYMMDD)
C 831109 DATE WRITTEN
C 880325 Modified to meet new SLATEC prologue standards. Only
C comment lines were modified.
C***END PROLOGUE ADDZZ
DIMENSION R(3)
C***FIRST EXECUTABLE STATEMENT ADDZZ
R(3) = R(1) + R(2)
RETURN
END
*******************************************************************************
SECTION 10. SLATEC QUICK CHECK PHILOSOPHY
The SLATEC Library is distributed with a set of test programs that may be used
as an aid to insure that the Library is installed correctly. This set of test
programs is known as the SLATEC quick checks. The quick checks are not meant
to provide an exhaustive test of the Library. Instead they are designed to
protect against gross errors, such as an unsatisfied external. Because the
SLATEC Library runs on a great variety of computers, the quick checks often
detect arithmetic difficulties with either particular Library routines or with
a particular computational environment.
A list of the quick check guidelines follows.
1. A quick check should test a few problems successfully solved by a
particular library subprogram. It is not intended to be an extensive
test of a subprogram.
2. A quick check should provide consistent and minimal output in most
cases, including a "PASS" or "FAIL" indicator. However, more detailed
output should be available on request to help track down problems in the
case of failures.
3. Some reasonable error conditions should be tested by the quick check by
purposefully referencing the routine incorrectly.
4. A quick check subprogram is expected to execute correctly on any machine
with an ANSI Fortran 77 compiler and library. No test should have to be
skipped to avoid an abort on a particular machine.
5. As distributed on the SLATEC tape, the quick check package consists of a
number of quick check main programs and a moderate number of subprograms.
Each quick check main program, more frequently called a quick check driver,
calls one or more quick check subprograms. Usually, a given driver
initiates the tests for a broadly related set of subprograms, e.g. for the
single precision Basic Linear Algebra Subprograms (BLAS). Each quick
check subprogram will test one or more closely related library routines of
the same precision. For example, single precision routines and their
double precision equivalents are not to be tested in the same quick check
subprogram.
6. The format of the quick check package does not rigidly dictate how it
must be executed on a particular machine. For example, memory size of the
machine might preclude loading all quick check modules at once.
*******************************************************************************
SECTION 11. SPECIFIC PROGRAMMING STANDARDS FOR SLATEC QUICK CHECKS
Just as the routines in the SLATEC Common Mathematical Library must meet
certain standards, so must the quick checks. These standards are meant to
ensure that the quick checks adhere to the SLATEC quick check philosophy and
to enhance maintainability. The list of these quick check standards follow.
1. Each module must test only a few related library subprograms.
2. Each module must be in the form of a subroutine with three arguments.
For example:
SUBROUTINE ADTST (LUN, KPRINT, IPASS)
The first is an input argument giving the unit number to which any output
should be written. The second is an input argument specifying the amount
of printing to be done by the quick check subroutine. The third is an
output flag indicating passage or failure of the subroutine.
LUN Unit number to which any output should be written.
KPRINT = 0 No printing is done (pass/fail is presumably monitored at a
higher level, i.e. in the driver). Error messages will not be
printed since the quick check driver sets the error handling
control flag to 0, using CALL XSETF(0) when KPRINT = 0 or 1.
= 1 No printing is done for tests which pass; a short message
(e.g., one line) is printed for tests which fail. Error
messages will not be printed since the quick check driver sets
the error handling control flag to 0, using CALL XSETF(0)
when KPRINT = 0 or 1.
= 2 A short message is printed for tests which pass; more detailed
information is printed for tests which fail. Error messages
describing the reason for failure should be printed.
= 3 (Possibly) quite detailed information is printed for all tests.
Error messages describing the reason for failure should be
printed.
IPASS = 0 Indicates failure of the quick check subroutine (i.e., at least
one test failed).
= 1 Indicates that all tests passed in the quick check subroutine.
In the case of a subroutine whose purpose is to produce output (e.g., a
printer-plotter), output of a more detailed nature might be produced for
KPRINT >= 1.
The quick check must execute correctly and completely using each value
of KPRINT. KPRINT is used only to control the printing and does not
affect the tests made of the SLATEC routine.
3. The quick check subprograms must be written in ANSI Fortran 77 and
must make use of I1MACH, R1MACH, and D1MACH for pass/fail tolerances.
4. Where possible, compute constants in a machine independent fashion. For
example, PI = 4. * ATAN(1.0)
5. Using one library routine to test another is permitted, though this should
be done with care.
6. Known solutions can be stored using DATA or PARAMETER statements. Some
subprograms return a "solution" which is more than one number - for
example, the eigenvalues of a matrix. In these cases, take special care
that the quick check test passes for ALL orderings of the output which are
mathematically correct.
7. Where subprograms are required by a routine being tested, they
should accompany the quick check. However, care should be taken so that
no two such subprograms have the same name. Choosing esoteric or odd
names is a good idea. It is extremely desirable that each such
subprogram contain comments indicating which quick check needed it
(a C***SEE ALSO line should be used).
8. Detailed output should be self-contained yet concise. No external
reference material or additional computations should be required to
determine what, for example, the correct solution to the problem really is.
9. For purposes of tracking down the cause of a failure, external reference
material or the name of a (willing) qualified expert should be listed in
the comment section of the quick check.
10. Quick checks must have SLATEC prologues and be adequately commented
and cleanly written so that the average software librarian has some hope
of tracking down problems. For example, if a test problem is known to
be tricky or if difficulties are expected for short word length
machines, an appropriate comment would be helpful.
11. After deliberately calling a library routine with incorrect arguments,
invoke the function IERR=NUMXER(NERR) to verify that the correct error
number was set. (NUMXER is a function in the SLATEC error handling
package that returns the number of the most recent error via both the
function value and the argument.) Then CALL XERCLR to clear it before
this (or the next) quick check makes another error.
12. A quick check should be written in such a way that it will execute
identically if called several times in the same program. In particular,
there should be no modification of DATA loaded variables which cause the
quick check to start with the wrong values on subsequent calls.
*******************************************************************************
SECTION 12. QUICK CHECK DRIVERS (MAIN PROGRAMS)
Many people writing quick checks are not aware of the environment in which the
individual quick check is called. The following aspects of the quick check
drivers are illustrated by the example driver in Section 14.
1. Each quick check driver will call one or more quick check subprograms.
2. The input and output units for the tests are set in the driver.
LIN = I1MACH(1) the input unit
LUN = I1MACH(2) the output unit
The output unit is communicated to the quick check subprograms
through the argument list. All output should be directed to the unit LUN
that is in the argument list.
3. Each quick check has three arguments LUN, KPRINT, and IPASS. The
meaning of these arguments within the quick checks is detailed
thoroughly in the previous section.
a. The quick check driver reads in KPRINT without a prompt, and
passes KPRINT as an argument to each quick check it calls. KPRINT must
not be changed by any driver or quick check. The driver uses KPRINT to
help determine what output to write.
b. The variable IPASS must be set to 0 (for fail) or to 1 (for pass) by
each quick check before returning to the driver. Within the driver,
the variable NFAIL is set to 0. If IPASS = 0 upon return to the
driver, then NFAIL is incremented. After calling all the quick checks,
NFAIL will then have the number of quick checks which failed.
c. Quick check driver output should follow this chart:
NFAIL OUTPUT
----- ------
not 0 driver writes fail message
0 driver writes pass message
4. There are calls to three SLATEC error handler routines in each quick check
driver:
CALL XSETUN(LUN) Selects unit LUN as the unit to which
error messages will be sent.
CALL XSETF(1) Only fatal (not recoverable) error messages
or XSETF(0) will cause an abort. XSETF sets the
KONTROL variable for the error handler
routines to the value of the XSETF
argument. A value of either 0 or 1 will
make only fatal errors cause a program
abort. A value of 1 will allow printing
of error messages, while a value of zero
will print only fatal error messages.
CALL XERMAX(1000) Increase the number of times any
single message may be printed.
*******************************************************************************
SECTION 13. QUICK CHECK SUBROUTINE EXAMPLE
The following program provides a very minimal check of the sample routine
from Section 9.
SUBROUTINE ADTST (LUN, KPRINT, IPASS)
C***BEGIN PROLOGUE ADTST
C***SUBSIDIARY
C***PURPOSE Quick check for SLATEC routine ADDXY
C***LIBRARY SLATEC
C***CATEGORY A3A
C***TYPE SINGLE PRECISION (ADTST-S, DADTST-D)
C***KEYWORDS QUICK CHECK, ADDXY,
C***AUTHOR Suyehiro, Tok, (LLNL)
C Walton, Lee, (SNL)
C***ROUTINES CALLED ADDXY, R1MACH
C***REVISION HISTORY (YYMMDD)
C 880511 DATE WRITTEN
C 880608 Revised to meet new prologue standards.
C***END PROLOGUE ADTST
C
C***FIRST EXECUTABLE STATEMENT ADTST
IF ( KPRINT .GE. 2 ) WRITE (LUN,99999)
99999 FORMAT ('OUTPUT FROM ADTST')
IPASS = 1
C
C EXAMPLE PROBLEM
X = 1.
Y = 2.
CALL ADDXY(X, Y, Z, IERR)
EPS = R1MACH(4)
IF( (ABS(Z-3.) .GT. EPS) .OR. (IERR .EQ. 1) ) IPASS = 0
IF ( KPRINT .GE. 2 ) THEN
WRITE (LUN,99995)X, Y, Z
99995 FORMAT (/' EXAMPLE PROBLEM ',/' X = ',E20.13,' Y = ',E20.13,' Z = ',
* E20.13)
ENDIF
IF ( (IPASS .EQ. 1 ) .AND. (KPRINT .GT. 1) ) WRITE (LUN,99994)
IF ( (IPASS .EQ. 0 ) .AND. (KPRINT .NE. 0) ) WRITE (LUN,99993)
99994 FORMAT(/' ***************ADDXY PASSED ALL TESTS***************')
99993 FORMAT(/' ***************ADDXY FAILED SOME TESTS***************')
RETURN
END
*******************************************************************************
SECTION 14. QUICK CHECK MAIN PROGRAM EXAMPLE
The following is an example main program which should be used to drive a quick
check. The names of the quick check subroutines it calls, ADTST and DADTST,
should be replaced with the name or names of real quick checks. The dummy
names of the SLATEC routines being tested, ADDXY and DADDXY, should be
replaced with the names of the routines which are actually being tested.
PROGRAM TEST00
C***BEGIN PROLOGUE TEST00
C***SUBSIDIARY
C***PURPOSE Driver for testing SLATEC subprograms
C ADDXY DADDXY
C***LIBRARY SLATEC
C***CATEGORY A3
C***TYPE ALL (TEST00-A)
C***KEYWORDS QUICK CHECK DRIVER, ADDXY, DADDXY
C***AUTHOR Suyehiro, Tok, (LLNL)
C Walton, Lee, (SNL)
C***DESCRIPTION
C
C *Usage:
C One input data record is required
C READ (LIN,990) KPRINT
C 990 FORMAT (I1)
C
C *Arguments:
C KPRINT = 0 Quick checks - No printing.
C Driver - Short pass or fail message printed.
C 1 Quick checks - No message printed for passed tests,
C short message printed for failed tests.
C Driver - Short pass or fail message printed.
C 2 Quick checks - Print short message for passed tests,
C fuller information for failed tests.
C Driver - Pass or fail message printed.
C 3 Quick checks - Print complete quick check results.
C Driver - Pass or fail message printed.
C
C *Description:
C Driver for testing SLATEC subprograms
C ADDXY DADDXY
C
C***REFERENCES (NONE)
C***ROUTINES CALLED ADTST, DADTST, I1MACH, XERMAX, XSETF, XSETUN
C***REVISION HISTORY (YYMMDD)
C 880511 DATE WRITTEN
C 880608 Revised to meet the new SLATEC prologue standards.
C 881103 Brought DESCRIPTION section up to Appendix E standards.
C***END PROLOGUE TEST00
C
C***FIRST EXECUTABLE STATEMENT TEST00
LUN = I1MACH(2)
LIN = I1MACH(1)
NFAIL = 0
C
C Read KPRINT parameter
C
READ (LIN,990) KPRINT
990 FORMAT (I1)
CALL XSETUN(LUN)
IF ( KPRINT .LE. 1 ) THEN
CALL XSETF(0)
ELSE
CALL XSETF(1)
ENDIF
CALL XERMAX(1000)
C
C Test ADDXY
C
CALL ADTST(LUN, KPRINT, IPASS)
IF ( IPASS .EQ. 0 ) NFAIL = NFAIL + 1
C
C Test DADDXY
C
CALL DADTST(LUN, KPRINT, IPASS)
IF ( IPASS .EQ. 0 ) NFAIL = NFAIL + 1
C
IF ( NFAIL .GT. 0 ) WRITE (LUN,980) NFAIL
980 FORMAT (/' ************* WARNING -- ', I5,
* ' TEST(S) FAILED IN PROGRAM TEST00 *************' )
IF ( NFAIL .EQ. 0 ) WRITE (LUN,970)
970 FORMAT
* (/' --------------TEST00 PASSED ALL TESTS----------------')
END
*******************************************************************************
APPENDIX A. GAMS (AND SLATEC) CLASSIFICATION SCHEME
SLATEC has adopted the GAMS (Guide to Available Mathematical Software)
Classification Scheme for Mathematical and Statistical Software,
reference [5].
GAMS (and SLATEC) Classification Scheme
for
Mathematical and Statistical Software
Version 1.2 October 1983
A. Arithmetic, error analysis
A1. Integer
A2. Rational
A3. Real
A3A. Single precision
A3B. Double precision
A3C. Extended precision
A3D. Extended range
A4. Complex
A4A. Single precision
A4B. Double precision
A4C. Extended precision
A4D. Extended range
A5. Interval
A5A. Real
A5B. Complex
A6. Change of representation
A6A. Type conversion
A6B. Base conversion
A6C. Decomposition, construction
A7. Sequences (e.g., convergence acceleration)
B. Number theory
C. Elementary and special functions (search also class L5)
C1. Integer-valued functions (e.g., floor, ceiling, factorial, binomial
coefficient)
C2. Powers, roots, reciprocals
C3. Polynomials
C3A. Orthogonal
C3A1. Trigonometric
C3A2. Chebyshev, Legendre
C3A3. Laguerre
C3A4. Hermite
C3B. Non-orthogonal
C4. Elementary transcendental functions
C4A. Trigonometric, inverse trigonometric
C4B. Exponential, logarithmic
C4C. Hyperbolic, inverse hyperbolic
C4D. Integrals of elementary transcendental functions
C5. Exponential and logarithmic integrals
C6. Cosine and sine integrals
C7. Gamma
C7A. Gamma, log gamma, reciprocal gamma
C7B. Beta, log beta
C7C. Psi function
C7D. Polygamma function
C7E. Incomplete gamma
C7F. Incomplete beta
C7G. Riemann zeta
C8. Error functions
C8A. Error functions, their inverses, integrals, including the normal
distribution function
C8B. Fresnel integrals
C8C. Dawson's integral
C9. Legendre functions
C10. Bessel functions
C10A. J, Y, H-(1), H-(2)
C10A1. Real argument, integer order
C10A2. Complex argument, integer order
C10A3. Real argument, real order
C10A4. Complex argument, real order
C10A5. Complex argument, complex order
C10B. I, K
C10B1. Real argument, integer order
C10B2. Complex argument, integer order
C10B3. Real argument, real order
C10B4. Complex argument, real order
C10B5. Complex argument, complex order
C10C. Kelvin functions
C10D. Airy and Scorer functions
C10E. Struve, Anger, and Weber functions
C10F. Integrals of Bessel functions
C11. Confluent hypergeometric functions
C12. Coulomb wave functions
C13. Jacobian elliptic functions, theta functions
C14. Elliptic integrals
C15. Weierstrass elliptic functions
C16. Parabolic cylinder functions
C17. Mathieu functions
C18. Spheroidal wave functions
C19. Other special functions
D. Linear Algebra
D1. Elementary vector and matrix operations
D1A. Elementary vector operations
D1A1. Set to constant
D1A2. Minimum and maximum components
D1A3. Norm
D1A3A. L-1 (sum of magnitudes)
D1A3B. L-2 (Euclidean norm)
D1A3C. L-infinity (maximum magnitude)
D1A4. Dot product (inner product)
D1A5. Copy or exchange (swap)
D1A6. Multiplication by scalar
D1A7. Triad (a*x+y for vectors x,y and scalar a)
D1A8. Elementary rotation (Givens transformation)
D1A9. Elementary reflection (Householder transformation)
D1A10. Convolutions
D1B. Elementary matrix operations
D1B1. Set to zero, to identity
D1B2. Norm
D1B3. Transpose
D1B4. Multiplication by vector
D1B5. Addition, subtraction
D1B6. Multiplication
D1B7. Matrix polynomial
D1B8. Copy
D1B9. Storage mode conversion
D1B10. Elementary rotation (Givens transformation)
D1B11. Elementary reflection (Householder transformation)
D2. Solution of systems of linear equations (including inversion, LU and
related decompositions)
D2A. Real nonsymmetric matrices
D2A1. General
D2A2. Banded
D2A2A. Tridiagonal
D2A3. Triangular
D2A4. Sparse
D2B. Real symmetric matrices
D2B1. General
D2B1A. Indefinite
D2B1B. Positive definite
D2B2. Positive definite banded
D2B2A. Tridiagonal
D2B4. Sparse
D2C. Complex non-Hermitian matrices
D2C1. General
D2C2. Banded
D2C2A. Tridiagonal
D2C3. Triangular
D2C4. Sparse
D2D. Complex Hermitian matrices
D2D1. General
D2D1A. Indefinite
D2D1B. Positive definite
D2D2. Positive definite banded
D2D2A. Tridiagonal
D2D4. Sparse
D2E. Associated operations (e.g., matrix reorderings)
D3. Determinants
D3A. Real nonsymmetric matrices
D3A1. General
D3A2. Banded
D3A2A. Tridiagonal
D3A3. Triangular
D3A4. Sparse
D3B. Real symmetric matrices
D3B1. General
D3B1A. Indefinite
D3B1B. Positive definite
D3B2. Positive definite banded
D3B2A. Tridiagonal
D3B4. Sparse
D3C. Complex non-Hermitian matrices
D3C1. General
D3C2. Banded
D3C2A. Tridiagonal
D3C3. Triangular
D3C4. Sparse
D3D. Complex Hermitian matrices
D3D1. General
D3D1A. Indefinite
D3D1B. Positive definite
D3D2. Positive definite banded
D3D2A. Tridiagonal
D3D4. Sparse
D4. Eigenvalues, eigenvectors
D4A. Ordinary eigenvalue problems (Ax = (lambda) * x)
D4A1. Real symmetric
D4A2. Real nonsymmetric
D4A3. Complex Hermitian
D4A4. Complex non-Hermitian
D4A5. Tridiagonal
D4A6. Banded
D4A7. Sparse
D4B. Generalized eigenvalue problems (e.g., Ax = (lambda)*Bx)
D4B1. Real symmetric
D4B2. Real general
D4B3. Complex Hermitian
D4B4. Complex general
D4B5. Banded
D4C. Associated operations
D4C1. Transform problem
D4C1A. Balance matrix
D4C1B. Reduce to compact form
D4C1B1. Tridiagonal
D4C1B2. Hessenberg
D4C1B3. Other
D4C1C. Standardize problem
D4C2. Compute eigenvalues of matrix in compact form
D4C2A. Tridiagonal
D4C2B. Hessenberg
D4C2C. Other
D4C3. Form eigenvectors from eigenvalues
D4C4. Back transform eigenvectors
D4C5. Determine Jordan normal form
D5. QR decomposition, Gram-Schmidt orthogonalization
D6. Singular value decomposition
D7. Update matrix decompositions
D7A. LU
D7B. Cholesky
D7C. QR
D7D. Singular value
D8. Other matrix equations (e.g., AX+XB=C)
D9. Overdetermined or underdetermined systems of equations, singular systems,
pseudo-inverses (search also classes D5, D6, K1a, L8a)
E. Interpolation
E1. Univariate data (curve fitting)
E1A. Polynomial splines (piecewise polynomials)
E1B. Polynomials
E1C. Other functions (e.g., rational, trigonometric)
E2. Multivariate data (surface fitting)
E2A. Gridded
E2B. Scattered
E3. Service routines (e.g., grid generation, evaluation of fitted functions)
(search also class N5)
F. Solution of nonlinear equations
F1. Single equation
F1A. Smooth
F1A1. Polynomial
F1A1A. Real coefficients
F1A1B. Complex coefficients
F1A2. Nonpolynomial
F1B. General (no smoothness assumed)
F2. System of equations
F2A. Smooth
F2B. General (no smoothness assumed)
F3. Service routines (e.g., check user-supplied derivatives)
G. Optimization (search also classes K, L8)
G1. Unconstrained
G1A. Univariate
G1A1. Smooth function
G1A1A. User provides no derivatives
G1A1B. User provides first derivatives
G1A1C. User provides first and second derivatives
G1A2. General function (no smoothness assumed)
G1B. Multivariate
G1B1. Smooth function
G1B1A. User provides no derivatives
G1B1B. User provides first derivatives
G1B1C. User provides first and second derivatives
G1B2. General function (no smoothness assumed)
G2. Constrained
G2A. Linear programming
G2A1. Dense matrix of constraints
G2A2. Sparse matrix of constraints
G2B. Transportation and assignments problem
G2C. Integer programming
G2C1. Zero/one
G2C2. Covering and packing problems
G2C3. Knapsack problems
G2C4. Matching problems
G2C5. Routing, scheduling, location problems
G2C6. Pure integer programming
G2C7. Mixed integer programming
G2D. Network (for network reliability search class M)
G2D1. Shortest path
G2D2. Minimum spanning tree
G2D3. Maximum flow
G2D3A. Generalized networks
G2D3B. Networks with side constraints
G2D4. Test problem generation
G2E. Quadratic programming
G2E1. Positive definite Hessian (i.e. convex problem)
G2E2. Indefinite Hessian
G2F. Geometric programming
G2G. Dynamic programming
G2H. General nonlinear programming
G2H1. Simple bounds
G2H1A. Smooth function
G2H1A1. User provides no derivatives
G2H1A2. User provides first derivatives
G2H1A3. User provides first and second derivatives
G2H1B. General function (no smoothness assumed)
G2H2. Linear equality or inequality constraints
G2H2A. Smooth function
G2H2A1. User provides no derivatives
G2H2A2. User provides first derivatives
G2H2A3. User provides first and second derivatives
G2H2B. General function (no smoothness assumed)
G2H3. Nonlinear constraints
G2H3A. Equality constraints only
G2H3A1. Smooth function and constraints
G2H3A1A. User provides no derivatives
G2H3A1B. User provides first derivatives of function and constraints
G2H3A1C. User provides first and second derivatives of function and
constraints
G2H3A2. General function and constraints (no smoothness assumed)
G2H3B. Equality and inequality constraints
G2H3B1. Smooth function and constraints
G2H3B1A. User provides no derivatives
G2H3B1B. User provides first derivatives of function and constraints
G2H3B1C. User provides first and second derivatives of function and
constraints
G2H3B2. General function and constraints (no smoothness assumed)
G2I. Global solution to nonconvex problems
G3. Optimal control
G4. Service routines
G4A. Problem input (e.g., matrix generation)
G4B. Problem scaling
G4C. Check user-supplied derivatives
G4D. Find feasible point
G4E. Check for redundancy
G4F. Other
H. Differentiation, integration
H1. Numerical differentiation
H2. Quadrature (numerical evaluation of definite integrals)
H2A. One-dimensional integrals
H2A1. Finite interval (general integrand)
H2A1A. Integrand available via user-defined procedure
H2A1A1. Automatic (user need only specify required accuracy)
H2A1A2. Nonautomatic
H2A1B. Integrand available only on grid
H2A1B1. Automatic (user need only specify required accuracy)
H2A1B2. Nonautomatic
H2A2. Finite interval (specific or special type integrand including weight
functions, oscillating and singular integrands, principal value
integrals, splines, etc.)
H2A2A. Integrand available via user-defined procedure
H2A2A1. Automatic (user need only specify required accuracy)
H2A2A2. Nonautomatic
H2A2B. Integrand available only on grid
H2A2B1. Automatic (user need only specify required accuracy)
H2A2B2. Nonautomatic
H2A3. Semi-infinite interval (including e**(-x) weight function)
H2A3A. Integrand available via user-defined procedure
H2A3A1. Automatic (user need only specify required accuracy)
H2A3A2. Nonautomatic
H2A4. Infinite interval (including e**(-x**2)) weight function)
H2A4A. Integrand available via user-defined procedure
H2A4A1. Automatic (user need only specify required accuracy)
H2A4A2. Nonautomatic
H2B. Multidimensional integrals
H2B1. One or more hyper-rectangular regions
H2B1A. Integrand available via user-defined procedure
H2B1A1. Automatic (user need only specify required accuracy)
H2B1A2. Nonautomatic
H2B1B. Integrand available only on grid
H2B1B1. Automatic (user need only specify required accuracy)
H2B1B2. Nonautomatic
H2B2. Nonrectangular region, general region
H2B2A. Integrand available via user-defined procedure
H2B2A1. Automatic (user need only specify required accuracy)
H2B2A2. Nonautomatic
H2B2B. Integrand available only on grid
H2B2B1. Automatic (user need only specify required accuracy)
H2B2B2. Nonautomatic
H2C. Service routines (compute weight and nodes for quadrature formulas)
I. Differential and integral equations
I1. Ordinary differential equations
I1A. Initial value problems
I1A1. General, nonstiff or mildly stiff
I1A1A. One-step methods (e.g., Runge-Kutta)
I1A1B. Multistep methods (e.g., Adams' predictor-corrector)
I1A1C. Extrapolation methods (e.g., Bulirsch-Stoer)
I1A2. Stiff and mixed algebraic-differential equations
I1B. Multipoint boundary value problems
I1B1. Linear
I1B2. Nonlinear
I1B3. Eigenvalue (e.g., Sturm-Liouville)
I1C. Service routines (e.g., interpolation of solutions, error handling)
I2. Partial differential equations
I2A. Initial boundary value problems
I2A1. Parabolic
I2A1A. One spatial dimension
I2A1B. Two or more spatial dimensions
I2A2. Hyperbolic
I2B. Elliptic boundary value problems
I2B1. Linear
I2B1A. Second order
I2B1A1. Poisson (Laplace) or Helmholz equation
I2B1A1A. Rectangular domain (or topologically rectangular in the coordinate
system)
I2B1A1B. Nonrectangular domain
I2B1A2. Other separable problems
I2B1A3. Nonseparable problems
I2B1C. Higher order equations (e.g., biharmonic)
I2B2. Nonlinear
I2B3. Eigenvalue
I2B4. Service routines
I2B4A. Domain triangulation (search also class P2a2c1)
I2B4B. Solution of discretized elliptic equations
I3. Integral equations
J. Integral transforms
J1. Fast Fourier transforms (search class L10 for time series analysis)
J1A. One-dimensional
J1A1. Real
J1A2. Complex
J1A3. Trigonometric (sine, cosine)
J1B. Multidimensional
J2. Convolutions
J3. Laplace transforms
J4. Hilbert transforms
K. Approximation (search also class L8)
K1. Least squares (L-2) approximation
K1A. Linear least squares (search also classes D5, D6, D9)
K1A1. Unconstrained
K1A1A. Univariate data (curve fitting)
K1A1A1. Polynomial splines (piecewise polynomials)
K1A1A2. Polynomials
K1A1A3. Other functions (e.g., rational, trigonometric, user-specified)
K1A1B. Multivariate data (surface fitting)
K1A2. Constrained
K1A2A. Linear constraints
K1A2B. Nonlinear constraints
K1B. Nonlinear least squares
K1B1. Unconstrained
K1B1A. Smooth functions
K1B1A1. User provides no derivatives
K1B1A2. User provides first derivatives
K1B1A3. User provides first and second derivatives
K1B1B. General functions
K1B2. Constrained
K1B2A. Linear constraints
K1B2B. Nonlinear constraints
K2. Minimax (L-infinity) approximation
K3. Least absolute value (L-1) approximation
K4. Other analytic approximations (e.g., Taylor polynomial, Pade)
K5. Smoothing
K6. Service routines (e.g., mesh generation, evaluation of fitted functions)
(search also class N5)
L. Statistics, probability
L1. Data summarization
L1A. One univariate quantitative sample
L1A1. Ungrouped data
L1A1A. Location
L1A1B. Dispersion
L1A1C. Shape
L1A1D. Distribution, density
L1A2. Ungrouped data with missing values
L1A3. Grouped data
L1A3A. Location
L1A3B. Dispersion
L1A3C. Shape
L1C. One univariate qualitative (proportional) sample
L1E. Two or more univariate samples or one multivariate sample
L1E1. Ungrouped data
L1E1A. Location
L1E1B. Correlation
L1E2. Ungrouped data with missing values
L1E3. Grouped data
L1F. Two or more multivariate samples
L2. Data manipulation (search also class N)
L2A. Transform (search also class N6 for sorting, ranking)
L2B. Group
L2C. Sample
L2D. Subset
L3. Graphics (search also class Q)
L3A. Histograms
L3B. Distribution functions
L3C. Scatter diagrams
L3C1. Y vs. X
L3C2. Symbol plots
L3C3. Multiple plots
L3C4. Probability plots
L3C4B. Beta, binomial
L3C4C. Cauchy, chi-squared
L3C4D. Double exponential
L3C4E. Exponential, extreme value
L3C4F. F distribution
L3C4G. Gamma, geometric
L3C4H. Halfnormal
L3C4L. Lambda, logistic, lognormal
L3C4N. Negative binomial, normal
L3C4P. Pareto, Poisson
L3C4T. t distribution
L3C4U. Uniform
L3C4W. Weibull
L3C5. Time series plots (X(i) vs. i, vertical, lag)
L3D. EDA graphics
L4. Elementary statistical inference, hypothesis testing
L4A. One univariate quantitative sample
L4A1. Ungrouped data
L4A1A. Parameter estimation
L4A1A2. Binomial
L4A1A5. Extreme value
L4A1A14. Normal
L4A1A16. Poisson
L4A1A21. Uniform
L4A1A23. Weibull
L4A1B. Distribution-free (nonparametric) analysis
L4A1C. Goodness-of-fit tests
L4A1D. Tests on sequences of numbers
L4A1E. Density and distribution function estimation
L4A1F. Tolerance limits
L4A2. Ungrouped data with missing values
L4A3. Grouped data
L4A3A. Parameter estimation
L4A3A14. Normal
L4B. Two or more univariate quantitative samples
L4B1. Ungrouped data
L4B1A. Parameter estimation
L4B1A14. Normal
L4B1B. Distribution-free (nonparametric) analysis
L4B2. Ungrouped data with missing values
L4B3. Grouped data
L4C. One univariate qualitative (proportional) sample
L4D. Two or more univariate samples
L4E. One multivariate sample
L4E1. Ungrouped data
L4E1A. Parameter estimation
L4E1A14. Normal
L4E1B. Distribution-free (nonparametric) analysis
L4E2. Ungrouped data with missing values
L4E2A. Parameter estimation
L4E2B. Distribution-free (nonparametric) analysis
L4E3. Grouped data
L4E3A. Parameter estimation
L4E3A14. Normal
L4E3B. Distribution-free (nonparametric) analysis
L4E4. Two or more multivariate samples
L4E4A. Parameter estimation
L4E4A14. Normal
L5. Function evaluation (search also class C)
L5A. Univariate
L5A1. Cumulative distribution functions, probability density functions
L5A1B. Beta, binomial
L5A1C. Cauchy, chi-squared
L5A1D. Double exponential
L5A1E. Error function, exponential, extreme value
L5A1F. F distribution
L5A1G. Gamma, general, geometric
L5A1H. Halfnormal, hypergeometric
L5A1K. Kolmogorov-Smirnov
L5A1L. Lambda, logistic, lognormal
L5A1N. Negative binomial, normal
L5A1P. Pareto, Poisson
L5A1T. t distribution
L5A1U. Uniform
L5A1W. Weibull
L5A2. Inverse cumulative distribution functions, sparsity functions
L5A2B. Beta, binomial
L5A2C. Cauchy, chi-squared
L5A2D. Double exponential
L5A2E. Exponential, extreme value
L5A2F. F distribution
L5A2G. Gamma, general, geometric
L5A2H. Halfnormal
L5A2L. Lambda, logistic, lognormal
L5A2N. Negative binomial, normal, normal scores
L5A2P. Pareto, Poisson
L5A2T. t distribution
L5A2U. Uniform
L5A2W. Weibull
L5B. Multivariate
L5B1. Cumulative distribution functions, probability density functions
L5B1N. Normal
L6. Pseudo-random number generation
L6A. Univariate
L6A2. Beta, binomial, Boolean
L6A3. Cauchy, chi-squared
L6A4. Double exponential
L6A5. Exponential, extreme value
L6A6. F distribution
L6A7. Gamma, general (continuous, discrete) distributions, geometric
L6A8. Halfnormal, hypergeometric
L6A9. Integers
L6A12. Lambda, logical, logistic, lognormal
L6A14. Negative binomial, normal
L6A15. Order statistics
L6A16. Pareto, permutations, Poisson
L6A19. Samples, stable distribution
L6A20. t distribution, time series, triangular
L6A21. Uniform
L6A22. Von Mises
L6A23. Weibull
L6B. Multivariate
L6B3. Contingency table, correlation matrix
L6B13. Multinomial
L6B14. Normal
L6B15. Orthogonal matrix
L6B21. Uniform
L6C. Service routines (e.g., seed)
L7. Experimental design, including analysis of variance
L7A. Univariate
L7A1. One-way analysis of variance
L7A1A. Parametric analysis
L7A1A1. Contrasts, multiple comparisons
L7A1A2. Analysis of variance components
L7A1B. Distribution-free (nonparametric) analysis
L7A2. Balanced multiway design
L7A2A. Complete
L7A2A1. Parametric analysis
L7A2A1A. Two-way
L7A2A1B. Factorial
L7A2A1C. Nested
L7A2A2. Distribution-free (nonparametric) analysis
L7A2B. Incomplete
L7A2B1. Parametric analysis
L7A2B1A. Latin square
L7A2B1B. Lattice designs
L7A2B2. Distribution-free (nonparametric) analysis
L7A3. Analysis of covariance
L7A4. General linear model (unbalanced design)
L7A4A. Parametric analysis
L7A4B. Distribution-free (nonparametric) analysis
L7B. Multivariate
L8. Regression (search also classes G, K)
L8A. Linear least squares (L-2) (search also classes D5, D6, D9)
L8A1. Simple
L8A1A. Ordinary
L8A1A1. Unweighted
L8A1A1A. No missing values
L8A1A1B. Missing values
L8A1A2. Weighted
L8A1B. Through the origin
L8A1C. Errors in variables
L8A1D. Calibration (inverse regression)
L8A2. Polynomial
L8A2A. Not using orthogonal polynomials
L8A2A1. Unweighted
L8A2A2. Weighted
L8A2B. Using orthogonal polynomials
L8A2B1. Unweighted
L8A2B2. Weighted
L8A3. Piecewise polynomial (i.e. multiphase or spline)
L8A4. Multiple
L8A4A. Ordinary
L8A4A1. Unweighted
L8A4A1A. No missing values
L8A4A1B. Missing values
L8A4A1C. From correlation data
L8A4A1D. Using principal components
L8A4A1E. Using preference pairs
L8A4A2. Weighted
L8A4B. Errors in variables
L8A4D. Logistic
L8A5. Variable selection
L8A6. Regression design
L8A7. Several multiple regressions
L8A8. Multivariate
L8A9. Diagnostics
L8A10. Hypothesis testing, inference
L8A10A. Lack-of-fit tests
L8A10B. Analysis of residuals
L8A10C. Inference
L8B. Biased (ridge)
L8C. Linear least absolute value (L-1)
L8D. Linear minimax (L-infinity)
L8E. Robust
L8F. EDA
L8G. Nonlinear
L8G1. Unweighted
L8G1A. Derivatives not supplied
L8G1B. Derivatives supplied
L8G2. Weighted
L8G2A. Derivatives not supplied
L8G2B. Derivatives supplied
L8H. Service routines
L9. Categorical data analysis
L9A. 2-by-2 tables
L9B. Two-way tables
L9C. Log-linear model
L9D. EDA (e.g., median polish)
L10. Time series analysis (search also class L3c5 for time series graphics)
L10A. Transformations, transforms (search also class J1)
L10B. Smoothing, filtering
L10C. Autocorrelation analysis
L10D. Complex demodulation
L10E. ARMA and ARIMA modeling and forecasting
L10E1. Model and parameter estimation
L10E2. Forecasting
L10F. Spectral analysis
L10G. Cross-correlation analysis
L10G1. Parameter estimation
L10G2. Forecasting
L11. Correlation analysis
L12. Discriminant analysis
L13. Factor analysis
L13A. Principal components analysis
L14. Cluster analysis
L14A. Unconstrained
L14A1. Nested
L14A1A. Joining (e.g., single link)
L14A1B. Divisive
L14A2. Non-nested
L14B. Constrained
L14B1. One-dimensional
L14B2. Two-dimensional
L14C. Display
L15. Life testing, survival analysis
M. Simulation, stochastic modeling (search also classes L6, L10)
M1. Simulation
M1A. Discrete
M1B. Continuous (Markov models)
M2. Queueing
M3. Reliability
M3A. Quality control
M3B. Electrical network
M4. Project optimization (e.g., PERT)
N. Data handling (search also class L2)
N1. Input, output
N2. Bit manipulation
N3. Character manipulation
N4. Storage management (e.g., stacks, heaps, trees)
N5. Searching
N5A. Extreme value
N5B. Insertion position
N5C. On a key
N6. Sorting
N6A. Internal
N6A1. Passive (i.e. construct pointer array, rank)
N6A1A. Integer
N6A1B. Real
N6A1B1. Single precision
N6A1B2. Double precision
N6A1C. Character
N6A2. Active
N6A2A. Integer
N6A2B. Real
N6A2B1. Single precision
N6A2B2. Double precision
N6A2C. Character
N6B. External
N7. Merging
N8. Permuting
O. Symbolic computation
P. Computational geometry (search also classes G, Q)
P1. One dimension
P2. Two dimensions
P2A. Points, lines
P2A1. Relationships
P2A1A. Closest and farthest points
P2A1B. Intersection
P2A2. Graph construction
P2A2A. Convex hull
P2A2B. Minimum spanning tree
P2A2C. Region partitioning
P2A2C1. Triangulation
P2A2C2. Voronoi diagram
P2B. Polygons (e.g., intersection, hidden line problems)
P2C. Circles
P3. Three dimensions
P3A. Points, lines, planes
P3B. Polytopes
P3C. Spheres
P4. More than three dimensions
Q. Graphics (search also classes L3, P)
Q1. Line printer plotting
R. Service routines
R1. Machine-dependent constants
R2. Error checking (e.g., check monotonicity)
R3. Error handling
R3A. Set criteria for fatal errors
R3B. Set unit number for error messages
R3C. Other utility programs
R4. Documentation retrieval
S. Software development tools
S1. Program transformation
S2. Static analysis
S3. Dynamic analysis
Z. Other
*******************************************************************************
APPENDIX B. MACHINE CONSTANTS
The SLATEC Common Math Library uses three functions for keeping machine
constants. In order to keep the source code for the Library as portable as
possible, no other Library routines should attempt to DATA load machine
dependent constants. Due to the subtlety of trying to calculate machine
constants at run time in a manner that yields correct constants for all
possible computers, no Library routines should attempt to calculate them.
Routines I1MACH, R1MACH, and D1MACH in the SLATEC Common Math Library are
derived from the routines of these names in the Bell Laboratories' PORT Library
and should be called whenever machines constants are needed. These functions
are DATA loaded with carefully determined constants of type integer, single
precision, and double precision, respectively, for a wide range of computers.
Each is called with one input argument to indicate which constant is desired.
The appropriate Fortran statements are:
For integer constants:
INTEGER I1MACH, I
I = I1MACH(N) where 1 .LE. N .LE. 16
For single precision constants:
REAL R1MACH, R
R = R1MACH(N) where 1 .LE. N .LE. 5
For double precision constants:
DOUBLE PRECISION D1MACH, D
D = D1MACH(N) where 1 .LE. N .LE. 5
The different constants that can be retrieved will be explained below after we
give a summary of the floating point arithmetic model which they characterize.
The PORT and SLATEC machine constant routines acknowledge that a computer
can have some minor flaws in how it performs arithmetic and that the purpose of
machine constant routines is to keep other library routines out of trouble.
For example, a computer may have a 48-bit coefficient, but due to round-off or
other deficiencies may be able to perform only 47-bit (or even 46-bit)
arithmetic reliably. A machine can also misbehave at the extreme ends of its
exponent range. The machine constants are chosen to describe a subset of the
floating point numbers of a computer on which operations such as addition,
subtraction, multiplication, reciprocation, and comparison work as your
intuition would expect. If the actual performance of the machine is such that
results fall into the "expected" intervals of the subset floating point system,
then the usual forms of error analysis will apply. For details, see [7].
The machine constants normally cannot be determined by reading a computer's
hardware reference manual. Such manuals tell the range and representation of
floating point numbers but usually do not describe the errors in the floating
point addition, subtraction, multiplication, reciprocation, or division units.
The constants for I1MACH, R1MACH, and D1MACH are found by doing extensive
testing using operands on which the hardware is most likely to fail. Failure
is most likely to occur at the extreme ends of the exponent range and near
powers of the number base. If such failures are relatively minor, we can
choose machine constants for I1MACH, R1MACH, and D1MACH to restrict the domain
of floating point numbers to a subset on which arithmetic operations work.
The subset model of floating point arithmetic is characterized by four
parameters:
B the number base or radix. This is usually 2 or 16.
T the number of digits in base B of the coefficient of the floating
point number.
EMIN the smallest (most negative) exponent (power of B)
EMAX the largest exponent (power of B)
A floating point number is modeled as FRACTION*(B**EXP) where EXP falls between
EMIN and EMAX and the FRACTION is of the form
+ or - ( f(1)*B**(-1) + ... + f(T)*B**(-T) )
with f(1) in the range 1 to B-1 inclusive and
f(2) through f(T) in the range 0 to B-1 inclusive.
In this model the fraction has the radix point at the left end. Some computers
have their radix point at the right end so that when their representation is
mapped onto this model, they appear to have an unbalanced exponent range (i.e.,
EMIN is not close to the negative of EMAX). If the computer cannot correctly
calculate results near underflow, EMIN is increased to a more conservative
value. Likewise, if the computer cannot correctly calculate results near
overflow, EMAX is decreased. If a base 2 machine with a 48-bit fraction is
unable to calculate 48-bit results due to hardware round-off, T may be set to
47 (or even 46) to account for the loss of accuracy.
The complete set of machine constants (including those not related to floating
point arithmetic) are:
I/O Unit Numbers
----------------
I1MACH( 1) = the FORTRAN unit number for the standard input device.
I1MACH( 2) = the FORTRAN unit number for the standard output device.
I1MACH( 3) = the FORTRAN unit number for the standard punch device.
I1MACH( 4) = the FORTRAN unit number for the standard error message device.
Word Properties
---------------
I1MACH( 5) = the number of bits per integer storage unit.
I1MACH( 6) = the number of characters per integer storage unit.
Integer Arithmetic
------------------
I1MACH( 7) = the base or radix for integer arithmetic.
I1MACH( 8) = the number of digits in radix I1MACH(7) used in integer
arithmetic.
I1MACH( 9) = the largest magnitude integer for which the machine and compiler
perform the complete set of arithmetic operations.
Floating Point Arithmetic
-------------------------
I1MACH(10) = the base or radix for floating point arithmetic. This is the B
of the floating point model.
Single Precision Arithmetic
---------------------------
I1MACH(11) = the number of digits in radix I1MACH(10) used in single precision
arithmetic. This is the T in the floating point model.
I1MACH(12) = the most negative usable exponent short of underflow of radix
I1MACH(10) for a single precision number. This is the EMIN in the
floating point model.
I1MACH(13) = the largest usable exponent short of overflow of radix I1MACH(10)
for a single precision number. This is the EMAX in the floating
point model.
Double Precision Arithmetic
---------------------------
I1MACH(14) = the number of digits in radix I1MACH(10) used in double precision
arithmetic. This is the T of the floating point model.
I1MACH(15) = the most negative usable exponent short of underflow of radix
I1MACH(10) for a double precision number. This is the EMIN of
the floating point model.
I1MACH(16) = the largest usable exponent short of overflow of radix I1MACH(10)
for a double precision number. This is the EMAX of the floating
point model.
Special Single Precision Values
-------------------------------
R1MACH( 1) = B**(EMIN-1). This is the smallest, positive, single precision
number in the range for safe, accurate arithmetic.
R1MACH( 2) = B**EMAX*(1-B**(-T)). This is the largest, positive, single
precision number in the range for safe, accurate arithmetic.
R1MACH( 3) = B**(-T). This is the smallest relative spacing between two
adjacent single precision numbers in the floating point model.
This constant is not machine epsilon; see below for machine
epsilon.
R1MACH( 4) = B**(1-T). This is the largest relative spacing between two
adjacent single precision numbers in the floating point model.
Any two single precision numbers that have a greater relative
spacing than R1MACH(4) can be compared correctly (with operators
like .EQ. or .LT.). This constant is an upper bound on theoretical
machine epsilon.
R1MACH( 5) = logarithm to base ten of the machine's floating point number base.
Special Double Precision Values
-------------------------------
D1MACH( 1) = B**(EMIN-1). This is the smallest, positive, double precision
numbers in the range for safe, accurate arithmetic.
D1MACH( 2) = B**EMAX*(1-B**(-T)). This is the largest, positive, double
precision number in the range for safe, accurate arithmetic.
D1MACH( 3) = B**(-T). This is the smallest relative spacing between two
adjacent double precision numbers in the floating point model.
This constant is not machine epsilon; see below for machine
epsilon.
D1MACH( 4) = B**(1-T). This is the largest relative spacing between two
adjacent double precision numbers in the floating point model.
Any two double precision numbers that have a greater relative
spacing than D1MACH(4) can be compared correctly (with operators
like .EQ. or .LT.). This constant is an upper bound on theoretical
machine epsilon.
D1MACH( 5) = logarithm to base ten of the machine's floating point number base.
In theory, all of the R1MACH and D1MACH values can be calculated from I1MACH
values; however, they are provided (1) to save having to calculate them and (2)
to avoid rousing any bugs in the exponentiation (** operator ) or logarithm
routines.
Machine epsilon (the smallest number that can be added to 1.0 or 1.0D0
that yields a result different from 1.0 or 1.0D0) is not one of the special
values that comes from this model. If the purpose of machine epsilon is to
decide when iterations have converged, the proper constants to use are
R1MACH(4) or D1MACH(4). These may be slightly larger than machine epsilon;
however, trying to iterate to smaller relative differences may not be possible
due to hardware round-off error.
The Fortran standard requires that the amount of storage assigned to an INTEGER
and a REAL be the same. Thus, the number of bits that can be used to represent
an INTEGER will almost always be larger than the number of bits in the mantissa
of a REAL. In converting from an INTEGER to a REAL, some machines will
correctly round or truncate, but some will not. Authors are therefore advised
to check the magnitude of INTEGERs and not attempt to convert INTEGERs to REALs
that can not be represented exactly as REALs. Similar problems can occur when
converting INTEGERs to DOUBLEs.
*******************************************************************************
APPENDIX C. ERROR HANDLING
Authors of Library routines must use at least the first and preferably both of
the following techniques to handle errors that their routines detect.
1. One argument, preferably the last, in the calling sequence must be an
error flag if the routine can detect errors. This is an integer variable
to which a value is assigned before returning to the caller. A value of
zero means the routine completed successfully. A positive value (preferably
in the range 1 to 999) should be used to indicate potential, partial, or
total failure. Separate values should be used for distinct conditions so
that the caller can determine the nature of the failure. Of course, the
possible values of this error flag and their meanings must be documented in
the description section of the prologue of the routine.
2. In addition to returning an error flag, the routine can supply more
information by writing an error message via a call to XERMSG. XERMSG
has an error number as one of its arguments, and the same value that will
be returned in the error flag argument must be used in calling XERMSG.
XERMSG is part of the SLATEC Common Math Library error handling package
which consists of a number of routines. It is not necessary for authors to
learn about the entire package. Instead we summarize here a few aspects of the
package that an author must know in order to use XERMSG correctly.
1. Although XERMSG supports three levels of severity (warning, recoverable
error, and fatal error), be sparing in the use of fatal errors. XERMSG
will terminate the program for fatal errors but may return for recoverable
errors, and will definitely return after warning messages. An error should
be designated fatal only if returning to the caller is likely to be
disastrous (e.g. result in an infinite loop).
2. The error handling package remembers the value of the error number and has
an entry point whereby the user can retrieve the most recent error number.
Successive calls to XERMSG replace this retained value. In the case of
warning messages, it is permissible to issue multiple warnings. In the
case of a recoverable error, no additional calls to XERMSG must be made by
the Library routine before returning to the caller since the caller must be
given a chance to retrieve and clear the error number (and error condition)
from the error handling package. In particular, if the user calls Library
routine X and X calls a lower level Library Y, it is permissible for Y
to call XERMSG, but after it returns to X, X must be careful to note any
recoverable errors detected in Y and not make any additional calls to
XERMSG in that case. In practice, it would be simpler if subsidiary
routines did not call XERMSG but only returned error flags indicating a
serious problem. Then the highest level Library routine could call XERMSG
just before returning to its caller. This also allows the highest level
routine the most flexibility in assigning error numbers and assures that
all possible error conditions are documented in one prologue rather than
being distributed through prologues of subsidiary routines.
Below we describe only subroutine XERMSG. Other routines in the error
handling package are described in their prologues and in Reference [4].
The call to XERMSG looks like
Template: CALL XERMSG (library, routine, message, errornumber, level)
Example: CALL XERMSG ('SLATEC', 'MMPY',
1 'The order of the matrix exceeds the row dimension', 3, 1)
where the meaning of the arguments is
library A character constant (or character variable) with the name of
the library. This will be 'SLATEC' for the SLATEC Common Math
Library. The error handling package is general enough to be used
by many libraries simultaneously, so it is desirable for the
routine that detects and reports an error to identify the library
name as well as the routine name.
routine A character constant (or character variable) with the name of the
routine that detected the error. Usually it is the name of the
routine that is calling XERMSG. There are some instances where a
user callable library routine calls lower level subsidiary
routines where the error is detected. In such cases it may be
more informative to supply the name of the routine the user
called rather than the name of the subsidiary routine that
detected the error.
message A character constant (or character variable) with the text of the
error or warning message. In the example below, the message is a
character constant that contains a generic message.
CALL XERMSG ('SLATEC', 'MMPY',
* 'The order of the matrix exceeds the row dimension',
* 3, 1)
It is possible (and is sometimes desirable) to generate a
specific message--e.g., one that contains actual numeric values.
Specific numeric values can be converted into character strings
using formatted WRITE statements into character variables. This
is called standard Fortran internal file I/O and is exemplified
in the first three lines of the following example. You can also
catenate substrings of characters to construct the error message.
Here is an example showing the use of both writing to an internal
file and catenating character strings.
CHARACTER*5 CHARN, CHARL
WRITE (CHARN,10) N
WRITE (CHARL,10) LDA
10 FORMAT(I5)
CALL XERMSG ('SLATEC', 'MMPY', 'The order'//CHARN//
* ' of the matrix exceeds its row dimension of'//
* CHARL, 3, 1)
There are two subtleties worth mentioning. One is that the //
for character catenation is used to construct the error message
so that no single character constant is continued to the next
line. This avoids confusion as to whether there are trailing
blanks at the end of the line. The second is that by catenating
the parts of the message as an actual argument rather than
encoding the entire message into one large character variable,
we avoid having to know how long the message will be in order to
declare an adequate length for that large character variable.
XERMSG calls XERPRN to print the message using multiple lines if
necessary. If the message is very long, XERPRN will break it
into pieces of 72 characters (as requested by XERMSG) for
printing on multiple lines. Also, XERMSG asks XERPRN to prefix
each line with ' * ' so that the total line length could be 76
characters. Note also that XERPRN scans the error message
backwards to ignore trailing blanks. Another feature is that the
substring '$$' is treated as a new line sentinel by XERPRN. If
you want to construct a multiline message without having to count
out multiples of 72 characters, just use '$$' as a separator.
'$$' obviously must occur within 72 characters of the start of
each line to have its intended effect since XERPRN is asked to
wrap around at 72 characters in addition to looking for '$$'.
errornumber An integer value that is chosen by the library routine's author.
It must be in the range 1 to 999. Each distinct error should
have its own error number. These error numbers should be
described in the machine readable documentation for the routine.
The error numbers need be unique only within each routine, so it
is reasonable for each routine to start enumerating errors from 1
and proceeding to the next integer.
level An integer value in the range 0 to 2 that indicates the level
(severity) of the error. Their meanings are
0 A warning message. This is used if it is not clear that there
really is an error, but the user's attention may be needed.
1 A recoverable error. This is used even if the error is so
serious that the routine cannot return any useful answer. If
the user has told the error package to return after
recoverable errors, then XERMSG will return to the Library
routine which can then return to the user's routine. The user
may also permit the error package to terminate the program
upon encountering a recoverable error.
2 A fatal error. XERMSG will not return to its caller after it
receives a fatal error. This level should hardly ever be
used; it is much better to allow the user a chance to recover.
An example of one of the few cases in which it is permissible
to declare a level 2 error is a reverse communication Library
routine that is likely to be called repeatedly until it
integrates across some interval. If there is a serious error
in the input such that another step cannot be taken and the
Library routine is called again without the input error having
been corrected by the caller, the Library routine will
probably be called forever with improper input. In this case,
it is reasonable to declare the error to be fatal.
Each of the arguments to XERMSG is input; none will be modified by XERMSG. A
routine may make multiple calls to XERMSG with warning level messages; however,
after a call to XERMSG with a recoverable error, the routine should return to
the user. Do not try to call XERMSG with a second recoverable error after the
first recoverable error because the error package saves the error number. The
user can retrieve this error number by calling another entry point in the error
handling package and then clear the error number when recovering from the
error. Calling XERMSG in succession causes the old error number to be
overwritten by the latest error number. This is considered harmless for error
numbers associated with warning messages but must not be done for error numbers
of serious errors. After a call to XERMSG with a recoverable error, the user
must be given a chance to call NUMXER or XERCLR to retrieve or clear the error
number.
*******************************************************************************
APPENDIX D. DISTRIBUTION FILE STRUCTURE
The source files of the SLATEC library distribution tape are ASCII text files.
Each line image consists of exactly 80 characters. The first file of the tape
is text file describing the contents of the tape.
The SLATEC source code file has the following characteristics.
1. All subprograms in the file are in alphabetic order. The collating
sequence is 0 through 9 and then A through Z.
2. Before each subprogram, of name for example XYZ, there is a line starting
in column 1 with
*DECK XYZ
This allows the source file to be used as input for a source code
maintenance program.
3. No comments other than the *DECK lines appear between subprograms.
*******************************************************************************
APPENDIX E. SUGGESTED FORMAT FOR A SLATEC SUBPROGRAM
A template embodying the suggested format for a SLATEC subprogram is given
below. As elsewhere in this Guide, the caret (^) denotes a required blank
character. These should be replaced with blanks AFTER filling out the
template. The template itself begins with the *DECK line, below. All
occurrences of "NAME" are to be replaced with the actual name of the
subprogram, of course. Items in brackets [] are either explanations or
optional information. Lines that do not have C or * in column 1 are
explanatory remarks that are intended to be deleted by the programmer. In all
cases where "or" is used, exactly one of the indicated forms must occur.
Lines that begin with C*** are standard SLATEC lines. These must be in the
indicated order. See Section 8 of this Guide for information on required vs
optional lines. In all but the C***DESCRIPTION section, the exact spacing and
punctuation are as mandated by this Guide. Spacing within this section is only
suggestive, except as noted below. The SLATEC standard mandates that no other
comments may begin "C***". All other lines between the C***BEGIN^PROLOGUE
and the C***END^PROLOGUE must be comment lines with "C^" in columns 1-2.
Within the C***DESCRIPTION section, lines that begin with "C^*" are for the
LLNL LDOC standard [9]. If present, these lines must be exactly as given here.
They should be in the indicated order. All other lines in this section must
have "C^^" in columns 1-3.
In the Arguments subsection, each argument must be followed by exactly one
argument qualifier. The qualifier must be preceded by a colon and followed
by at least one blank. The allowable qualifiers and their meanings follow.
Qualifier Meaning
--------- ---------
:IN input variable. Must be set by the user prior to the call
(unless otherwise indicated). Must NOT be changed by the
routine under any circumstances.
:OUT output variable. Values will be set by the routine.
Must be initialized before first usage in the routine.
:INOUT input/output variable. Must be set by the user prior to
the call (as indicated in argument description); value(s)
may be set or changed by the routine.
:WORK workspace. Simply working storage required by the routine.
Need not be set prior to the call and will not contain
information meaningful to the user on return. (Some
routines require the contents of a work array to remain
unchanged between successive calls. Such usage should be
carefully explained in the argument description.)
:EXT external procedure. The actual argument must be the name of
a SUBROUTINE, FUNCTION, or BLOCK DATA subprogram. It must
appear in an EXTERNAL statement in the calling program. The
argument description following should precisely specify the
expected calling sequence.
:DUMMY dummy argument. Need not be set by user; will not be
referenced by the routine. [Use discouraged!]
To avoid potential problems with automatic formatting of argument descriptions,
none of these key words should appear anywhere else in the text immediately
preceded by a colon.
NOTES:
1. Make a template by copying the following "*DECK^NAME" through
"^^^^^^END" lines, inclusive, from this Guide.
2. You will probably want to customize this template by filling
in the C***AUTHOR section and adding other things you customarily
include in your prologues. If all of your routines are in the same
category(ies), you may wish to fill in the C***CATEGORY and
C***KEYWORDS sections, too. Be sure to eliminate the brackets [].
3. Be sure to delete the "C***SUBSIDIARY" line if this is a user-
callable routine.
*DECK^NAME
^^^^^^SUBROUTINE^NAME[^(ARG1[,^ARG2[,^...]])] or
^^^^^^FUNCTION^NAME^(ARG1[,^ARG2[,^...]]) or
^^^^^^COMPLEX^FUNCTION^NAME^(ARG1[,^ARG2[,^...]]) or
^^^^^^DOUBLE^PRECISION^FUNCTION^NAME^(ARG1[,^ARG2[,^...]]) or
^^^^^^INTEGER^FUNCTION^NAME^(ARG1[,^ARG2[,^...]]) or
^^^^^^REAL^FUNCTION^NAME^(ARG1[,^ARG2[,^...]]) or
^^^^^^LOGICAL^FUNCTION^NAME^(ARG1[,^ARG2[,^...]]) or
^^^^^^CHARACTER[*len]^FUNCTION^NAME^(ARG1[,^ARG2[,^...]])
C***BEGIN^PROLOGUE^^NAME
C***SUBSIDIARY
C***PURPOSE^^Brief (1-6 lines) summary of the purpose of this routine.
C^^^^^^^^^^^^(To best fit LDOC standards, first line should be suitable
C^^^^^^^^^^^^for a table of contents entry for this routine.)
C***LIBRARY^^^SLATEC[^(Package)]
C***CATEGORY^^CAT1[,^CAT2]
C***TYPE^^^^^^SINGLE PRECISION^(NAME-S,^DNAME-D)
C***KEYWORDS^^KEY1[,^KEY2[,
C^^^^^^^^^^^^^MORE]]
C***AUTHOR^^Last-name[,^First-name[,^(Organization)]][
C^^^^^^^^^^^^^More information][
C^^^^^^^^^^^Second-last-name[,^First-name[,^(Organization)]][
C^^^^^^^^^^^^^More information]]
C***DESCRIPTION
C^^
C^*Usage:
C^^ This subsection should have declarations for all arguments to the
C^^ routine and a model call of the routine. Use the actual names of
C^^ the arguments here. Ideally, arguments should be named in a way
C^^ that suggests their meaning.
C^^ The following example illustrates the use of dummy identifiers (in
C^^ lower case) to indicate that the required size of an array is
C^^ some function of the values of the other arguments. This may not
C^^ be legal Fortran, but should be easier for a knowledgeable user
C^^ to understand than giving the required size somewhere else.
C^^
C^^ INTEGER M, N, MDIMA, IERR
C^^ PARAMETER (nfcns = 6, nwks = 3*nfcns+M+7)
C^^ REAL X(nmax), A(MDIMA,nmax), FCNS(nfcns), WKS(nwks)
C^^
C^^ CALL NAME (M, N, X, A, MDIMA, FCNS, WKS, IERR)
C^^
C^*Arguments:
C^^ Arguments should be described in exactly the same order as in the
C^^ CALL list. Include any restrictions, etc.
C^^ The following illustrates the recommended form of argument descrip-
C^^ tions for the example given above. Note the use of qualifiers.
C^^
C^^ M :IN^ is the number of data points.
C^^
C^^ N :IN^ is the number of unknowns. (Must have 0.lt.N.le.M .)
C^^
C^^ X :IN^ is a real array containing ...
C^^ (The dimensioned length of X must be at least N.)
C^^
C^^ A :INOUT^ should contain ... on input; will be destroyed on
C^^ return. (The second dimension of A must be at least N.)
C^^
C^^ MDIMA:IN^ is the first dimension of array A.
C^^ (Must have M.le.MDIMA .)
C^^
C^^ FCNS:OUT^ will contain the six summary functions based on ...
C^^
C^^ WKS:WORK^ is a real array of working storage. Its length is a
C^^ function of the length of FCNS and the number of data
C^^ points, as indicated above.
C^^
C^^ IERR:OUT^ is an error flag with the following possible values:
C^^ Normal return:
C^^ IERR = 0 (no errors)
C^^ Warning error:
C^^ IERR > 0 means what?
C^^ "Recoverable" errors:
C^^ IERR =-1 if M < 1 or N < 1 .
C^^ IERR =-2 if M > MDIMA .
C^^ IERR =-3 means what?
C^^
C^*Function^Return^Values:
C^^ This subsection is present only in a FUNCTION subprogram.
C^^ In case of an integer- or character-valued function with a discrete
C^^ set of values, list all possible return values, with their
C^^ meanings, in the following form. [The colon is significant.]
C^^ value : meaning
C^^ Otherwise, something of the following sort is acceptable.
C^^ SQRT : the square root of X.
C^^
C^*Description:
C^^ One or more paragraphs describing the intended routine use,
C^^ dependencies on other routines, etc. Specific algorithm
C^^ descriptions could go here, if appropriate.
C^^ The emphasis should be on information useful to a user (as opposed
C^^ to developer or maintainer) of the routine.
C^^
C^*Examples:
C^^ Detailed examples of usage would go here, if desired.
C^^
C^*Accuracy:
C^^ This optional subsection contains notes on the accuracy or
C^^ precision of the results computed by the routine.
C^^
C^*Cautions:
C^^ List any known problems or potentially hazardous side effects
C^^ that are not otherwise described, such as not being safe for
C^^ multiprocessing or exceptional cases for arguments.
C^^ (Ideally, there should be none in a SLATEC routine!)
C^^
C^*See^Also:
C^^ This subsection would contain notes that refer to other library
C^^ routines that interrelate to this routine in important ways.
C^^ Examples include a solver for a LU factorization routine or an
C^^ evaluator for an interpolation or approximation routine.
C^^ This subsection may amplify information in the C***SEE ALSO
C^^ section, below, which should appear only if the prologue of the
C^^ listed routine(s) contains documentation for this routine.
C^^
C^*Long^Description:
C^^ An optional subsection containing much more detailed information.
C^^
C***SEE^ALSO^^RTN1[,^RTN2[,
C^^^^^^^^^^^^^RTNn]]
C***REFERENCES^^(NONE) or
C***REFERENCES^^1. Reference 1 ...
C^^^^^^^^^^^^^^^^^Continuation of reference 1.
C^^^^^^^^^^^^^^^2. Reference 2 ...
C^^^^^^^^^^^^^^^^^Continuation of reference 2.
C***ROUTINES^CALLED^^(NONE) or
C***ROUTINES^CALLED^^RTN1[,^RTN2[,
C^^^^^^^^^^^^^^^^^^^^RTNn]]
[Do not include standard Fortran intrinsics or externals.]
C***COMMON^BLOCKS^^^^BLOCK1[,^BLOCK2]
C***REVISION^HISTORY^^(YYMMDD)
[ This section should contain a record of the origin and ]
[ modification history of this routine. ]
C^^^871105^^DATE^WRITTEN
C^^^880121^^Various editorial changes. (Version 6)
C^^^881102^^Converted to new SLATEC format. (Version 7)
C^^^881128^^Various editorial changes. (Version 8)
C^
C***END^PROLOGUE^^NAME
C
C*Internal Notes:
C Implementation notes that explain details of the routine's design
C or coding, tricky dependencies that might trip up a maintainer
C later, environmental assumptions made, alternate designs that
C were considered but not used, etc.
C Details on contents of common blocks referenced, locks used, etc.,
C would go here.
C Emphasis is on INTERNALLY useful information.
C
C**End
C
C Additional comments that are not appropriate even for an internal
C document, but which the programmer feels should precede declarations.
C
C Declare arguments.
C
< Declarations >
C
C Declare local variables.
C
< Declarations >
C
C***FIRST^EXECUTABLE^STATEMENT^^NAME
< Body of NAME >
^^^^^^END
*******************************************************************************
ACKNOWLEDGEMENT
The authors wish to acknowledge the assistance provided by Dr. Frederick N.
Fritsch of the Computing and Mathematics Research Division, Lawrence Livermore
National Laboratory, who wrote Appendix E and made corrections and comments on
the manuscript.
*******************************************************************************
REFERENCES
[1] W. H. Vandevender and K. H. Haskell, The SLATEC mathematical subroutine
library, SIGNUM Newsletter, 17, 3 (September 1982), pp. 16-21.
[2] P. A. Fox, A. D. Hall and N. L. Schryer, The PORT mathematical subroutine
library, ACM Transactions on Mathematical Software, 4, 2 (June 1978), pp.
104-126.
[3] P. A. Fox, A. D. Hall and N. L. Schryer, Algorithm 528: framework for a
portable library, ACM Transactions on Mathematical Software, 4, 2 (June
1978), pp. 177-188.
[4] R. E. Jones and D. K. Kahaner, XERROR, the SLATEC error-handling package,
Software - Practice and Experience, 13, 3 (March 1983), pp. 251-257.
[5] R. F. Boisvert, S. E. Howe and D. K. Kahaner, GAMS: a framework for the
management of scientific software, ACM Transactions on Mathematical
Software, 11, 4 (December 1985), pp. 313-355.
[6] American National Standard Programming Language FORTRAN, ANSI X3.9-1978,
American National Standards Institute, 1430 Broadway, New York, New York
10018, April 1978.
[7] W. S. Brown, A simple but realistic model of floating point computation,
ACM Transactions on Mathematical Software, 7, 4 (December 1981), pp.
445-480.
[8] F. N. Fritsch, SLATEC/LDOC prologue: template and conversion program,
Report UCID-21357, Rev.1, Lawrence Livermore National Laboratory,
Livermore, California, November 1988.
Reference in a new issue View git blame Copy permalink