vsnyder@jato.jpl.nasa.gov (Van Snyder) (02/23/91)
In article <1991Feb13.1113.5265@canrem.uucp> "tellabs canada" <tellabs.canada@canrem.uucp> writes: >-> - spline algorithms > >Look for Numerical Recipes in C (mathematicians programming bible), >you'll find algorithms for this and a thousand and one other things >there Numerical Recipes (NR) is definitely NOT the "mathematicians programming bible". If you look in the Numerical Analysis literature you'll find pretty bad reviews of NR, for examply by Larry Shampine, a leading researcher in numerical methods for solving the initial value problem for ordinary differential equations, and an expert in many other fields of numerical analysis, and by Dick Hanson, a leading researcher in numerical linear algebra and non-linear least squares, and also an expert in many other fields of numerical analysis. Shampine has worked at Sandia Laboratories, and is now at SMU (I think). Hanson has worked here at JPL, at University of Washington (Pullman), at Sandia National Laboratories, at Applied Dynamics (Ann Arbor), and is now at International Mathematical and Statistical Libraries, Inc (IMSL) in Houston. Shampine and Hanson found fault, respectively, with subprograms for ordinary differential equations, and least squares problems. In our own investigations we found the NR MEDFIT algorithm, for what the authors called "robust estimation" to be quite bad -- sometimes went into a loop. The routines they provide for special functions, e.g. Cylindrical Bessel Functions of the first kind and order zero, commonly called J0, were the polynomial approximations developed by Cecil Hastings in 1956, and published in the National Bureau of Standards Handbook of Special Functions, Applied Math Series 55 (AMS 55). The latter truly IS the mathematicians bible, but not for programming -- the numerical methods are out of date. It has been republished by Dover, and is sometimes available for $15-20. There's nothing really WRONG with Hastings' approximations, except that they only give you about 5-6 digits, and are not as efficient as more modern methods. If you want good math software, contact the archive mail server (Bart-like) netlib@research.att.com. Send it mail consisting of "send index from netlib" Something in the index will be a document about netlib. Failing that, get a GOOD numerical analysis text. The one by Kendall Atkinson is excellent. So is the one by Kahaner, Moler and Nash, and it has the added bonus of a diskette full of Fortran code. For a broad range of approximations for elementary and special functions, get "Computer Approximations" by Hart et al. For linear least squares problems, get "Solving Least Squares Problems" by Lawson and Hanson. For splines, look for work by Carl deBoor. I don't remember the title of his book, but his code is available from Netlib. The authors of NR may well be "leading scientists" in their respective fields, as the dust jacket claims. But there are no claims they're leading researchers or developers of mathematical software, and the quality of the codes in their book demonstrates that. The advice of the numerical analysis community is to throw away that book before you're tempted to use an algorithm from it. Failing that, double and triple check any algorithm from it before trusting it with anything more important than calculating your gas mileage. Van Snyder. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
boyd@mailer.cc.fsu.edu (Mickey Boyd) (02/24/91)
In article <1991Feb22.210921.28469@jato.jpl.nasa.gov>, vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) writes: >In article <1991Feb13.1113.5265@canrem.uucp> "tellabs canada" <tellabs.canada@canrem.uucp> writes: >>-> - spline algorithms >> >>Look for Numerical Recipes in C (mathematicians programming bible), >>you'll find algorithms for this and a thousand and one other things >>there > >Numerical Recipes (NR) is definitely NOT the "mathematicians programming bible". >[....lots of good sounding reasons to not get this book/disk....] Just out of curiosity, is the newer NR in C any better than the original one (where everything was FORTRAN)? NR is available on the ST with a source code disk (in C). Have they improved their algorithms any in the translation to C? -- Mickey R. Boyd | "God is a comedian playing to an FSU Computer Science | audience too afraid to laugh." Technical Support Group | email: boyd@fsucs.cs.fsu.edu | - Voltaire
vsnyder@jato.jpl.nasa.gov (Van Snyder) (02/27/91)
In article <1991Feb23.174459.4432@mailer.cc.fsu.edu> boyd@nu.cs.fsu.edu (Mickey Boyd) writes: >In article <1991Feb22.210921.28469@jato.jpl.nasa.gov>, vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) writes: >>In article <1991Feb13.1113.5265@canrem.uucp> "tellabs canada" <tellabs.canada@canrem.uucp> writes: >>>-> - spline algorithms >>> >>>Look for Numerical Recipes in C (mathematicians programming bible), >>>you'll find algorithms for this and a thousand and one other things >>>there >> >>Numerical Recipes (NR) is definitely NOT the "mathematicians programming bible". >>[....lots of good sounding reasons to not get this book/disk....] > >Just out of curiosity, is the newer NR in C any better than the original one >(where everything was FORTRAN)? NR is available on the ST with a source code >disk (in C). Have they improved their algorithms any in the translation to >C? As far as we can tell, the C algorithms are just a straight translation of the Fortran algorithms. No improvements. Aside: C compilers that aren't ANSI-C will have some problems (i.e. require you to do some gymnastics) with numerical analysis that won't happen in Fortran. Even ANSI C has trouble with matrices, since arrays don't really exist in C (they're bogus pointers). Tha main problem in porting linear algebra codes from Fortran to C is in the transposition from column major storage order to row major storage order. Van. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
kirste@methan.chemie.fu-berlin.de (Burkhard Kirste) (02/27/91)
vsnyder@jato.jpl.nasa.gov (Van Snyder) writes: >In article <1991Feb23.174459.4432@mailer.cc.fsu.edu> boyd@nu.cs.fsu.edu (Mickey Boyd) writes: >>In article <1991Feb22.210921.28469@jato.jpl.nasa.gov>, vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) writes: >>>In article <1991Feb13.1113.5265@canrem.uucp> "tellabs canada" <tellabs.canada@canrem.uucp> writes: >>>>-> - spline algorithms >>>> >>>>Look for Numerical Recipes in C (mathematicians programming bible), [stuff deleted] > >As far as we can tell, the C algorithms are just a straight translation of the >Fortran algorithms. No improvements. Aside: C compilers that aren't ANSI-C Yes, for the most part it looks like an automatic translation; in most instance, e.g., they kept the array numbering starting with 1, not 0. A few routines have experienced major rewriting. >will have some problems (i.e. require you to do some gymnastics) with numerical >analysis that won't happen in Fortran. Even ANSI C has trouble with matrices, >since arrays don't really exist in C (they're bogus pointers). Tha main problem >in porting linear algebra codes from Fortran to C is in the transposition from >column major storage order to row major storage order. I don't see serious problems in the internals of storage (column or row major), as long as one would not like to exchange the binary output. Arrays DO exist in C, of course; the only problem might be with range checking. Regarding two-dimensional arrays, one might use either true arrays twodim[][fixed] (only the first bound may left open) or the pointer to pointer method, **twodim. NR uses the second method and provides routines matrix and free_matrix for storage allocation and deallocation (as well as vector and free_vector for 1D arrays with arbitrary bounds, to keep compatibility with Fortran ...). -- |~| Freie Universitaet Berlin, Institut fuer Organische Chemie / \ Burkhard Kirste kirste@kristall.chemie.fu-berlin.dbp.de /FUB\ Takustrasse 3, D-1000 Berlin 33 UUCP: kirste@fub.uucp `---' Telefon: (030)838-6484 Telefax: (030)838-5163