Numerical Recipes
AdaWorks
often wondered if anyone has a version in process for Ada. It occurred
to me that this would make a good writing project for someone. Alas, it
cannot be me because I have long ago lost whatever mathematics skills are
necessary to do all the coding and testing and proving that the solutions are
both optimal and correct.
But I would love to have a copy of this programmed in Ada 95.
Richard Riehle
ric...@adaworks.com
--
ric...@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX 328-1112
Robert C. Leif, Ph.D.
To: Richard Riehle et al.
Subject: Numerical Recipes
Date: 23 November, 1995
Richard Riehle wrote
----------------------------------------------------------------------------
---------------
>
>Date: Wed, 22 Nov 1995 23:02:58 GMT
>From: AdaWorks <adaw...@NETCOM.COM>
>Subject: Numerical Recipes
>
>There is a set of Numerical Recipes books for C, Fortran, and Pascal. I have
>often wondered if anyone has a version in process for Ada. It occurred
>to me that this would make a good writing project for someone. Alas, it
>cannot be me because I have long ago lost whatever mathematics skills are
>necessary to do all the coding and testing and proving that the solutions are
>both optimal and correct.
>
>But I would love to have a copy of this programmed in Ada 95.
----------------------------------------------------------------------------
-----------------
Richard, as usual, you asked the right question.
In fact, one of the major impediments to the adoption of Ada for engineering
is the lack of Numerical Recipes in Ada. This book is the Engineers'
security blanket. If Ada is to be used in the commercial engineering
sector, then AJPO or some other DoD group should be proactive in sponsoring
the production of Numerical Recipes in Ada. The Pascal version is
diminishing in popularity.
In my own field, Analytical Cytology, the specification of the Flow
Cytometry 3.0 standard included a reference to an algorithm in Numerical
Recipes in C. Needless to say, I objected.
Simple question, Is Numerical Recipes used by any of the Military
Educational establishments? If so, how many copies per year?
Could the Numerics Working Group help? It may be possible to use R&R
Pastran to translate some of the Pascal code. I quite well understand that
Ada numerics are much more complete than Pascal's. However, algorithms and
comments may be reusable.
Numerical Recipes is published by Cambridge University Press NY
40 w. 20th St.
New York, N.Y.
Tel. 212-924-3900
Lauren Cowles xt 438 is the person responsible for Numerical Recipes
Robert C. Leif, Ph.D., PMIAC,
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
5648 Toyon Road
San Diego, CA 92115
Tel. & Fax (619) 582-0437
e-mail rl...@mail.cts.com
tmo...@bix.com
>Summary: Is Anyone Working on this for Ada
A year or so ago I asked the authors and was told no. I'd be happy
to contribute an Ada 'Selecting the Mth largest' which also corrects
an error in at least the Fortran version in the book. Also some
'Linear Prediction and Linear Predictive Coding' and power sprectral
estimation stuff. But note there seems to be some question in
Numerical Analysis circles about some of the algorithms used.
Brian Rogoff
There is a set of Numerical Recipes books for C, Fortran, and Pascal. I have
often wondered if anyone has a version in process for Ada. It occurred
to me that this would make a good writing project for someone. Alas, it
cannot be me because I have long ago lost whatever mathematics skills are
necessary to do all the coding and testing and proving that the solutions are
both optimal and correct.
But I would love to have a copy of this programmed in Ada 95.
Richard Riehle
ric...@adaworks.com
Why? You could certainly use the C or Fortran version with the Ada 95 FFI,
right?
If you really wanted something that used the special characterics of Ada 95,
you would be better off cribbing from LAPACK++ or LASPACK for an OO
numerical linear algebra library design, and lookig elsewhere for other
parts of Numerical Recipes that you wanted to translate.
I agree with your (implicit) point that Ada 95 looks like a nice language
for scientific computing. Is anyone out there writing scientific libraries
in Ada 95 yet? I couldn't get an earlier version of GNAT running on our
Indys a few months ago so I gave up, maybe I'll try again.
-- Brian
Robert Dewar
"I agree with your (implicit) point that Ada 95 looks like a nice language
for scientific computing. Is anyone out there writing scientific libraries
in Ada 95 yet? I couldn't get an earlier version of GNAT running on our
Indys a few months ago so I gave up, maybe I'll try again."
I expect both the SGI and freely distributed versions of 3.01 to appear
next week (they are slightly different with respect to some debugging
information that is generated and a couple of other minor issues, but
they are basically the same, and both based on the version that was validated
(although neither technically has validated status, since the certificate
has not been issued yet).
So that's probvably the point at which to try again, and let us know if
you have difficulties.
The only freely available SGI version previously is 2.04, which is indeed
very far out of date.
AdaWorks
: Could the Numerics Working Group help? It may be possible to use R&R
: Pastran to translate some of the Pascal code. I quite well understand that
: Ada numerics are much more complete than Pascal's. However, algorithms and
: comments may be reusable.
The use of Pastran is an interesting idea. Of course, Pastran is an
Ada 83 model, but it would be a start toward developing the Ada 95
version. Also, the Pascal versions do not have any kind of packaging
or generic capabilities.
The Pascal algorithms are all available on magnetic media, usually
sold in the bookstore right next to the book.
Several people have sent me personal email with an interest in this
project. Now it is a matter of what kind of copyright problems might
manifest themselves. It would be best if the publisher of the orginal
book series would contract someone to do this.
Richard Riehle
: Numerical Recipes is published by Cambridge University Press NY
: 40 w. 20th St.
: New York, N.Y.
: Tel. 212-924-3900
: Lauren Cowles xt 438 is the person responsible for Numerical Recipes
--
Brian Rogoff
iI am still a little puzzled, are these numerical recipes callable code?
Yes. Not many data structures, and no sparse matrix library in the version
I used.
In that case why would one recode them in Ada, simply compile them in
the other language and link to them.
Indeed, why not? Isn't this what Interfaces.C is for?
What is the advantage of translating them, especially if you use a
toolk like Pastran, which is pretty much bound to generate dubious
Ada code ...
I suspect that the original poster thinks that Ada would be better than
C for this kind of programming. I think so, but I think a numerical library
designed from scratch by people familiar with Ada 95 features would be
nicer than an "Adatran" library.
-- Brian
Robert Dewar
" Yes, they are callable code. The simple answer to why recode in Ada
is that not everyone has an Ada 95 with a nice Pragma Interface, and
not everyone has a Fortran, C, or Pascal compiler that interfaces to it.
The more general answer is the same as 'why use Ada?'."
Hmm! somewhat unconvincing, I still don't see any point in simply recoding
things in Ada, and this is NOT the same as "why use Ada", there is a big
difference between choosing the best language for new code, and simply
recoding stuff.
Actually tmoran (sorry is this Ted, my news reader does not reveal the
full name here?) I think agrees, because he goes on to point out that
if the components are reengineered in Ada, as opposed to merely being
recoded, then they can be much more powerful and useful.
I certainly agree with that, and think that such an effort is far
more worthwhile than attempting an automatic translation with a tool
like Pastran.
tmo...@bix.com
>I am still a little puzzled, are these numerical recipes callable code?
>them, especially if you use a toolk like Pastran, which is pretty much
>bound to generate dubious Ada code ...
Yes, they are callable code. The simple answer to why recode in Ada
is that not everyone has an Ada 95 with a nice Pragma Interface, and
not everyone has a Fortran, C, or Pascal compiler that interfaces to it.
The more general answer is the same as 'why use Ada?'.
For example, In the Fortran book:
FUNCTION select(k,n,arr)
INTEGER k,n
REAL select,arr(n)
...
'returns the kth smallest value in the array arr(1:n) ...'
is callable code. But perhaps one wants the kth smallest in an array of
integers, or records, or anything other than REALs. Or perhaps the index
is not an INTEGER. Or perhaps the index range is such that 'mid=(l+ir)/2'
is likely to cause an overflow and one would prefer code a little more
carefully written. Or perhaps using lower case 'L' as an index variable
is so repugnant that your organizational or personal style guides forbid
use of any such code. Or in this particular subroutine there is an error
in the looping that causes it to wastefully re-sort already sorted parts
of the array. Translated to Ada with suitable naming, and looping
constructs other than 'if ... goto', that CPU wasting bug is much more
visible and is then easily fixed. None of those changes will be done by a
mere automated transliteration to Ada, of course, but it just might be
worth it to some folks to have a robust, reusable, "Ada quality" component.
Robert C. Leif, Ph.D.
e-mail rl...@crash.cts.com
Date: Monday, November 27, 1995
>Date: Sat, 25 Nov 1995 22:15:28 -0500
>From: Robert Dewar <de...@CS.NYU.EDU>
>Subject: Re: Numerical Recipes
>I am still a little puzzled, are these numerical recipes callable code?
>In that case why would one recode them in Ada, simply compile them in
>the other language and link to them. What is the advantage of translating
>them, especially if you use a tool like Pastran, which is pretty much
>bound to generate dubious Ada code ...
If you are using one algorithm, you are correct. However, if Ada is to be
an accepted language for engineering, it should have its own libraries,
which take advantage of its superior numerics and safety. Also, I suspect
debugging and performance may be hurt by interfacing between two languages.
The subject will become even more complex when multiple processors are
employed. Lastly, we need a standard science and engineering numerics core
to expand upon.
Some of us are not very good at reading C and would like to keep our work,
at least, within the Pascal family of languages. I suspect that most Pascal
and Modula programmers would also like to stay with the Pascal family of
languages. The desirability of Ada would be greatly enhanced by being able
to upgrade the existing Pascal and Modula software. Microsoft's Excel would
never have obtained market share, if it had not been able to read Lotus 123
templates.
As far as the generation of dubious Ada code, I very carefully wrote, "It
may be possible to use R&R Pastran to translate some of the Pascal code. I
quite well understand that Ada numerics are much more complete than
Pascal's. However, algorithms and comments may be reusable." I did NOT
write program structure or that one should accept the translation as is. I
should also have noted, that this would have facilitate reuse of the text of
the Pascal version of Numerical Recipes.
Robert C. Leif, Ph.D., PMIAC,
Vice President & Research Director
Ada_Med, A Division of Newport Instruments
5648 Toyon Road
San Diego, CA 92115
Tel. & Fax (619) 582-0437
e-mail rl...@crash.cts.com
AdaWorks
: iI am still a little puzzled, are these numerical recipes callable code?
: In that case why would one recode them in Ada, simply compile them in
: the other language and link to them. What is the advantage of translating
: bound to generate dubious Ada code ...
Robert,
First, I agree about the potentially questionable quality of transalated
code. In my experience, translating from one language to another
is like "kissing through a hedge," to quote Nikita Khruschev. And
automatic translators have a way of getting one a mouth full of thorns.
But I suspect one can experience some of the same problems when relying on
such tricks as pragma import, even with the benefit of pragma Convention.
Indeed, Robert. Why even bother to use Ada at all? And all of those
data structures that are already coded in Pascal and Modula-2? Why
not just use them as they are? The Booch components and the GRACE
library are probably superfluous. :-)
My preference would be to have them in Ada. This would be useful for both
production and pedagogical reasons. Also, some of the algorithms, as coded
in these other languages just do not present the same level of capability
one might expect from Ada. For example, none of them provide a generic
capability. Also, there are some excellent things one could do with
Ada packages to factor out common properties, more easily combine some
of the workhorse routines into hierarchical library units, and build in
a certain amount of exception handling. As for the algorithms themselves,
I think an Ada version would be more readable.
One minor point. Having this kind of stuff coded and available in Ada
would have a positive impact on Ada's image. Over the years with Ada 83
it was always a nuisance when we had to pragma interface to C to get
simple chores done. I would like to see the time when the use of
pragma import is the exception because the Ada compiler includes everything
one needs to do the job.
Richard Riehle
Brian Rogoff
Robert Dewar (de...@cs.nyu.edu) wrote:
: iI am still a little puzzled, are these numerical recipes callable code?
: In that case why would one recode them in Ada, simply compile them in
: the other language and link to them. What is the advantage of translating
: them, especially if you use a toolk like Pastran, which is pretty much
: bound to generate dubious Ada code ...
Robert,
<deletia>
Indeed, Robert. Why even bother to use Ada at all? And all of those
data structures that are already coded in Pascal and Modula-2? Why
not just use them as they are? The Booch components and the GRACE
library are probably superfluous. :-)
I think there is no disagreement in this entire thread. Those who are posting
that it would be better to interface to the existing C code absolutely agree that
a "pure Ada" numerical library utilizing the appropriate linguistic features of
Ada would be good. But the original question was about translating Numerical Recipes
to Ada. Since that library is so "low-level", I just don't think it makes sense to
waste time on it, except to familiarize yourself with the mathematical ideas .
If highlighting the strengths of Ada is a goal, start afresh, with a
modern library. I think a nice place to start would be numerical linear algebra,
and the web page
http://netlib2.cs.utk.edu/linalg/html_templates/report.html
has a lot of modern algorithms in pseudo-Algol for iterative solvers, nice
explanations, an actual hardcopy book for the web-challenged. There is already a
C++ version of this in the works at
http://gams.nist.gov/acmd/Staff/RPozo/iml++.html
-- Brian
Tom Moran
>...translating Numerical Recipes to Ada. Since that library is
>so "low-level", I just don't think it makes sense to waste time
>on it, except to familiarize yourself with the mathematical ideas .
>
Is that the goal? The original post said things about lots of
people using the 'Numerical Recipes in ...' books for cookbook
numerical code. Those folks' object is to sort some data, estimate
a power spectrum, or whatever. Their goals often do not include
highlighting the strength of a language or familiarizing themselves
with the mathematical ideas. If they have a power spectrum to
estimate, an Ada compiler, a Fortran compiler, and the '... in
Fortran' book, they will use Fortran. If they had instead the
'... in Ada' book, they would use Ada.
A potential author should first of all know his audience. Am I
quite mistaken about the target market for the 'Numerical Recipes
in ...' books?
P.S. The original post suggested it would be nice to have an '...
in Ada' version, without specifying how Ada-ish that might be. It
was a later post that suggested the possibility of a quick and
dirty automated translation.
Robert Dewar
there is nothing equivalent in Ada. And for some widely used problem solution,
e.g. numerics, I believe it would be a good thing to build something in "our"
language."
I completely agre with the above. I absolutely think that reengineering
libraries to take full advantage of Ada 95 where the resources exist to
do this properly is an excellent idea. My concern was that there is no
point in merely "translating" exisiting libraries into Ada 95 in a manner
that provides no additional functionality. That is simply a waste of
effort, and at best achieves very little, and at worst introduces bugs.
One argument was that such translation is good because there are people who
don't know C etc. only Ada. That seem bogus to me. Obviously you need an
Ada package interface that contains the necessary pragma Import stuff and
other aspects of a thin binding, but as usual in Ada, a user of this package
does not need to even look at the body of the implementation, let alone
understand the language in which it is written, if the library is a
reliable component.
Basically it seems to me that two kinds of things are useful. Think interface
(oops, I mean *thin* interface) bindings to existing libraries in whatever
languages, and reengineering of existing libraries to take advantage of
Ada. Clearly which is appropriate depends on the case and on the resources.
For example, STL clearly needs reengineering, but SGI is not about to
reengineer Inventor.
But let's not waste time doing simple straight translations, especially
not those done by, or assisted by simple minded translation tools, because
that path tends to lead to stuff that is not properly thought out in Ada
from first pricciples, which is what is needed if you are reengineering.
pjoh...@iquest.com
>iI am still a little puzzled, are these numerical recipes callable code?
>In that case why would one recode them in Ada, simply compile them in
>the other language and link to them. What is the advantage of translating
>them, especially if you use a toolk like Pastran, which is pretty much
>bound to generate dubious Ada code ...
The various "Numerical Recipes" [FORTRAN, C, PASCAL] are a combination of
algorithm, source code, and test bed. The code has to be compiled. This
requires one to have the appropriate development tools. The reason there
has been three iterations of the recipes is to demonstrate how numerical
algorithms can be implemented in various languages. The problem that I
have found is that each implementation was nothin more than a tranlation
of the original code [read -- FORTRAN written in C and PASCAL].
One problem with translating the "Numerical Recipes" code is probable
copyright infringement as the books and source code are copyrighted.
What would be nice is to have the algorithms implemented in Ada from the
algorithmic description rather than from the code example. I have done
this to several other numeric algorithms. It is amazing how different the
implementation is when you design the code from scratch with a specific
language in mind.
Phil Johnson
Joerg Rodemann
: There is a set of Numerical Recipes books for C, Fortran, and Pascal. [...]
: But I would love to have a copy of this programmed in Ada 95.
Hi folks!
I agree with those who want to have a real Ada version of the numerical
recipes. The argument about interfacing is very dangerous in my point of view.
If you walk that way you also might ask: why code then in C --- just use the
Fortran version. Certainly I admit that the interface mechanism in Ada is a
great thing because a lot of libraries is coded in other languages for the
moment. And for sure I also have not enough spare time to translate the
X11-sources to Ada-95... ;->
But on the other hand --- if we want Ada-95 to become a really widely used
language --- it is better if there are also a lot of Ada-libraries already
exisiting for various problems. Imagine I would like to write a piece of
code with a little bit of numeric, and the program has to be in C...would you
like to care about the Fortran-Version of the library? Sure: each time you
rewrite a code fragment you will have to test it from the beginning...
And yet --- in Ada some very dangerous constructions and errors might not
occur that are existing in other version. E.g. my C-compiler did not warn me
at once as I passed a pointer to a double precision float to a function that
expected a pointer to a single precision... Well, I can live with such
problems but I can do without them as well!
Now my own conclusion is: use the tested C (or Cobol, Fortran) libraries if
there is nothing equivalent in Ada. And for some widely used problem solution,
e.g. numerics, I believe it would be a good thing to build something in "our"
language.
Greetings
George Rodemann
--
Joerg 'George' Rodemann Erhard-Groezinger-Strasse 82
Department of Physics D-89134 Blaustein
University of Ulm Tel. (0731) 553319
e-mail: rode...@mathematik.uni-ulm.de
AdaWorks
and posted a note about the following book of Numerical Recipes written
in French. Amazing what one can learn by posting a serious query on
this forum.
: Jean-Etienne Rombaldi
: Algorithmique num\'erique et Ada
: Masson (1994)
: ISBN 2-225-84384-8
[snip]
: Make the author active for you by buying its book!
Merci, Monsieur Gasser.
I am ordering my copy today. Guess I'd better brush-up on my reading
French.
Richard Riehle
ric...@adaworks.com
Laurent Gasser
contains everything which is studied in an undergraduate course in
numerical analysis, with a consequent library in Ada 83.
I found my message to Mike:
Jean-Etienne Rombaldi
Algorithmique num\'erique et Ada
Masson (1994)
ISBN 2-225-84384-8
This is a book entierly dedicated to numerical analysis in Ada 83.
The book goes through the topics of solving linear systems, of
eigenvalues, of approximations and interpolations, of numerical
integration, of differential equations (ODE) and finite differences
(with an example of finite elements). The approach is rather about
introducing the theory and the usage of the code on disc. The book is
in French, with a code not so independent of the compiler OpenAda for
PC-DOS. A very complete library, and I know that the author (now in
Corse) works at making a Window interface to it.
Make the author active for you by buying its book! (I have no direct
or indirect interest in the selling of the book, by the way.)
--
Laurent Gasser (gas...@dma.epfl.ch)
Computers do not solve problems, they execute solutions.
tmo...@bix.com
>... Numerical Recipes in Ada. This book is the Engineers security blanket.
>
>In my own field, Analytical Cytology, the specification of the Flow
>Cytometry 3.0 standard included a reference to an algorithm in Numerical
>Recipes in C.
I think these comments should be noted very seriously by those who
would write a brand new "Gourmet Numerical Recipes in Ada" book.
Such a book, excellent though it might be in algorithms,
explanations, and implementing code, would not automatically be part
of an existing, accepted standard. Eventually, hopefully, but not in
the near future.
Re Pragma Interface: what fraction of current Ada users have easy
access to a Fortran, C, or Pascal compiler they can interface to?
More than 90%? Is there a Fortran, Pascal, or C compiler that can be
used via Pragma Interface with the Patriot validated Ada 95 system?