Authors reply: We agree that the use of Python as a "front end" is very desirable. The ideal as discussed by Paul DuBois in CiP and CiSE is to write the main part of the program in fortran or C and call them from Python.
author's reply: If a neutron is captured, all the energy goes into the medium and in this sense the process is inelastic. We are making a distinction between non-capturing collisions. Also, if you look at the neutrons that make it through the material, then we are consistent with the usual scattering terminology. That is, all of the neutrons that could be detected by a detector have the same energy as the incident neutrons in Problem 11.9, but in Problem 11.10 they would typically have lost energy. The same is also true for the reflected neutrons.
Honestly, the only doubt I still have about the book is precisely the language. I do computational neuroscience, and my language of choice is C (I also use Mathematica and Matlab a lot). I have to confess that I have never used BASIC. I am sure I, as well as my students, can learn BASIC, but my doubts are not about it being easy or difficult. My doubts group into two classes (1) Is BASIC good for the professional future of my students? Many of our majors do not go on to graduate school. So, my understanding is that C would be better for them. Can you correct me in this one? I am not talking about good programing habits. I am talking about a line in their resume. (2) Practical concerns: If I use C, will I be able to translate all the programs on my own? Are freeware compilers (such as yabasic) able to run your TrueBasic programs? (I use Linux, so I lean towards free stuff.) I do want to use your book, as I feel it is the best around. I would then appreciate any suggestion you may have about languages.
Jan Tobochnik's response: We have thought long and hard about the questions you pose concerning the use of languages in a computer simulation course. As we state in our appendices, the main reason we have stuck with True Basic is its platform independence and simple graphics. In a course you should be able to use any language since translating our True Basic programs into any procedural language is simple as long as you provide some kind of simple graphics library that mimics the True Basic graphics routines. In fact that is what I am planning to do this winter. (Information about Vogl on the Macintosh.) I will be using Codewarrior C++ on the Macintosh for most of the course. If there are some students who have never done any programming, I might start with a little True Basic just to have a slightly simpler introduction.
One reason I am using C is that it is a more marketable skill, although many companies still use Visual Basic to write internal applications. However, the bottom line is that once a student learns one language well, they can pick up others very quickly.
In our book and on our web page we do some translations into C and FORTRAN already. Hopefully, we will have more by the end of this academic year.
authors reply: The text by A. Garcia uses Matlab. We find that True Basic is a more natural introduction to Fortran and hence a better choice for doing simulations. However, there is no perfect do all language.
y now
denoting the difference between the true y-value and y0,
(2.3) is correct, but the the y1 in the figure is
incorrectly located.
authors reply: We appreciate your question about the notation on page
13. What we mean is that y1 is the value of y at
x1. Thus, the equal sign in (2.3) indicates what would
happen if we knew
y exactly, and the approximate sign indicates
that with the Euler algorithm we approximate
y by f
x.
Thus, y1 stands for the exact value until the
approximation is made. In the figure we have made the approximation
and thus y1 stands for the approximate value.
What do you think?
9/11/95. Richard J. Gaylord comments: Mathematica and Maple are both computer algebra systems that contain
underlying progamming languages. The languages are quite different from one
another.
Maple is not a functional programming language; it has only a few of the
basic functional programming constructs that characterize a functional
language and its pattern-matching capabilities are very limited. Overall,
Maple is basically a procedural language.
Mathematica, on the other hand, is in essence, a functional programming
language that is implemented as a term rewriting system with very extensive
pattern-matching capabilities (one can program in Mathematica using the
procedural style of programming (eg., using Do loops) but it is defintely
preferable to adopt the functional or rule-based style).
Note: To see the differences between the use of these two languages, one
can look at programs written in the these languages by the developers of
these computer algebra systems.
9/11/95. Richard J. Gaylord comments: It is true that functional programs generally run more slowly than
procedural programs. However, runtime is not the whole story in terms of
efficiency. The time it takes to develop code, and even more importantly,
to modify programs, is substantially faster for functional programs than for
procedural programs. This is important for protyping and carrying out
exploratory research.
An additional factor that needs to be taken into account when evaluating
the efficiency of a language for computer simulation work is related to
what computing tasks are going to be carried out. Most simulation studies
include not only creating and running a program but also analyzing the
results both visually and numerically (as well as writing up the study both
for publication and presentation). There is a major benefit to using a
computer algebra system such as Mathematica, Maple, Macsyma, or Axiom which
provides a unified computing environment for carrying out all of these
tasks.
Editors note: related books by Richard J. Gaylord: R. Gaylord, S.
Kamin, and P. Wellin, Introduction to Programming with
Mathematica, second edition, Springer-Verlag (1995) and R. J.
Gaylord and P. R. Wellin, Computer Simulations with
Mathematica, Springer-Verlag (1995).
reply: We haven't, but we are considering it for the future. Would a version of our text in C/C++ or Fortran 77/90 be of interest?
Please send us your ideas and opinions. Send a message to Harvey Gould, hgould@clarku.edu, or Jan Tobochnik, jant@kzoo.edu.
Updated 7 January 1997.