# NUMERICAL RECIPES

Discussion in 'C Programming' started by robin, Jan 2, 2011.

1. ### robinGuest

"Ron Shepard" <> wrote in message
news:...

| 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
* 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

robin, Jan 2, 2011

2. ### bertGuest

On Jan 2, 9:03 am, "robin" <> wrote:
> 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.
--

bert, Jan 2, 2011

3. ### robinGuest

"bert" <> wrote in message
news:...
On Jan 2, 9:03 am, "robin" <> wrote:

> 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++, ..."

robin, Jan 2, 2011
4. ### Malcolm McLeanGuest

On Jan 2, 3:29 pm, bert <> wrote:
>
> 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.

Malcolm McLean, Jan 2, 2011
5. ### aruzinskyGuest

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.

On Jan 2, 8:23 am, Giorgio Pastore <> wrote:
> On 1/2/11 2:29 PM, bert wrote:
>
> > On Jan 2, 9:03 am, "robin"<>  wrote:
> >> Numerical Recipes is an authoritative source of information
> >> about a vast number of numerical procedures.

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

>
> Actually, I think that Numerical Recipes is a book which progressively
> becomes worse at each new edition.
>
>  From the side of algorithms, the first edition  was doing a pretty good
> job concentrating on a few of them. That way, it was a not-deep but
> modern, honest and readable book on numerical algorithms. A good
> starting point for further readings. The examples in Fortran 77 were not
> enough modular to be included in other codes without some rewriting,
> but, as examples of implementation were reasonably well written.
>
> The last edition has become a huge book which tries to cover almost
> everything. It is true that the original intent was to provide a sort of
> cookbook. But the first edition was a good starting point for everybody
>   wanted to get a feeling  how to become a chef able to prepare a full
> meal. The last one covers too much for a general overview and not so in
> depth to provide a definite guide for each specific topic.
>
> Finally, the authors explicit admission of missing their bets on the
> language evolution is mirrored by codes which progressively tend to use
> less expressively  the underlying languages.
>
> I hope that this trend could be reversed in the future.
>
> Giorgio

aruzinsky, Jan 2, 2011
6. ### Guest

In article <ifqj7c\$ne2\$-september.org>,
Peter Flass <> wrote:
>
>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.

, Jan 2, 2011
7. ### Peter FlassGuest

On 1/2/2011 8:29 AM, bert wrote:
> On Jan 2, 9:03 am, "robin"<> wrote:
>> 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.
> --

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.

Peter Flass, Jan 2, 2011
8. ### glen herrmannsfeldtGuest

In comp.lang.fortran bert <> wrote:
> On Jan 2, 9:03 am, "robin" <> wrote:
>> 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.

(snip)

This one I agree with, though if you go through the routine
how it works. It did that at least once, and it took a while
to get right. (Especially all the loops indexing arrays

-- glen

glen herrmannsfeldt, Jan 2, 2011
9. ### SeebsGuest

On 2011-01-02, robin <> wrote:
> "bert" <> wrote in message
> news:...
>> 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.

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

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach /
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs, Jan 3, 2011
10. ### robinGuest

<> wrote in message news:ifqhas\$10h\$...
| In article <ifqj7c\$ne2\$-september.org>,
| Peter Flass <> wrote:
| >
| >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.

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).

robin, Jan 3, 2011
11. ### James Dow AllenGuest

On Jan 3, 3:39 am, glen herrmannsfeldt <> wrote:
> 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

James Dow Allen, Jan 3, 2011
12. ### Richard MaineGuest

Phil Hobbs <> wrote:

> ...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).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Richard Maine, Jan 5, 2011
13. ### UnoGuest

On 1/7/2011 5:09 AM, rosario wrote:
> "rosario"<> ha scritto nel messaggio
> news:4d25757b\$0\$10583\$...
>>
>> "rosario"<> ha scritto nel messaggio
>> news:4d2571d4\$0\$10573\$...
>>>
>>> "rosario"<> ha scritto nel messaggio
>>> news:4d249126\$0\$10574\$...
>>>>
>>>> "robin"<> ha scritto nel messaggio
>>>> news:4d2055cd\$0\$99356\$...
>>>>> "Ron Shepard"<> wrote in message
>>>>> news:...
>>>>>
>>>>> | 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
>> &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

Uno, Jan 9, 2011
14. ### UnoGuest

On 1/5/2011 2:11 PM, Richard Maine wrote:
> Phil Hobbs<> wrote:
>
>> ...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

Uno, Jan 9, 2011
15. ### UnoGuest

On 1/2/2011 7:34 PM, Seebs wrote:
> On 2011-01-02, robin<> wrote:
>> "bert"<> wrote in message
>> news:...
>>> 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.

>
> 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.
--
Uno

Uno, Jan 9, 2011
16. ### Guest

In article <>, Uno <> wrote:
>On 1/2/2011 7:34 PM, Seebs wrote:
>> On 2011-01-02, robin<> wrote:
>>
>>> Pointers are probably best avoided.

>>
>> 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?

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.

, Jan 9, 2011
17. ### aruzinskyGuest

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

On Jan 8, 9:42 pm, Uno <> wrote:
> On 1/2/2011 7:34 PM, Seebs wrote:
>
> > On 2011-01-02, robin<>  wrote:
> >> "bert"<>  wrote in message
> >>news:....
> >>> 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.

>
> > 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.
> --
> Uno

aruzinsky, Jan 9, 2011
18. ### SeebsGuest

On 2011-01-09, aruzinsky <> wrote:
> 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

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
--
Copyright 2010, all wrongs reversed. Peter Seebach /
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs, Jan 9, 2011
19. ### BeliavskyGuest

On Jan 8, 10:33 pm, Uno <> wrote:
> On 1/5/2011 2:11 PM, Richard Maine wrote:
>
>
>
>
>
>
>
>
>
> > Phil Hobbs<>  wrote:

>
> >> ...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 .

Beliavsky, Jan 9, 2011
20. ### Keith ThompsonGuest

writes:
> In article <>, Uno <> wrote:
>>On 1/2/2011 7:34 PM, Seebs wrote:
>>> On 2011-01-02, robin<> wrote:
>>>
>>>> Pointers are probably best avoided.
>>>
>>> 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?

>
> 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.

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson, Jan 9, 2011