NUMERICAL RECIPES

[robin]

| I think the
| Numerical Recipes books are excellent introductions to many
| computational problems, including linear algebra. I do agree that
| the code itself that is given in the book is sometimes not the most
| robust, but on the other hand, something like LAPACK code is robust
| but too complicated for a beginner to understand easily.

Numerical Recipes is an authoritative source of information
about a vast number of numerical procedures.

Therefore I endorse Ron Shepherd's remark that it is an
"excellent introductions to many computational problems, including linear algebra".

At more than 1200 pages, and more than 400 propgrams/procedures,
there is something there for everybody.

Three editions have been published.
________________

New in the Third Edition (2007):

* A new chapter on classification and inference,
including such topics as Gaussian mixture models,
hidden Markov modeling, hierarchical clustering
(phylogenetic trees), and support vector machines.
* A new chapter on computational geometry, including
topics like KD trees, quad- and octrees, Delaunay
triangulation and applications, and many useful
algorithms for lines, polygons, triangles, spheres, and
so on.
* Many new statistical distributions, with pdf's, cdf's,
and inverse cdf's
* An expanded treatment of ODEs, emphasizing recent
advances, and with completely new routines
* Much-expanded sections on uniform random
deviates. and on deviates from many other statistical
distributions
* An introduction to spectral and pseudospectral
methods for PDEs
* Interior point methods for linear programming
* More on sparse matrices
* Interpolation on scattered data in multidimensions
* Curve interpolation in multidimensions
* Quadrature by variable transformation, and adaptive
quadrature
* More on Gaussian quadratures and orthogonal
polynomials
* More on accelerating the convergence of series
* Improved incomplete gamma and beta functions,
and new inverse functions
* Improved spherical harmonics and fast spherical
harmonic transforms
* Generalized Fermi-Dirac integrals
* Multivariate Gaussian deviates
* Algorithms and implementations for hash memory
functions
* Incremental quantile estimation
* Chi-square with small numbers of counts
* Dynamic programming
* Hard and soft error correction, and Viterbi decoding
* Eigensystem routines for real, nonsymmetric matrices
* Multitaper methods for power spectral estimation
* Wavelets on the interval
* Information-theoretic properties of distributions
* Markov chain Monte Carlo
* Gaussian process regression and Kriging
* Stochastic simulation of chemical reaction networks
* Code for plotting simple graphs from within programs

 

[bert]

Numerical Recipes is an authoritative source of information
about a vast number of numerical procedures.

Maybe so, but the version "Numerical Recipes in C"
was a travesty. Practically all of the C code had
been transliterated quite mindlessly from Fortran,
making hardly any use of C idioms which would
have made the code cleaner and neater. In
particular, there was scarcely any use of pointers.
So authoritative about procedures, maybe, but as
for authoritative about C, absolutely not.
--

 

[robin]

Numerical Recipes is an authoritative source of information
about a vast number of numerical procedures.

Maybe so, but the version "Numerical Recipes in C"
was a travesty.

Wasn't that published in about 1992?

I clearly stated that I was referring the information and the procedures,
and in particular to the 2007 edition.

Practically all of the C code had
been transliterated quite mindlessly from Fortran,
making hardly any use of C idioms which would
have made the code cleaner and neater. In
particular, there was scarcely any use of pointers.

Pointers are probably best avoided.

So authoritative about procedures, maybe, but as
for authoritative about C, absolutely not.

It doesn't pretend to be.
The authors clearly state that NR is "NOT [emphasis added]
a textbook on programming, or on best programming practices, or on C++, ..."

 

[Malcolm McLean]

Maybe so, but the version "Numerical Recipes in C"
was a travesty.  Practically all of the C code had
been transliterated quite mindlessly from Fortran,

I've spent many a day rewriting Numerical Recipes code so that it
actually fits with the rest of my C program.

 

[aruzinsky]

