Re: Who uses clapack?
beliavsky_at_aol.com
Date: 12/11/04
- Next message: khufu: "Re: Euler method vindicated"
- Previous message: Jentje Goslinga: "Re: Who uses clapack?"
- In reply to: Jentje Goslinga: "Re: Who uses clapack?"
- Next in thread: James Van Buskirk: "Re: Who uses clapack?"
- Reply: James Van Buskirk: "Re: Who uses clapack?"
- Reply: Jentje Goslinga: "Re: Who uses clapack?"
- Messages sorted by: [ date ] [ thread ]
Date: 10 Dec 2004 17:18:51 -0800
>Many people nowadays perform numerical computations in C
>or C++ which are just as suitable as Fortran.
Fortran 95 still has many advantages over C and C++:
(1) true multidimensional arrays, with a wide range of intrinsic
functions like SUM and MAXVAL and the ability to use array sections
like a(1:10,:,2:10:2).
(2) the ability to pass one- and multi-dimensional arrays to functions
in a SIMPLE manner and to have functions returning arrays.
(3) arrays that can start at 0, 1, or any other user-specifed integer
(4) intrinsic functions like SIN that are generic to single, double,
and often quadruple precision, for both scalar and array arguments
(5) user-defined PURE and ELEMENTAL functions, to facilitate
parallelization and reduce the need for separate functions handling
scalar and array arguments
(6) better handling of complex numbers
(7) a form of DO loop that prevents the user from inadvertently
changing the loop variable. WHILE loops and and a DO-ENDDO loop with an
EXIT can be used when more flexibility is needed.
(8) the ability to EXIT from nested loops
superior facilities for reading and writing formatted tables of numbers
(9) a cleaner, less error-prone syntax. It is natural for the
end-of-line to terminate a statement by default, and to allow
continuation lines when needed. A misplaced semi-colon won't
drastically change the meaning of a Fortran code.
>There are many engineering applications with substantial
>number crunching which are written in C.
In my company substantial number crunching is done in Excel, because
some people refuse to learn anything else. Many C programmers seem to
have similar blinders.
>Most individuals and many smaller Engineering companies do
>not want to be perpetually burdened with having to purchase
>a license for a Fortran compiler for their workstations and
>would rather spend a few man days converting the Lapack
>modules which their application requires to C.
>Have you ever seen those bills for a Fortran compiler for an
>AIX machine? Have you ever had to fight SUN Fortran?
Much scientific computation that used to be done on commercial UNIX
platforms is now being done on Linux, where there are many commercial
Fortran 95 compilers. The Lahey/Fujitsu Linux compiler costs as little
as $250, and the Intel Fortran compiler is free for non-commercial use.
G95 at http://www.g95.org is 99.9% of a free, open-source Fortran 95
compiler for Linux, Windows, Mac OS X, and other platforms. Gfortran is
getting there.
>The problem with Lapack is that you can't read the code,
>that it is neither commented nor documented with a Technical
>Manual and that the algorithms referred to are detailed in
>obscure internal reports at certain universities.
Lapack documentation is at http://www.netlib.org/lapack/lug/index.html
, also as a printed book.
>the Lapack code uses 60's style programming:
>No dynamic memory allocation but the eternal WORK and IWORK
>arrays which are partitioned up in intricate ways.
>Does Lapack really need to cater to prehistorical compilers
>which do not support dynamic memory allocation?
Fortran 90/95 has dynamic memory allocation.
>The functions generally are too large with the familiar gobs
>of variables at the start and no attempt at resticting scope.
Fortran 90/95 functions and subroutines can have OPTIONAL arguments, so
that the user may only need to specify a few to get the default
behavior. The LAPACK95 interface to the LAPACK library already exists,
and using it, a subroutine call such as
call SGELSD(M, N, NRHS, A, LDA, B, LDB, S, RCOND, RANK, WORK,LWORK,
IWORK, INFO)
can be replaced with just
CALL LA_GELSD (A, B)
>There are no Modules containing related functions but every function
is separate.
Fortran 90/95 has something called a "MODULE" that does exactly this.
To get compile-time checking of procedure interfaces, the
"pre-historic" #include statements of C/C++ are not needed.
>The single precision versions are useless in my opinion but
>others may disagree, at the very least relegate them to
>recognizeable modules so users who do not want them can leave
>them out.
The single precision codes of LAPACK start with the letter S, as
described at http://www.netlib.org/lapack/individualroutines.html , and
are thus easy to recognize.
Ideally, each of the BLAS calls could be replaced by calls to Fortran
90/95 intrinsic functions or array operations, improving readability.
You have indirectly made a good case for writing the next version of
LAPACK in Fortran 95.
In general, one should try to gain a current understanding of a
subject, in this case Fortran, before making recommendations about it
to others. There are Fortran 90/95 tutorials at
http://www.dmoz.org/Computers/Programming/Languages/Fortran/Tutorials/Fortran_90_and_95/
.
- Next message: khufu: "Re: Euler method vindicated"
- Previous message: Jentje Goslinga: "Re: Who uses clapack?"
- In reply to: Jentje Goslinga: "Re: Who uses clapack?"
- Next in thread: James Van Buskirk: "Re: Who uses clapack?"
- Reply: James Van Buskirk: "Re: Who uses clapack?"
- Reply: Jentje Goslinga: "Re: Who uses clapack?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
