Skip to content

.NAME in .Fortran

7 messages · Peter Dunn, Duncan Murdoch, Rolf Turner +1 more

#
Hi all

I've been getting some emails from the R package maintainers that I need
to update some code in a CRAN packge that uses FORTRAN, to comply with
(not so recent) changes.  I've been a little busy...

I'm having trouble adjusting my code.  I hope someone can help.

The package was working fine, and a few R functions in my package had
lines like this:

tmp <- .Fortran( name="pdf", <other parameters here>)

and similar.  The "pdf" is the name of the FORTRAN subroutine being
called, of course.

When I replace that line with

tmp <- .Fortran( .NAME="pdf", <other parameters here>)


...the package then does not pass the checks.  The library package builds
OK with no errors or warnings, and then during "R CMD check" the examples
give this error:

out <- tweedie.profile( y~1, p.vec=seq(1.1, 1.9, length=9),
do.plot=TRUE)
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
.Error in .Fortran(.NAME = "pdfun", as.double(power),
as.double(phi[i]/(y[i]^(2 -  :
  supplied argument name '.NAME' does not match 'name'
Calls: tweedie.profile -> dtweedie.inversion -> .Fortran
Execution halted




I've had a search--including a read of the "Writing R Extensions" manual
on CRAN (I did read it, but interestingly a search of that document did
not reveal any instance of .NAME)--and I cannot see the problem.  It's
probably obvious.

Any help appreciated, even pointers to more info.

P.

sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base




The output from R CMD check:



R CMD check tweedie
* using log directory
'/Users/pdunn2/Documents/SharedFiles/pkd/Research/Rlibraries/tweedie/tweedi
e.Rcheck'
* using R version 2.15.1 (2012-06-22)
* using platform: x86_64-apple-darwin9.8.0 (64-bit)
* using session charset: UTF-8
* checking for file 'tweedie/DESCRIPTION' ... OK
* this is package 'tweedie' version '2.1.2'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking whether package 'tweedie' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ...
OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies
... OK
** checking whether the namespace can be unloaded cleanly ... OK
* loading checks for arch 'x86_64'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ...
OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies
... OK
** checking whether the namespace can be unloaded cleanly ... OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... NOTE
dtweedie.stable: no visible global function definition for 'dstable'
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'tweedie.plot':
tweedie.plot
  Code: function(y, xi = power, mu, phi, type = "pdfun", power = NULL,
                 add = FALSE, ...)
  Docs: function(y, xi, mu, phi, type = "pdf", power = NULL, add =
                 FALSE, ...)
  Mismatches in argument default values:
    Name: 'xi' Code: power Docs:
    Name: 'type' Code: "pdfun" Docs: "pdf"

* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... OK
* checking examples ...
** running examples for arch 'i386' ... ERROR
Running examples in 'tweedie-Ex.R' failed
The error most likely occurred in:

### Name: tweedie-package
### Title: Tweedie Distributions
### Aliases: tweedie-package Tweedie
### Keywords: models
### ** Examples
# Generate random numbers
set.seed(314)
y <- rtweedie( 500, p=1.5, mu=1, phi=1)
        # With index  p  between 1 and 2, this produces continuous
        # data with exact zeros
x <- rnorm( length(y), 0, 1)  # Unrelated predictor
# With exact zeros, index  p  must be between 1 and 2
# Fit the tweedie distribution; expect p about 1.5
out <- tweedie.profile( y~1, p.vec=seq(1.1, 1.9, length=9), do.plot=TRUE)
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
.Error in .Fortran(.NAME = "pdfun", as.double(power),
as.double(phi[i]/(y[i]^(2 -  :
  supplied argument name '.NAME' does not match 'name'
Calls: tweedie.profile -> dtweedie.inversion -> .Fortran
Execution halted
** running examples for arch 'x86_64' ... ERROR
Running examples in 'tweedie-Ex.R' failed
The error most likely occurred in:

### Name: tweedie-package
### Title: Tweedie Distributions
### Aliases: tweedie-package Tweedie
### Keywords: models
### ** Examples
# Generate random numbers
set.seed(314)
y <- rtweedie( 500, p=1.5, mu=1, phi=1)
        # With index  p  between 1 and 2, this produces continuous
        # data with exact zeros
x <- rnorm( length(y), 0, 1)  # Unrelated predictor
# With exact zeros, index  p  must be between 1 and 2
# Fit the tweedie distribution; expect p about 1.5
out <- tweedie.profile( y~1, p.vec=seq(1.1, 1.9, length=9), do.plot=TRUE)
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
.Error in .Fortran(.NAME = "pdfun", as.double(power),
as.double(phi[i]/(y[i]^(2 -  :
  supplied argument name '.NAME' does not match 'name'
Calls: tweedie.profile -> dtweedie.inversion -> .Fortran
Execution halted



--
Dr Peter Dunn
Biostatistician
Faculty of Science, Health, Education and
Engineering (T3.03; ML 33)
Ph: +61 7 5456 5085 | Fax: +61 7 5430 2896 | Email: pdunn2 at usc.edu.au |
Web: www.usc.edu.au <http://www.usc.edu.au/>





University of the Sunshine Coast, Locked Bag 4, Maroochydore DC, Queensland, 4558 Australia.
CRICOS Provider No: 01595D
Please consider the environment before printing this email.
This email is confidential. If received in error, please delete it from your system.
#
I don't understand at all what the problem is, but a workaround
is simply not to specify the "pdf" argument in "name=value" form
but rather in positional form.  I.e. just make it the first argument
to .Fortran().  As in:

     tmp <- .Fortran("pdf", <other parameters here>)

Works for me! :-)

     cheers,

         Rolf
On 11/09/12 13:21, Peter Dunn wrote:
<SNIP>
#
On 12-09-10 9:21 PM, Peter Dunn wrote:
I suspect you are doing your checks with an old version, not with the 
one listed below.  The first argument was called "name" until R 2.13.0 
was released; at that point it was changed to ".NAME" (to prevent 
conflicts with something or other).  It seems someone forgot to note 
this in the NEWS file...

You can find which version did the checks by looking at the header in 
the 00check.log file created during the check.  You could also follow 
Rolf's advice and not name the first arg.

Duncan Murdoch
#
Duncan:

I experimented by using ".NAME =" in a call to .Fortran()
in one of my packages and got the same error as Peter.
I am definitely (!) using R version 2.15.1.

Doing args(.Fortran) gives:
If I replace ".NAME" by "name" in my call to .Fortran() everything works
smoothly.

Consequently:  It looks to me like there is a bug here.  An inconsistency
between .Fortran() and ".Primitive(".Fortran")" perhaps.

     cheers,

         Rolf
On 12/09/12 00:09, Duncan Murdoch wrote:
#
On 12-09-11 4:44 PM, Rolf Turner wrote:
Yes, Peter told me the same.
There was a bug; it was fixed in August (also without a NEWS entry). 
You shouldn't see it in R-patched, or 2.15.2, when that is released.

Duncan Murdoch
#
On 12/09/12 10:50, Duncan Murdoch wrote:
<SNIP>

I installed R-patched and experimented again.  Now no error is thrown 
when .Fortran()
is called with ".NAME=".   However, neither is any error thrown when 
..Fortran is called
with "name=".

Is this as it should be, or is there still something not quite right?

     cheers,

         Rolf
#
On 11/09/2012 13:09, Duncan Murdoch wrote:
Actually, an incorrect check got re-activated by 2.15.1.  NEWS for 
R-devel says

     ? The functions .C(), .Call(), .External() and .Fortran() now check
       that they are called with an unnamed first argument: the formal
       arguments were changed from name= to .NAME= in R 2.13.0, but some
       packages were still using the old name.
Actually the CRAN message explicitly asked Master Dunn to use an unnamed 
first argument ....

Or even follow the advice of the ?.Fortran help page in R-patched/R-devel:

      These functions are all primitive, and ?.NAME? is always matched
      to the first argument supplied (which should not be named).  The
      other named arguments follow ?...? and so cannot be abbreviated.

The reason for that advice is that only unnamed first arguments will 
work for all recent versions of R.

As the posting guide says

'f you are using an old version of R and think it does not work 
properly, upgrade to the latest version and try that, before posting. If 
possible, try the current R-patched or R-devel version of R (see the FAQ 
for details), to see if the problem has already been addressed.'