Pierre-
the point that at least I was trying to make (and I believe also Van Snyder who
offered the most in this direction of the discussion, i.e. NR is NOT the book
of choice for NumAnal) is that:
"Things should be made as simple as possible but no simpler than that"
A. Einstein
Hence, my claim (and I believe Van Snyder's too) is that NR is going several
steps further on the simplicity road and that is generating risks for the
"uninitiated".
Yes, there should have been more well written good book on NumAnal out there
but unfortunately there are very few that cover in breadth as much as NR. But
this does not justify relying on NR to be an authority. I have personally found
the following algorithm to work the best:
a. understand the nature of the problem you're trying to solve
b. go into NAG and find the relevant routines
c. read NAG's docs and then if needed the references cited.
d. implement your code that calls NAG routine(s)
Ok, if you do not have NAG, you can do similarly with NETLIB and GAMS. This
is a much better route and one will get this way far more help say in
sci.math.num-analysis than by following NR.
Your arguments are well supported. However, to play the "devil's advocate"
I could argue that your engineer (and I am one) will investigate further the
"wrong algorithm" if the results are completely trash. If this is not the case
he will trust the results, hence he has a problem.
Kind regards,
Petros
----------------------
Petros Dafniotis, PhD
DuPont de Nemours Intl. S.A. - DuPont Lycra(R)
[log in to unmask]
---
DISCLAIMER: My employer, DuPont de Nemours, has nothing to do with
the opinions and ideas expressed in this post / message.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
