[bluenose69]

It's been a very long time since I've used NR, but it was pretty terrible code that was a poor competitor for NAG and IMSL.

The discussion of algorithms, being informal and well-illustrated, was the high point of the books. The code, not so much.

I had the Fortran book and so, when the C book came out, I bought that as well. The C code seemed to have been auto-generated by the Fortran code, and it was really quite terrible.

Functions in the fortran code had arguments for what I'd call "work arrays". There was some risk in that, because if the documentation told you to give space for 2N+1 floating point values and you gave 2N, you might get into problems. I don't think that was a real problem in practice, because people were accustomed to this general way of working and so they were careful.

The C code took a different approach. The functions allocated and deallocated space as needed. And, since lots of functions called other functions for very simple things, there was a massive amount of memory juggling going on. This made the functions be wildly slow. So, the point of the boycott was not terribly relevant, because I think pretty much everyone trying to use that C code just rewrote it, anyway.

[jeffwass]

This 100%.

20+ years ago I took my NR class as part of my physics PhD program, it was a required course for all physics and astronomy students.

I don't think anybody in the class was planning to use the actual recipes from the book as a drop-in placement for their work, but it was to explain the methods behind the software we all used (Matlab in my group, IDL and IRAF for the astronomers, etc), so users can make the best choice for which curve fitting or regression or optimisation routines to call, and avoid potential pitfalls.

To me it seems like an OS class that uses minix to explain behind-the-scenes operation system functionality. Hardly anyone in the class will go on to use Minix as their primary OS in their future career. (I've not done any formal CS study, so forgive the analogy).

[Animats]

I had the Fortran book and so, when the C book came out, I bought that as well. The C code seemed to have been auto-generated by the Fortran code, and it was really quite terrible.

Oh, yes. The arrays in the C code were indexed from 1, following the FORTRAN code, with functions to convert the subscripts. Pointers to arrays were offset by one element size, so they didn't point to the array at all. They pointed to an address outside of the array.

I rewrote parts of NR in C++, but ancient, 1990s C++, with pre-STL Microsoft collection classes.

[fargle]

> the code, not so much

Exactly. And what's nice about that approach is that it sidesteps that ludicrous license.

As many people point out, you shouldn't roll-your-own numeric code. Unless you are solely responsible for knowing it's what you want and are cognizant of all the tricky edge cases and can make informed engineering decisions of course.

As the article says "Numerical Recipes is a good book for learning about numerical methods." I agree. If I need a quick algorithm in my language of choice, I might refer to NR in Fortran or C as a guide, but the actual implementation must be cleaned up and integrated correctly. Probably extended and specialized and combined with whatever tricks are required for the purpose. The books are (were) useful as books, but the code was never more than executable pseudo-code. I find it helpful to understand the algorithm, and once I do, I immediately begin seeing where I need to adjust it too.

And you can't copyright algorithms. So as long as I don't make a NR.py lib (which no-one needs) that contains the entire Structure, sequence and organization (SSO) of the book, the publishers can stick their crappy license where they like. I don't have to boycott the book.