Who uses clapack?

The authors of lapack/scalapack are starting to work on a new release of
these packages. One of the things we want to address is the sillyness
that C users, instead of linking to the binaries of the Fortran version,
use an automatically translated C version.

Therefore we'd like to know precisely what the reasons for this are.

Naively one would say, compile the Fortran version, append an underscore
(when appropriate) to routine names, and just link those libraries to
your object files.

What are the gotchas, and what are the real stumbling blocks here?
Please spell it out in as much detail as you can muster. This situation
really needs to improve.

V.
--
email: lastname at cs utk edu
homepage: www cs utk edu tilde lastname

see.sig@for.addy (Victor Eijkhout) wrote:
>The authors of lapack/scalapack are starting to work on a new release of
>these packages. One of the things we want to address is the sillyness
>that C users, instead of linking to the binaries of the Fortran version,
>use an automatically translated C version.
>
>Therefore we'd like to know precisely what the reasons for this are.
>
>Naively one would say, compile the Fortran version, append an underscore
>(when appropriate) to routine names, and just link those libraries to
>your object files.
>
>What are the gotchas, and what are the real stumbling blocks here?
>Please spell it out in as much detail as you can muster. This situation
>really needs to improve.

The reasons may be more political than technical. At my company, the IT depa
rtment
is Fortran-phobic, so if someone in the research department hands them a
code with mixed C++ and Fortran 77, they will want the F77 part to be f2c'ed
.
They believe that FORTRAN is unmaintainable because they don't know FORTRAN.

I can use Fortran to get work done, but only if I stay out of their sight.
I hate IT people.

I know of at least one other company in my industry (financial services)
with a policy that all production code must be in C++. Researchers can exper
iment
in Matlab etc., but eventually code must be migrated.

I find it odd that you think people ought to use Fortran LAPACK rather than
clapack, when it appears from http://www.fortranstatement.com/cgi...ures.p
l
that you signed a "petition to retire Fortran", which contains lies such
as "FORTRAN2003 Adds No Functionality".



----== Posted via mcse.ms - Unlimited-Uncensored-Secure Usenet News==-
---
http://www.mcse.ms The #1 Newsgroup Service in the World! >100,000 New
sgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =
---

Victor Eijkhout wrote:
> The authors of lapack/scalapack are starting to work on a new release
of
> these packages. One of the things we want to address is the sillyness
> that C users, instead of linking to the binaries of the Fortran
version,
> use an automatically translated C version.
>
> Therefore we'd like to know precisely what the reasons for this are.
>
> Naively one would say, compile the Fortran version, append an
underscore
> (when appropriate) to routine names, and just link those libraries to
> your object files.
>
> What are the gotchas, and what are the real stumbling blocks here?
> Please spell it out in as much detail as you can muster. This
situation
> really needs to improve.
>
> V.
> --
> email: lastname at cs utk edu
> homepage: www cs utk edu tilde lastname

As a person who used to use CLAPACK until I found it was just as easy
to link to the FORTRAN libs, I would dare say there are those who use
CLAPACK because they don't realize there are other alternatives.  Also,
CLAPACK comes with the header file needed to use either the FORTRAN or
CLAPACK libraries, whereas if you download the pre-built libraries from
http://www.netlib.org/lapack/archives/, the header files are not
present.  This is a small issue, but could be a problem for people who
are less familiar with the library structure or the semantics for
calling a FORTRAN library from C/C++.  Just my thoughts...

On a slightly related note, is there any effort (or even thought) being
put into the development of a "standardized" C++ object-oriented LAPACK
library?  Something to wrap around the BLAS and LAPACK, perhaps?
Best,
Ryan

"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> wrote:

> I find it odd that you think people ought to use Fortran LAPACK rather
> than clapack, when it appears from
> http://www.fortranstatement.com/cgi-bin/signatures.pl that you signed a
> "petition to retire Fortran", which contains lies such as "FORTRAN2003
> Adds No Functionality".

Hee. I forgot about that. And I don't think it's relevant for my
question.

Lapack/Scalapack is 500,000 lines of tremendously useful legacy code,
and it's not going to go away anytime soon. At the moment my only
ambition is to make that code as cleanly usable from other languages as
possible. Using automatically translated versions is at the least a
support nightmare.

Thanks for your response,

V.
--
email: lastname at cs utk edu
homepage: www cs utk edu tilde lastname

Tino <tino52@yahoo.com> wrote:

> On a slightly related note, is there any effort (or even thought) being
> put into the development of a "standardized" C++ object-oriented LAPACK
> library?  Something to wrap around the BLAS and LAPACK, perhaps?

The thought has occurred to many people. I mean, passing LDA into a C++
routine is the programming equivalent of turning a crank handle on the
space shuttle. Now, what to do about it....

I've started looking at Sidl/Babel to get a more native looking
interface in other languages than F77. Not sure to what extent that will
satisfy you.

