I have some comments on the Fortran code in the
fseries package in file 4A-GarchModelling.f ,
especially the subroutine GARCHFIT and function
DSNORM.
I appended the code to the end of an earlier message,
but it was rejected by some rule. Let me first say
that I am grateful that packages for financial
econometrics exist in R.
Fortran 77 had PARAMETERs, and PARAMETERs equal to
99999 and 200 should have been defined instead of
repeatedly using "magic numbers". More importantly,
the code will fail if NN exceeds 99999, but the code
does not check for this. I hope someone will fix this.
In the code dsged the variables half, one, two should
be made parameters, and instead of
IMPLICIT DOUBLE PRECISION (A-H, O-Z)
IMPLICIT NONE
should be used and all variables declared. Although
IMPLICIT NONE is not standard Fortran 77, it is
standard Fortran 90 and is supported by g77.
Experienced Fortranners know that IMPLICIT NONE
catches errors. Another defect is the use of specific
intrinsic functions such as DSQRT. There is no need to
use this, since the SQRT function is generic, handling
both single and double precision arguments.
Maybe there should R coding standards to address such
issues. I hope that eventually the Fortran code in R
will use the modern features of Fortran 90 and later
standards, using the gfortran compiler. However, with
a little effort one can still write clean code in
Fortran 77 that also conforms to later standards.
Vivek Rao
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
I have some comments on the Fortran code in the
fseries package in file 4A-GarchModelling.f ,
especially the subroutine GARCHFIT and function
DSNORM.
I appended the code to the end of an earlier message,
but it was rejected by some rule. Let me first say
that I am grateful that packages for financial
econometrics exist in R.
Fortran 77 had PARAMETERs, and PARAMETERs equal to
99999 and 200 should have been defined instead of
repeatedly using "magic numbers". More importantly,
the code will fail if NN exceeds 99999, but the code
does not check for this. I hope someone will fix this.
In the code dsged the variables half, one, two should
be made parameters, and instead of
IMPLICIT DOUBLE PRECISION (A-H, O-Z)
IMPLICIT NONE
should be used and all variables declared. Although
IMPLICIT NONE is not standard Fortran 77, it is
standard Fortran 90 and is supported by g77.
Experienced Fortranners know that IMPLICIT NONE
catches errors. Another defect is the use of specific
intrinsic functions such as DSQRT. There is no need to
use this, since the SQRT function is generic, handling
both single and double precision arguments.
Maybe there should R coding standards to address such
issues. I hope that eventually the Fortran code in R
will use the modern features of Fortran 90 and later
standards, using the gfortran compiler. However, with
a little effort one can still write clean code in
Fortran 77 that also conforms to later standards.
Vivek Rao
____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
On Wed, 11 Apr 2007, Vivek Rao wrote:> I have some comments on the Fortran code in the > fseries package in file 4A-GarchModelling.f , > especially the subroutine GARCHFIT and function > DSNORM. > I appended the code to the end of an earlier message, > but it was rejected by some rule. Let me first say > that I am grateful that packages for financial > econometrics exist in R.Please pass those on to the maintainer. Note that currently we expect only Fortran 77 to be used in R and (preferably) its packages, as there still are users with a Fortran 77 compiler and nothing later. One major group are those on Windows, and it is hoped that that will move to gcc 4.2.x in 2007. There are still quite a few users on OSes that are two or more years old and for which gcc3 is the norm.> Fortran 77 had PARAMETERs, and PARAMETERs equal to > 99999 and 200 should have been defined instead of > repeatedly using "magic numbers". More importantly, > the code will fail if NN exceeds 99999, but the code > does not check for this. I hope someone will fix this. > > In the code dsged the variables half, one, two should > be made parameters, and instead of > > IMPLICIT DOUBLE PRECISION (A-H, O-Z) > > IMPLICIT NONE > > should be used and all variables declared. Although > IMPLICIT NONE is not standard Fortran 77, it is > standard Fortran 90 and is supported by g77. > Experienced Fortranners know that IMPLICIT NONE > catches errors. Another defect is the use of specific > intrinsic functions such as DSQRT. There is no need to > use this, since the SQRT function is generic, handling > both single and double precision arguments. > > Maybe there should R coding standards to address such > issues. I hope that eventually the Fortran code in R > will use the modern features of Fortran 90 and later > standards, using the gfortran compiler. However, with > a little effort one can still write clean code in > Fortran 77 that also conforms to later standards.The Fortran code in R itself is (entirely, I think) imported from elsewhere, e.g. from EISPACK or LAPACK or Netlib. We have little interest in changing long-established code, and as the recent thread 'eigen in beta' shows, everytime we update such code someone thinks there is a new bug in R. The developer.r-project.org has a collection of references to encourage 'portable programming', including on Fortran standards.> Vivek Rao-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Hi Vivek,>>>>> "Vivek" == Vivek Rao <rvivekrao at yahoo.com> >>>>> 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