[Rd] R CMD check: Error in .C

2009-10-26 Thread Etienne Laliberté
Function/file names are hypothetical. Say I have written myfunction.R,
which calls myfunction.c via .C("myfunction", ...).

I've compiled successfully myfunction.c via R CMD SHLIB myfunction.c
in the terminal. Then, in the R console:

dyn.load("myfunction.so")
source("myfunction.R")
test <- myfunction() # works fine

So everything is in order, myfunction works perfectly.

Now I want to include myfunction() into a package called mypackage.
Here's what I did:

1) I've added PACKAGE = "mypackage" in the .C() line in myfunction.R.
2) I put myfunction.R into the R folder of mypackage
3) I put myfunction.c into the src folder of mypackage
4) I created myfunction.Rd into the man folder

I then build the package via R CMD build mypackage. All good. However,
when I run R CMD check mypackage, I get the following error (note that
I translated from french, might be a bit different in english):

Error in .C("myfunction", ...): C symbol name "myfunction" cannot be
found in the DLL for package "mypackage"

I would appreciate some help here. Please do not refer my to "Writing
R extensions" - if the answer's in there, I don't understand it.

Many thanks.

--
Etienne Laliberté

Rural Ecology Research Group
School of Forestry
University of Canterbury
Private Bag 4800
Christchurch 8140, New Zealand
Phone: +64 3 366 7001 ext. 8365
Fax: +64 3 364 2124
www.elaliberte.info

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Advice on how to arrange fix of buglet

2009-10-26 Thread Martin Maechler
> "JN" == Prof John C Nash 
> on Thu, 22 Oct 2009 10:53:43 -0400 writes:

JN> Recently I reported a small bug in optim's SANN method
JN> failing to report that it had exceeded the maximum
JN> function evaluation limit in the convergence code. This
JN> is a small enough matter that I was reluctant to create
JN> a full-blown bug report. Indeed in the optimx package
JN> Ravi Varadhan and I have been developing on r-forge
JN> (under the OptimizeR project) it was a minimal work
JN> around to fix the matter in our wrapper that
JN> incorporates optim() and a number of other tools. While
JN> I don't normally do C code, I could likely figure out a
JN> fix for optim too.

JN> My query is about how to best get this done without
JN> causing a lot of work for others i.e., where to I send
JN> patches etc. I expect there are a number of similar
JN> issues for different areas of R and its documentation,
JN> and a clarification from someone in the core team could
JN> streamline things. Maybe the bug system is still the
JN> right place?

Yes, and in R the function bug.report() 

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R CMD check: Error in .C

2009-10-26 Thread Duncan Murdoch

Etienne Laliberté wrote:

Function/file names are hypothetical. Say I have written myfunction.R,
which calls myfunction.c via .C("myfunction", ...).

I've compiled successfully myfunction.c via R CMD SHLIB myfunction.c
in the terminal. Then, in the R console:

dyn.load("myfunction.so")
source("myfunction.R")
test <- myfunction() # works fine

So everything is in order, myfunction works perfectly.

Now I want to include myfunction() into a package called mypackage.
Here's what I did:

1) I've added PACKAGE = "mypackage" in the .C() line in myfunction.R.
2) I put myfunction.R into the R folder of mypackage
3) I put myfunction.c into the src folder of mypackage
4) I created myfunction.Rd into the man folder

I then build the package via R CMD build mypackage. All good. However,
when I run R CMD check mypackage, I get the following error (note that
I translated from french, might be a bit different in english):

Error in .C("myfunction", ...): C symbol name "myfunction" cannot be
found in the DLL for package "mypackage"

I would appreciate some help here. Please do not refer my to "Writing
R extensions" - if the answer's in there, I don't understand it.
  


What do you get from R CMD INSTALL mypackage? 


Duncan Murdoch

Many thanks.

--
Etienne Laliberté

Rural Ecology Research Group
School of Forestry
University of Canterbury
Private Bag 4800
Christchurch 8140, New Zealand
Phone: +64 3 366 7001 ext. 8365
Fax: +64 3 364 2124
www.elaliberte.info

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R CMD check: Error in .C

2009-10-26 Thread Mathieu Ribatet
Dear Etienne,

You probably want to create a zzz.R file in the /mypkg/R/ folder which
is just

.First.lib <- function(lib, pkg){
  library.dynam("MyPkgName", package = pkg, lib.loc = lib)
  return(invisible(0))
}

This would ensure that your shared library will be loaded.

Best,
Mathieu