V.
--
email: lastname at cs utk edu
homepage: www cs utk edu tilde lastname

In <1gokq2z.1qtze21fbcwaoN%see.sig@for.addy> see.sig@for.addy (Victor Eijkho
ut) writes:

>The authors of lapack/scalapack are starting to work on a new release of
>these packages. One of the things we want to address is the sillyness
>that C users, instead of linking to the binaries of the Fortran version,
>use an automatically translated C version.
>
>Therefore we'd like to know precisely what the reasons for this are.
>
>Naively one would say, compile the Fortran version, append an underscore
>(when appropriate) to routine names, and just link those libraries to
>your object files.
>
>What are the gotchas, and what are the real stumbling blocks here?
>Please spell it out in as much detail as you can muster. This situation
>really needs to improve.

The issue that springs to mind is that Fortran and C store matrices
differently: Fortran does it column-wise (the first index varies fastest),
C does it row-wise (the last index varies fastest).

The fact that Fortran array indexing is 1-based (by default) and C array
indexing is 0-based shouldn't cause any problems when using the compiled
Fortran code from C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

Victor Eijkhout wrote:
> "beliavsky@aol.com" <beliavsky@127.0.0.1:7501> wrote:
>
> 
>
>
> Hee. I forgot about that. And I don't think it's relevant for my
> question.
>
> Lapack/Scalapack is 500,000 lines of tremendously useful legacy code,
> and it's not going to go away anytime soon. At the moment my only
> ambition is to make that code as cleanly usable from other languages as
> possible. Using automatically translated versions is at the least a
> support nightmare.
>
> Thanks for your response,
>

The reasons that folks translate are more at the level of urban legends
and about as well informed as your wanting to retire Fortran.

The urban legends may relate to the problems of doing mixed languages.
You might require run time libraries for both but only have one
compiler. There is surely some amount of pure bigotry which may
be passed along by PHBs (Pointy Haired Boss - see Dilbert for a full
explanation). Policy may dictate that full source must be available
even if it is unreadable and unmaintainable in practice. This allows
the source to be recompiled on new and yet unknown machines. The new
machine may actually be the same old machine but with a new version
of its system software.

Each of these is of the "enduring nonsense" variety as there is a small
amount of technical justification which might apply is some circumstance
that typically has no relevance to the situation in which it is now
applied.

> V.

Dan Pop <Dan.Pop@cern.ch> wrote:

> The issue that springs to mind is that Fortran and C store matrices
> differently: Fortran does it column-wise (the first index varies fastest),
> C does it row-wise (the last index varies fastest).
>
> The fact that Fortran array indexing is 1-based (by default) and C array
> indexing is 0-based shouldn't cause any problems when using the compiled
> Fortran code from C.

These sort of issues make me wonder why clapack is considered so great:
it does not provide arrays in the C-natural order, and in some places
the 1-based indexing is exposed, such as in pivoting of the
factorization.

When we write a more C-native interface we'll try to cover these issues.
It will mean some minimal bit of glue code that will hardly impact
performance.

Thanks for your response.

V.
--
email: lastname at cs utk edu
homepage: www cs utk edu tilde lastname

Victor Eijkhout wrote:
> The authors of lapack/scalapack are starting to work on a new release of
> these packages. One of the things we want to address is the sillyness
> that C users, instead of linking to the binaries of the Fortran version,
> use an automatically translated C version.
>
> Therefore we'd like to know precisely what the reasons for this are.
>
> Naively one would say, compile the Fortran version, append an underscore
> (when appropriate) to routine names, and just link those libraries to
> your object files.
>
> What are the gotchas, and what are the real stumbling blocks here?
> Please spell it out in as much detail as you can muster. This situation
> really needs to improve.
>
> V.

The following are just my opinions based on my experience.

One reason is, the clapack's installation instructions are crystal
clear. I mean it is very easy and gives step by step instructions as to
what to do.

But on the other hand, lapack gave me hell of a trouble while compiling.
Compiling with intel compiler gave some IEEE errors (cant recall them
exactly, but if you are interested, they could be found on c.l.f
archives) The lapack/lapack95 instructions are cryptic and probably can
be understood only by experts. But now I have intel mkl library
available for free. So I dont have to compile them myself.

raju

Dan Pop wrote:

(snip regarding lapack and clapack)

> The issue that springs to mind is that Fortran and C store matrices
> differently: Fortran does it column-wise (the first index varies fastest),
> C does it row-wise (the last index varies fastest).

> The fact that Fortran array indexing is 1-based (by default) and C array
> indexing is 0-based shouldn't cause any problems when using the compiled
> Fortran code from C.

Some people who write numerical algorithms in Fortran exchange
the subscripts from the mathematical description, and others don't.

With cache memory and virtual memory one should always be sure that
the loops correspond to the memory layout in the appropriate language.

-- glen