f2c - FORTRAN to C

Alison has sucked me into a discussion which I would have preferred to avoid. She sent out the following quote from me, intended for a particular individual in a particular context, and not intended for general discussion. And you all, understandbly, started to discuss this. She sent all of your discussion to me so that I might see it > There's no way one can verify whether FORTRAN->C code works correctly. > On first principles, I strongly recommend against this practice. > I'm not sure whether this is a violation of the license agreement, > but I am going to check, and if not, I am going to consider > modifying the license. I have checked our license agreement. Developing C-code per se is not a violation. I have considered modifying the license. I do not think it should be modified. Nick Holford observed that when I said that there was no way to know whether the C code works correctly, I may have meant "in general". He is correct. With a *particular* NONMEM problem, one can confirm that both FORTRAN and C codes are giving essentially the same results. He also observed that different FORTRAN compilers can give different NONMEM results, and therefore posed the question whether one can tell whether even the FORTRAN compiled NONMEM code is correct. This observation too is, of course, correct. However, unless one FORTRAN compiler has a real bug, while another doesn't, the difference between their results will be negligible (for reasons partly explained below). I am concerned that the same may not be true for NONMEM C-Code. Incidentally, the NONMEM Project Group does a certain amount of testing of NONMEM using different FORTRAN compilers. This helps check the robustness and reliability of our code. Natural compiler differences, will lead to small differences in results on the same machine (and natural differences in machines will also lead to small differences.) By a small difference in results, I mean a small difference in the minimum objective function and final parameter estimates. (Nick has on previous occasion, and privately to just a few of us, noticed differences in results from the Covariance Step and questioned whether these were small. I replied that they in fact were, although at first blush, they appeared not to be. Results from the Covariance Step can be more sensitive to small compiler or machine differences.) However, when small differences occur, the search path taken to the final estimate can appear quite different. This path is very sensitive to small compiler and machine differences. Differences in search paths appear, for the purposes of this discussion, to be essentially random. Different search paths to the same final estimate can involve very different numbers of function evaluations. If one wants to benchmark NONMEM between different systems, one should compare the CPU time per function evaluation. It isn't fair to rate a system as slower because it takes more function evaluations to get to the same final estimate. Due to the randomness, with the next problem one tries, it is quite likely that the benchmark comparison would be reversed. I doubt that C-code will run faster, using CPU time per function eval. as our measure, than will FORTRAN code. I haven't tried C-code, and I really don't know; I could be wrong. However, we try to write code efficiently *for FORTRAN*, and I can't quite imagine what there is about C-code *per se* that could improve on the FORTRAN code. (If with the C-compiler there is some greater degree of optimization or such than is available with the FORTRAN compiler, improvement could occur. But then, maybe a better FORTRAN compiler should be obtained). We can do this because we understand some detailed things about what FORTRAN compilers do. Indeed, we take advantage of subtle FORTRAN "rules". I am somewhat uncertain about the extent to which the FORTRAN->C program can be faithful to *all* FORTRAN rules, or at least to the way they are usually implemented by FORTRAN. Perhaps some are very faithful. But one takes a risk here, more of a risk than one takes with choosing some particular FORTRAN compiler. One reason we use FORTRAN is because there is a well-developed STANDARD to which all FORTRAN compilers (from which we assume you will make your choice) must (try to) comply. Not so, regarding FORTRAN->C conversion programs. I can easily imagine that nonadherence to all FORTRAN rules could cause problems, not only with NONMEM efficiency, but with NONMEM accuracy and reliability as well. The problem might not become apparent with the first NONMEM problem you try to run, and maybe it will never become apparent while it nevertheless leads to adverse effects. Because we use different FORTRAN compilers, and because of the FORTRAN standard, we can give you some confidence that NONMEM FORTRAN compiled code works well. We are not in a position to give you this same confidence with NONMEM C compiled code. So my recommendation is really a caution. I don't think the benefit (if indeed there is one) will be worth the risk. But you are free to take this risk. I can hear someone ask: If FORTRAN search paths are rather variable, mightn't this swamp FORTRAN-related efficiencies you have tried to use in your code? The hope is that the "signal" amongst the noise will be detectable. That is, the hope is that over many NONMEM runs, the net gain resulting from these efficiencies will be significant.