Le lundi 26 octobre 2009 à 03:58 +0100, Etienne Laliberté a écrit :
> Function/file names are hypothetical. Say I have written myfunction.R,
> which calls myfunction.c via .C("myfunction", ...).
> 
> I've compiled successfully myfunction.c via R CMD SHLIB myfunction.c
> in the terminal. Then, in the R console:
> 
> dyn.load("myfunction.so")
> source("myfunction.R")
> test <- myfunction() # works fine
> 
> So everything is in order, myfunction works perfectly.
> 
> Now I want to include myfunction() into a package called mypackage.
> Here's what I did:
> 
> 1) I've added PACKAGE = "mypackage" in the .C() line in myfunction.R.
> 2) I put myfunction.R into the R folder of mypackage
> 3) I put myfunction.c into the src folder of mypackage
> 4) I created myfunction.Rd into the man folder
> 
> I then build the package via R CMD build mypackage. All good. However,
> when I run R CMD check mypackage, I get the following error (note that
> I translated from french, might be a bit different in english):
> 
> Error in .C("myfunction", ...): C symbol name "myfunction" cannot be
> found in the DLL for package "mypackage"
> 
> I would appreciate some help here. Please do not refer my to "Writing
> R extensions" - if the answer's in there, I don't understand it.
> 
> Many thanks.
> 
> --
> Etienne Laliberté
> 
> Rural Ecology Research Group
> School of Forestry
> University of Canterbury
> Private Bag 4800
> Christchurch 8140, New Zealand
> Phone: +64 3 366 7001 ext. 8365
> Fax: +64 3 364 2124
> www.elaliberte.info
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne   Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Buglet in optim() SANN

2009-10-26 Thread Ravi Varadhan
Dear John,

First let me apologize for not taking this off-list, since I feel that the
issues that you have raised are very important for optimizeRs to think
about.  

I completely agree with all you points.  Even though Brian Ripley is correct
in pointing out that for SANN `maxit' is the only stopping criterion, it is
still misleading when the convergence indicator says `0'.  By convention, a
zero indicator is taken to mean successful convergence to a local optimum,
i.e. to a point where the KKT conditions are satisfied.  If there is no
reasonable way to terminate SANN (or other stochastic search algorithms), it
might be more appropriate to indicate convergence as `NA', rather than `0'. 

Of course, for non-smooth and noisy functions we do not have the KKT
conditions to guide us in evaluating whether we have a good solution or not.
In these situations, the quality of the solution needs to be evaluated based
on problem-specific knowledge.  Hopefully, we can address this issue to some
extent in the future versions of "optimx". For example, if a user tries to
use SANN for a smooth objective function, then she should be forewarned.  

Best,
Ravi.


---

Ravi Varadhan, Ph.D.

Assistant Professor, The Center on Aging and Health

Division of Geriatric Medicine and Gerontology 

Johns Hopkins University

Ph: (410) 502-2619

Fax: (410) 614-9625

Email: rvarad...@jhmi.edu

Webpage:
http://www.jhsph.edu/agingandhealth/People/Faculty_personal_pages/Varadhan.h
tml

 




-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Prof. John C Nash
Sent: Sunday, October 25, 2009 6:34 PM
To: Prof Brian Ripley
Cc: r-devel@r-project.org
Subject: Re: [Rd] Buglet in optim() SANN

Indeed Brian is correct about the functioning of SANN and the R
documentation. I'd misread the "maxit" warning. Things can stay as they
are for now.

The rest of this msg is for information and an invitation to off-list
discussion.

I realize my posting opens up the can of worms about what "convergence"
means. As someone who has occasionally published discussions on
convergence versus termination, I'd certainly prefer to set the
'convergence' flag to 1 for SANN, since we have only a termination at
the maximum number of function evaluations and not necessarily a result
that can be presumed to be "optim"al. Or perhaps put a note in the
description of the 'convergence' flag to indicate the potential
misinterpretation with SANN where results need the user to externally
check if they are likely to be usable as an optimum.

It may be better to call the non-zero results for "convergence" a
"termination indicator" rather than an "error code". Some related
packages like ucminf give more than one non-zero indicators for results
that are generally usable as optima. They are informational rather than
errors. Writing our optimx wrapper for a number of methods has forced us
to think about how such information is returned and reported through a
flag like "convergence". There are several choices and plenty of room
for confusion.

Right now a few of us are working on improvements for optimization, but
the first goal is to get things working OK for smooth, precisely defined
functions. However, we have been looking at methods like SANN for
multimodal and noisy (i.e., imprecisely defined) functions. For those
problems, knowing when you have an acceptable or usable result is never
easy.

Comments and exchanges welcome -- off-list of course.

Cheers, JN