The same thing happened with Collected Algorithms from ACM. Volumes
I, ii and III were nice with many good general purpose algorithms,
although written mostly in algol (see http://en.wikipedia.org/wiki/ALGOL)
and some Fortran. These volumes are a good competitor to Numerical
Recipes. The volumes that followed were too specialized and the
algorithms were on microfiche.

 

[nmm1]

I found there was a lot of work translating the algorithms into PL/I
too, for the same reason. You can't just translate the code
one-for-one, but have to translate the intent instead.

If that were all :-( As pointed out several times, you often have
to fix the code as well.

That being said, I've found the first edition quite useful.

Which included the worst random number generators that I had seen
in 25 years of refereeing on that topic - MUCH worse than RANDU.
They started to give wrong answers in trivial, realistic tests
with only 200 numbers.



Regards,
Nick Maclaren.

 

[Peter Flass]

Maybe so, but the version "Numerical Recipes in C"
was a travesty. Practically all of the C code had
been transliterated quite mindlessly from Fortran,
making hardly any use of C idioms which would
have made the code cleaner and neater. In
particular, there was scarcely any use of pointers.
So authoritative about procedures, maybe, but as
for authoritative about C, absolutely not.
--

I found there was a lot of work translating the algorithms into PL/I
too, for the same reason. You can't just translate the code
one-for-one, but have to translate the intent instead.

That being said, I've found the first edition quite useful.

 

[glen herrmannsfeldt]

Maybe so, but the version "Numerical Recipes in C"
was a travesty. Practically all of the C code had
been transliterated quite mindlessly from Fortran,
making hardly any use of C idioms which would
have made the code cleaner and neater.

(snip)

This one I agree with, though if you go through the routine
and fix up those problems, in the end you learn more about
how it works. It did that at least once, and it took a while
to get right. (Especially all the loops indexing arrays
from zero instead of one.)

-- glen

 

[Seebs]

Pointers are probably best avoided.

Not in a book that's supposed to be useful to C programmers.

-s

 

[robin]

| In article <[email protected]>,
| >
| >I found there was a lot of work translating the algorithms into PL/I
| >too, for the same reason. You can't just translate the code
| >one-for-one, but have to translate the intent instead.
|
| If that were all :-( As pointed out several times, you often have
| to fix the code as well.

Your comments and information are out-of-date.

| >That being said, I've found the first edition quite useful.
|
| Which included the worst random number generators that I had seen
| in 25 years of refereeing on that topic - MUCH worse than RANDU.
| They started to give wrong answers in trivial, realistic tests
| with only 200 numbers.

Again, you are referring to the 1988 (first) edition.
That's 23 years ago. Not particularly relevant.

The current (third) edition provides a range of RNGs
(but, of course, not the latest of George Marsaglia's of 2010).

 

[James Dow Allen]

... fix up those problems, in the end you learn more about
how it works.  It did that at least once, and it took a while
to get right.  (Especially all the loops indexing arrays
from zero instead of one.)

I also went through the NR routines I needed and rewrote them
to index from zero; am glad to discover now I wasn't the only
one so perverse. But, no ... I didn't learn how Jacobi's
pivots work while I was at it, just being in "copy faithfully"
mode.

Doing this rewrite, I felt somewhat anal-retentive, since the
N.R. routines could be treated as a black box, and the funny
indexing disguised via macros. It was my obsessive-compulsive
behavior, I think, that made me "fix" the indexing ...
but at least I don't wash my hands 10 hours per day like
some OCD sufferers.

James Dow Allen

 

[Richard Maine]

...once you put them [NR codes] in a shared library, it
becomes a useful prototyping tool and doesn't contaminate your code with
copylefts and suchlike.

Have you read the license conditions on the NR code? Regardless of what
one might think about copylefts, the copyright on the NR code is more
restrictive than any copyleft. Copylefts place conditions on
redistributing the code or programs built from it. The NR copyright
places an even stronger condition - namely that you cannot do it at all.

Quoting exactly from my copy of NR in Fortran 90

"Immediate License....You are not allowed to transfer or distribute
machine-readable copies to any other person, or to use the routines
on more than one machine, or to distribute executable programs
containing our routines. This is the only free license."

As the last sentence quoted above implies, there are other license
options, but you have to pay for all of them (paying for the book
doesn't count).

 

[Uno]

"rosario"<[email protected]> ha scritto nel messaggio

"robin"<[email protected]> ha scritto nel messaggio

| I think the
| Numerical Recipes books are excellent introductions to many
| computational problems, including linear algebra. I do agree that
| the code itself that is given in the book is sometimes not the most
| robust, but on the other hand, something like LAPACK code is robust
| but too complicated for a beginner to understand easily.

Numerical Recipes is an authoritative source of information
about a vast number of numerical procedures.

better write code in one macro asm that allow multi instruction for line
and indentation

all compiler science == 0 for me, and it go to the wrong way
[the way the human lost what the machine do]

excuse me possibily, i'm one extremis don't believe all the people say
i believe what i see

and i see something like this:

; a inizializzaRNDFile(u32* RNDvar, u8* fname)
; Questa funzione inizializza i vettori delle basi e dei seed per la variabile
random RNDvar
; prendendo i dati per l'inizializzazione da un file esterno.
; RNDvar: variabile random ritornata da rtnRNDmem() o inizializzata da
iniRNDmem
[in/out]
; fname: stringa che contiene il nome del file i cui dati servono a
inizializzare RNDvar [in]
; ritorna: [0 ed CF==1 per errore; 1 ed CF==0 tutto ok]
; uso tipico:
; rtnRNDmem(6, 31415821, 1234) |jc .e|j=a
; inizializzaRNDFile(j, "filedati")|jc .e
; 0j,4i,8Ra, 12P_RNDvar, 16P_fname + 5120
; 5132 5136
align 4
inizializzaRNDFile:
<i,j
s-=5120
<< RNDvar=5132, fname=5136, KeyHandle=16
i=^fname|j=^RNDvar
i==0#.e |j==0 #.e|D*j==0#.e ; la basea non puo' essere zero
D*j+ini== -1 #.e ; l'array di basi non puo' essere inizializzato
D*j+nbs>100000#.e ; il numero delle basi non puo' essere> 100000
#.1
.e1: a=^KeyHandle|CloseHandle(a)
.e: a^=a|stc|#.z ; errore: ritorna 0
.1: CreateFileA(i,&GENERIC_READ, 0, 0,&OPEN_EXISTING,
&FILE_ATTRIBUTE_NORMAL,0)
a==&INVALID_HANDLE_VALUE#.e|^KeyHandle=a
r=&*s+24|c=s|ReadFile(a, r, 4064, c, 0)
a==0#.e1|a=D*s|a<4?#.e1 ; se ha elementi in numero<4 esci errore
a=^KeyHandle|CloseHandle(a)|a==0#.e
; prepara la variabile random definendo l'array di
basi e seed
; con i dati provenienti dal file
r=&*s+24|a=^0|PreparaRND(j, r, a)|jc .e
a=1|clc
.z:

RNDvar, fname, KeyHandle s=&*s+5120
i,j

ret 8

so i'm just one troll?

I would say more like a scribbler. That's alright, if you're five.

 

[Uno]

...once you put them [NR codes] in a shared library, it
becomes a useful prototyping tool and doesn't contaminate your code with
copylefts and suchlike.

Have you read the license conditions on the NR code? Regardless of what
one might think about copylefts, the copyright on the NR code is more
restrictive than any copyleft. Copylefts place conditions on
redistributing the code or programs built from it. The NR copyright
places an even stronger condition - namely that you cannot do it at all.

Quoting exactly from my copy of NR in Fortran 90

"Immediate License....You are not allowed to transfer or distribute
machine-readable copies to any other person, or to use the routines
on more than one machine, or to distribute executable programs
containing our routines. This is the only free license."

As the last sentence quoted above implies, there are other license
options, but you have to pay for all of them (paying for the book
doesn't count).

My problem with the treatment was the large, proprietary module that
needed to be included in order to make the smallest of examples work.

I'm not saying that would be a problem for others, presumably people
with deeper pockets than me, which is a lot of people.

They sure are amazing, quick, and robust, tho.

 

[Uno]

Not in a book that's supposed to be useful to C programmers.

By what process do you get that? Programs without pointers aren't useful?

Usually, when the rest of us talk about "avoiding pointers," we mean the
unnecessary ones that obfuscate.

Of course, I'll never stand between Seebs and his calling to make C a
useless abstraction.

 

[nmm1]

By what process do you get that? Programs without pointers aren't useful?

In C, that is true. All of strings, arrays and (when used as objects)
functions are actually pointers, and it is important to know and use
that when passing them as function arguments.

It is not true in Fortran.


Regards,
Nick Maclaren.

 

[aruzinsky]

Proper implementation of C pointers increases program speed but the
source code is relatively unreadable. C and, more so, C++ can be
written to be either very readable or very unreadable. I much rather
read C source code written to resemble pseudo-code. Afterwards, it is
easy enough for me to implement pointers (which later I have
difficulty reading).

 

[Seebs]

Proper implementation of C pointers increases program speed but the
source code is relatively unreadable.

No, it isn't.

I much rather
read C source code written to resemble pseudo-code. Afterwards, it is
easy enough for me to implement pointers (which later I have
difficulty reading).

There are tons of algorithms which are elegant and clear using pointers,
and hard to write clearly at all without them. Perhaps you should just
practice more until pointers are more comfortable for you.

-s

 

[Beliavsky]

...once you put them [NR codes] in a shared library, it
becomes a useful prototyping tool and doesn't contaminate your code with
copylefts and suchlike.

Have you read the license conditions on the NR code? Regardless of what
one might think about copylefts, the copyright on the NR code is more
restrictive than any copyleft. Copylefts place conditions on
redistributing the code or programs built from it. The NR copyright
places an even stronger condition - namely that you cannot do it at all..

Quoting exactly from my copy of NR in Fortran 90

   "Immediate License....You are not allowed to transfer or distribute
    machine-readable copies to any other person, or to use the routines
    on more than one machine, or to distribute executable programs
    containing our routines. This is the only free license."

As the last sentence quoted above implies, there are other license
options, but you have to pay for all of them (paying for the book
doesn't count).

My problem with the treatment was the large, proprietary module that
needed to be included in order to make the smallest of examples work.

I think that part of the Numerical Recipes is in the public domain .
See http://www.nr.com/public-domain.html .

 

[Keith Thompson]

In C, that is true. All of strings, arrays and (when used as objects)
functions are actually pointers, and it is important to know and use
that when passing them as function arguments.

It is not true in Fortran.

It's not true in C either.

Strings are not pointers. Arrays are not pointers. Functions are not
pointers.

All three are typically managed using pointers, and a declaration that
looks like a parameter of array or function type is really a pointer
parameter.