Hi Vivek,
>>>>> "Vivek" == Vivek Rao <[EMAIL PROTECTED]>
>>>>> on Wed, 11 Apr 2007 06:20:21 -0700 (PDT) writes:
Vivek> I have some comments on the Fortran code in the
Vivek> fseries package in file 4A-GarchModelling.f ,
this is "fSeries" {and case does matter in R - contrary to Fortran :-)}
a CRAN-contributed package which has a well-defined maintainer
whom you can quickly find using
packageDescription("fSeries")
Further, he might not read R-devel on a regular basis at all ..
Vivek> especially the subroutine GARCHFIT and function
Vivek> DSNORM.
Vivek> I appended the code to the end of an earlier message,
Vivek> but it was rejected by some rule.
you (i.e. your mailer) must have used an unspecified binary
mime-type; do use "text/plain" instead and the attachments
won't be filtered.
Vivek> Let me first say that I am grateful that packages for
Vivek> financial econometrics exist in R.
Vivek> Fortran 77 had PARAMETERs, and PARAMETERs equal to
Vivek> 99999 and 200 should have been defined instead of
Vivek> repeatedly using "magic numbers". More importantly,
Vivek> the code will fail if NN exceeds 99999, but the code
Vivek> does not check for this. I hope someone will fix this.
Vivek> In the code dsged the variables half, one, two should
Vivek> be made parameters, and instead of
Vivek> IMPLICIT DOUBLE PRECISION (A-H, O-Z)
Vivek> IMPLICIT NONE
Vivek> should be used and all variables declared. Although
Vivek> IMPLICIT NONE is not standard Fortran 77, it is
Vivek> standard Fortran 90 and is supported by g77.
Vivek> Experienced Fortranners know that IMPLICIT NONE
Vivek> catches errors. Another defect is the use of specific
Vivek> intrinsic functions such as DSQRT. There is no need to
Vivek> use this, since the SQRT function is generic, handling
Vivek> both single and double precision arguments.
Vivek> Maybe there should R coding standards to address such
Vivek> issues. I hope that eventually the Fortran code in R
Vivek> will use the modern features of Fortran 90 and later
Vivek> standards, using the gfortran compiler. However, with
Vivek> a little effort one can still write clean code in
Vivek> Fortran 77 that also conforms to later standards.
I mostly agree with all you say above.
But we (R-core) have never wanted to play style-police for the
1000++ CRAN / bioconductor / omegahat R packages that other
people provide.
As core team we only feel responsible for the code that we
distribute with the R distribution, and even there, the so-called
recommended ("non-core") packages typically have their own
individual maintainer.
I'd say, R-core would typically follow your recommendations
above, apart from the fact that most of us would not use
Fortran for developing new code.
And for legacy code that is well tested with many years of
history, we'd rarely want to spend the time just for beautifying
code (though I occasionally have done so, when wanting to find
out what the code was doing at all).
Martin Maechler, ETH Zurich
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