Prof Brian Ripley wrote:
> As the posting guide says, please read the help carefully before
> posting.  It does say:
> 
>  ?maxit? The maximum number of iterations. Defaults to ?100? for
>   the derivative-based methods, and ?500? for ?"Nelder-Mead"?.
>   For ?"SANN"? ?maxit? gives the total number of function
>   evaluations. There is no other stopping criterion.
>
>   Defaults to ?1?.
> 
> so this is indicating 'successful convergence' as documented.
> 
> On Tue, 20 Oct 2009, Prof. John C Nash wrote:
> 
>> I think SANN method in optim() is failing to report that it has not
>> converged. Here is an example
>>
>> genrose.f<- function(x, gs=NULL){ # objective function
>> ## One generalization of the Rosenbrock banana valley function (n
>> parameters)
>> n <- length(x)
>>if(is.null(gs)) { gs=100.0 }
>> fval<-1.0 + sum (gs*(x[1:(n-1)]^2 - x[2:n])^2 + (x[2:n] - 1)^2)
>>return(fval)
>> }
>>
>> xx<-rep(pi,10)
>> test<-optim(xx,genrose.f,method="SANN",control=list(maxit=1000,trace=1))
>> print(test)
>>
>>
>> Output is:
>>
>>> source("tsann.R")
>> sann objective function values
>> initial   value 40781.805639
>> iter  999 value 29.969529
>> final value 29.969529
>> sann stop

[Rd] Typo in help(parse_Rd, package="tools")

2009-10-26 Thread Henrik Bengtsson
Under See Also in help(parse_Rd, package="tools") it says:

Rd2HTML for the converters that use the output of parseRd.

Should be "parse_Rd" not "parseRd".

> sessionInfo()
R version 2.10.0 Patched (2009-10-26 r50212)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] tools_2.10.0

/H

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] help.start() only recognizes forward slashes in R_LIBS_USER which is not the default case

2009-10-26 Thread Henrik Bengtsson
I've found that the HTML help system started via help.start() requires
all forward slashes in R_LIBS_USER otherwise the Packages page is
corrupt/non-working.  Note that by default R_LIBS_USER is set by R on
startup.

Example 1:
With R_LIBS_USER=C:/Users/JohnDoe/R/win-library/2.10
> help.start() [and go to "Packages"]
If nothing happens, you should open
'http://127.0.0.1:6850/doc/html/index.html' yourself
This works!

Example 2:
With: R_LIBS_USER=C:\\Users\\JohnDoe\\R\\win-library\\2.10
> help.start() [and go to "Packages"]
If nothing happens, you should open
'http://127.0.0.1:6850/doc/html/index.html' yourself
Warning message:
In sub(paste(lib, "([^/]*)", "DESCRIPTION$", sep = "/"), "\\1",  :
  regcomp error:  'Invalid back reference'
> Making packages.html ...

with http://127.0.0.1:6850/doc/html/packages.html displaying:

Error in sub(paste(lib, "([^/]*)", "DESCRIPTION$", sep = "/"), "\\1",  :
  invalid regular expression
'C:\Users\JohnDoe\R\win-library\2.10/([^/]*)/DESCRIPTION$'

Example 3:
With R_LIBS_USER=C:\\Users\\JohnDoe/R/win-library/2.10
> help.start() [and go to "Packages"]
If nothing happens, you should open
'http://127.0.0.1:6850/doc/html/index.html' yourself

with http://127.0.0.1:6850/doc/html/packages.html displaying:

Packages in C:\Users\JohnDoe\R\win-library\2.10

C:\Users\JohnDoe/R/win-library/2.10/abind/DESCRIPTION   -- Title is missing --
C:\Users\JohnDoe/R/win-library/2.10/affxparser/DESCRIPTION  -- Title is
missing --
C:\Users\JohnDoe/R/win-library/2.10/affy/DESCRIPTION-- Title is missing --

where the abind link is
http://127.0.0.1:6850/library/C:%5CUsers%JohnDoe/R/win-library/2.10/abind/DESCRIPTION/html/00Index.html
and similarly for affxparser and so on.

This third case may(?)/is(?) set by R on startup if R_LIBS_USER is not
set, cf. help(.libPaths):

 By default 'R_LIBS' is unset, and 'R_LIBS_USER' is set to
 subdirectory 'R/win-library/x.y' of the home directory, for R
 x.y.z.

because HOME=C:\Users\JohnDoe is set by Windows.

It seems like the HTML help server only recognizes forward slashes in
R_LIBS_USER.

The following patch solves the problem (can be added to ~/.Rprofile):

.libPaths(gsub("\\", "/", .libPaths(), fixed=TRUE));


/Henrik

> sessionInfo()
R version 2.10.0 Patched (2009-10-26 r50212)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] tools_2.10.0

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel