[Rd] Copyright on src/nmath/qnorm.c
At the top of src/nmath/qnorm.c it is stated: * Copyright (C) 1998 Ross Ihaka * Copyright (C) 2000--2005 The R Development Core Team * based on AS 111 (C) 1977 Royal Statistical Society * and on AS 241 (C) 1988 Royal Statistical Society The routine is in fact an f2c'd version of AS241 from StatLib: http://lib.stat.cmu.edu/apstat/241 and http://lib.stat.cmu.edu/apstat/ It seems odd to me that this is re-licensed under GPL and copyright asserted to be held by R Development Core Team. I expect that if I looked further I could find plenty of other routines with a similar heritage. The StatLib page states, The Royal Statistical Society holds the copyright to these routines, but has given its permission for their distribution provided that no fee is charged. Why does R Development Core Team claim copyright for what appears to be work copyright RSS? You really ought to ascribe the copyright to RSS. I don't think that the GPL is compatible with the StatLib license since the GPL does not forbid charging a fee for distribution. I guess you could come to some agreement with the RSS and I'm sure they would be happy to help. I think that it is important to be very precise on matters of licensing which is why I raise the point. David Heffernan. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rounding multinomial proportions
I present you with a function that solves a problem that has bugged me for
many years. I think the problem may be general enough to at least consider
adding this function, or a revamped version of it, to the 'stats' package,
with the other multinomial functions reside.
I'm using R to export data to text files, which are input data for an
external model written in C++. Parts of the data are age distributions, in
the form of relative frequency in each year:
Year Age1 Age2 ... Age10
1980 0.123 0.234 ... 0.001
... ......... ...
Each row should sum to exactly 1. The problem is that when I preprocess
each line in R as p-a/sum(a), occasionally a line will sum to 0.999,
1.002, or the like. This could either crash the external model or lead to
wrong conclusions.
I believe similar partitioning is commonly used in a wide variety of
models, making this a general problem for many modellers.
In the past, I have checked every line manually, and then arbitrarily
tweaked one or two values up or down to make the row sum to exactly one,
but two people would tweak differently. Another semi-solution is to write
the values to the text file in a very long format, but this would (1) make
it harder to visually check the numbers and (2) the numbers in the article
or report would no longer match the data files exactly, so other
scientists could not repeat the analysis and get the same results.
Once I implemented a quick and dirty solution, simply setting the last
proportion (Age10 above) as 1 minus the sum of ages 1-9. I quickly stopped
using that approach when I started seeing negative values.
After this introduction, the attached round_multinom.html should make
sense. The algorithm I ended up choosing comes from allocating seats in
elections, so I was tempted to provide that application as well, although
it makes the interface and documentation slightly more confusing.
The working title of this function was a short and catchy vote(), but I
changed it to round_multinom(), even though it's not matrix-oriented like
the other *multinom functions. That would probably be straightforward to
do, but I'll keep it as a vector function during the initial discussion.
I'm curious to hear your impressions and ideas. In the worst case, this is
a not-so-great solution to a marginal problem. In the best case, this
might be worth a short note in the Journal of Statistical Software.
Thanks for your time,
Arni
P.S. In case the mailing list doesn't handle attachments, I've placed the
same files on http://www.hafro.is/~arnima/ for your convenience.\name{round_multinom}
\alias{round_multinom}
\encoding{UTF-8}
\title{
Round Multinomial Proportions (or Allocate Seats from Election
Results)
}
\description{
This function can round multinomial proportions to a given number of
decimal places, while making sure the rounded proportions sum to
exactly one. This is achieved using one of three algorithms that were
originally invented to allocate seats from election results.
It is often necessary to round proportions, e.g. to produce legible
percentages for an article or a presentation. Rounding also takes
place when data are written to a text file, to be analyzed by an
external model. The rounded proportions often fail to add to exactly
one,
\preformatted{
a - c(67630, 116558, 207536, 251555, 356721)
p - round(a/sum(a), 3) # 0.068 0.117 0.208 0.252 0.357
sum(p) # 1.002}
which would make the rounded proportions illegal input data for many
models. Instead of manually checking and arbitrarily tweaking
proportions so they add to exactly one, this function can guarantee
that condition, using an unbiased algorithm.
}
\usage{
round_multinom(x, digits = NULL, seats = NULL, method=SL, labels = names(x))
}
\arguments{
\item{x}{vector containing multinomial proportions or counts.}
\item{digits}{
number of decimal places to use when rounding multinomial
proportions.
}
\item{seats}{number of seats to allocate from election results.}
\item{method}{
string specifying the algorithm to use: \code{DH}, \code{MSL},
or \code{SL}.
}
\item{labels}{optional vector of names for the output vector.}
}
\details{
This function should be called \emph{either} with a \code{digits}
argument to round multinomial proportions, \emph{or} with a
\code{seats} argument to allocate seats from election results, not
both.
The algorithms are variations of the \dQuote{highest averages} method
for allocating seats proportionally from multiparty election results:
\describe{
\item{\code{DH}}{
d'Hondt method, involves the series 1, 2, 3, \ldots, \eqn{n}.
Favors big parties.
}
\item{\code{MSL}}{
Modified Sainte-Laguë, involves the series 1, 2.4, 3.8, \ldots,
1.4\eqn{n}--0.4. Favors big parties slightly.
}
\item{\code{SL}}{
Sainte-Laguë. Involves the series 1, 3, 5, \ldots,
[Rd] LinkingTo and C++
Hello,
I've been trying to make LinkingTo work when the package linked to has
c++ code.
I've put dumb packages to illustrate this emails here ;
http://addictedtor.free.fr/misc/linkingto
Package A defines this C++ class:
class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;
Package B has this function :
SEXP say_hello(){
A a ;
return a.hello() ;
}
headers of package A are copied into inst/include so that package B can
have.
LinkingTo: A
in its DESCRIPTION file.
Also, package B has the R function ;
g - function(){
.Call(say_hello, PACKAGE = B)
}
With this I can compile A and B, but then I get :
$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
/usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch - tryCatchList - tryCatchOne - Anonymous
If I then add a Makevars in B with this :
# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )
PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)
Then it works:
$ Rscript -e B::g()
[1] hello
So it appears that adding the -I flag, which is what LinkingTo does is
not enough when the package linking from (B) actually has to link to
the linked to package (A).
I've been looking at
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
but it seems only applicable to c(++) functions and not classes ...
What am I missing ? Should/can linkingto be extended in a way that
accomodates c++
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LinkingTo and C++
On 02/11/2010 10:08 AM, Romain Francois wrote:
Hello,
I've been trying to make LinkingTo work when the package linked to has
c++ code.
I've put dumb packages to illustrate this emails here ;
http://addictedtor.free.fr/misc/linkingto
Package A defines this C++ class:
class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;
Package B has this function :
SEXP say_hello(){
A a ;
return a.hello() ;
}
headers of package A are copied into inst/include so that package B can
have.
LinkingTo: A
in its DESCRIPTION file.
Also, package B has the R function ;
g - function(){
.Call(say_hello, PACKAGE = B)
}
With this I can compile A and B, but then I get :
$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
/usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch - tryCatchList - tryCatchOne - Anonymous
If I then add a Makevars in B with this :
# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )
PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)
Then it works:
$ Rscript -e B::g()
[1] hello
So it appears that adding the -I flag, which is what LinkingTo does is
not enough when the package linking from (B) actually has to link to
the linked to package (A).
I've been looking at
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
but it seems only applicable to c(++) functions and not classes ...
What am I missing ? Should/can linkingto be extended in a way that
accomodates c++
Romain
One other way of course would be to have some lib support, so that for
example an R library holds not only R packages but shared libraries.
So for example, if as part of package A's Makevars, I copy its A.so into
R.home( component = lib ) and rename it libA.so :
RLIBDIR=$(shell $(R_HOME)/bin/Rscript -e cat(R.home(component='lib')) )
all: $(SHLIB) install
install:
cp $(SHLIB) $(RLIBDIR)/lib$(SHLIB)
cp -f A.h ../inst/include
Then B can just have this Makevars :
PKG_LIBS=-lA
as well as the LinkingTo: A in the description.
Now I realize that R.home(component='lib') is not the right place where
to host libA.so, as one might not have rights, etc ... but should there
be a right place, as a per-R-library lib folder ?
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rounding multinomial proportions
Ugh, I made a typo at the very heart of my message: when I preprocess each line in R as p-a/sum(a), occasionally a line will sum to 0.999, 1.002, or the like should be when I preprocess each line in R as p-round(a/sum(a),3) occasionally a line will sum to 0.999, 1.002, or the like Also, the first paragraph should end with where the other multinomial functions reside. Revision 2, Arni On Thu, 11 Feb 2010, Arni Magnusson wrote: I present you with a function that solves a problem that has bugged me for many years. I think the problem may be general enough to at least consider adding this function, or a revamped version of it, to the 'stats' package, with the other multinomial functions reside. I'm using R to export data to text files, which are input data for an external model written in C++. Parts of the data are age distributions, in the form of relative frequency in each year: Year Age1 Age2 ... Age10 1980 0.123 0.234 ... 0.001 ... ......... ... Each row should sum to exactly 1. The problem is that when I preprocess each line in R as p-a/sum(a), occasionally a line will sum to 0.999, 1.002, or the like. This could either crash the external model or lead to wrong conclusions. I believe similar partitioning is commonly used in a wide variety of models, making this a general problem for many modellers. In the past, I have checked every line manually, and then arbitrarily tweaked one or two values up or down to make the row sum to exactly one, but two people would tweak differently. Another semi-solution is to write the values to the text file in a very long format, but this would (1) make it harder to visually check the numbers and (2) the numbers in the article or report would no longer match the data files exactly, so other scientists could not repeat the analysis and get the same results. Once I implemented a quick and dirty solution, simply setting the last proportion (Age10 above) as 1 minus the sum of ages 1-9. I quickly stopped using that approach when I started seeing negative values. After this introduction, the attached round_multinom.html should make sense. The algorithm I ended up choosing comes from allocating seats in elections, so I was tempted to provide that application as well, although it makes the interface and documentation slightly more confusing. The working title of this function was a short and catchy vote(), but I changed it to round_multinom(), even though it's not matrix-oriented like the other *multinom functions. That would probably be straightforward to do, but I'll keep it as a vector function during the initial discussion. I'm curious to hear your impressions and ideas. In the worst case, this is a not-so-great solution to a marginal problem. In the best case, this might be worth a short note in the Journal of Statistical Software. Thanks for your time, Arni P.S. In case the mailing list doesn't handle attachments, I've placed the same files on http://www.hafro.is/~arnima/ for your convenience. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copyright on src/nmath/qnorm.c
David Heffernan wrote: At the top of src/nmath/qnorm.c it is stated: * Copyright (C) 1998 Ross Ihaka * Copyright (C) 2000--2005 The R Development Core Team * based on AS 111 (C) 1977 Royal Statistical Society * and on AS 241 (C) 1988 Royal Statistical Society The routine is in fact an f2c'd version of AS241 from StatLib: http://lib.stat.cmu.edu/apstat/241 and http://lib.stat.cmu.edu/apstat/ It seems odd to me that this is re-licensed under GPL and copyright asserted to be held by R Development Core Team. I expect that if I looked further I could find plenty of other routines with a similar heritage. (a) We sought permission from the RSS to use the Applied Statistics algorithms in R, and GPL was mentioned in the discussions. There is a list of such algorithms in doc/COPYRIGHTS. (b) Multiple copyright statements refer to _changes_ to code (RSS does not automatically obtain copyright for our modifications, including the f2c translation), and as such, the headers are accurate. Peter D. The StatLib page states, The Royal Statistical Society holds the copyright to these routines, but has given its permission for their distribution provided that no fee is charged. Why does R Development Core Team claim copyright for what appears to be work copyright RSS? You really ought to ascribe the copyright to RSS. I don't think that the GPL is compatible with the StatLib license since the GPL does not forbid charging a fee for distribution. I guess you could come to some agreement with the RSS and I'm sure they would be happy to help. I think that it is important to be very precise on matters of licensing which is why I raise the point. David Heffernan. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LinkingTo and C++
Romain,
I think your'e confusing two entirely different concepts here:
1) LinkingTo: allows a package to provide C-level functions to other packages
(see R-ext 5.4). Let's say package A provides a function foo by calling
R_RegisterCCallable for that function. If a package B wants to use that
function, it uses LinkingTo: and calls R_GetCCallable to obtain the function
pointer. It does not actually link to package A because that is in general not
possible - it simply obtains the pointers through R. In addition, LinkingTo:
makes sure that you have access to the header files of package A which help you
to cast the functions and define any data structures you may need. Since C++ is
a superset of C you can use this facility with C++ as long as you don't depend
on anything outside of the header files.
2) linking directly to another package's shared object is in general not
possible, because packages are not guaranteed to be dynamic libraries. They are
usually shared objects which may or may not be compatible with a dynamic
library on a given platform. Therefore the R-ext describes other way in which
you may provide some library independently of the package shared object to
other packages (see R-ext 5.8). The issue is that you have to create a separate
library (PKG/libs[/arch]/PKG.so won't work in general!) and provide this to
other packages. As 5.8 says, this is in general not trivial because it is very
platform dependent and the most portable way is to offer a static library.
To come back to your example, LinkingTo: A and B will work if you remove
Makevars from B (you don't want to link) and put your hello method into the A.h
header:
library (B)
Loading required package: A
.Call(say_hello, PACKAGE = B)
[1] hello
However, your'e not really using the LinkingTo: facilities for the functions so
it's essentially just helping you to find the header file.
Cheers,
Simon
On Feb 11, 2010, at 4:08 AM, Romain Francois wrote:
Hello,
I've been trying to make LinkingTo work when the package linked to has c++
code.
I've put dumb packages to illustrate this emails here ;
http://addictedtor.free.fr/misc/linkingto
Package A defines this C++ class:
class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;
Package B has this function :
SEXP say_hello(){
A a ;
return a.hello() ;
}
headers of package A are copied into inst/include so that package B can have.
LinkingTo: A
in its DESCRIPTION file.
Also, package B has the R function ;
g - function(){
.Call(say_hello, PACKAGE = B)
}
With this I can compile A and B, but then I get :
$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
/usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch - tryCatchList - tryCatchOne - Anonymous
If I then add a Makevars in B with this :
# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )
PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)
Then it works:
$ Rscript -e B::g()
[1] hello
So it appears that adding the -I flag, which is what LinkingTo does is not
enough when the package linking from (B) actually has to link to the
linked to package (A).
I've been looking at
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
but it seems only applicable to c(++) functions and not classes ...
What am I missing ? Should/can linkingto be extended in a way that
accomodates c++
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2
__
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] LinkingTo and C++
Thanks.
On 02/11/2010 05:55 PM, Simon Urbanek wrote:
Romain,
I think your'e confusing two entirely different concepts here:
Yes. The name LinkingTo probably helped my confusion.
1) LinkingTo: allows a package to provide C-level functions to other packages
(see R-ext 5.4). Let's say package A provides a function foo by calling
R_RegisterCCallable for that function. If a package B wants to use that
function, it uses LinkingTo: and calls R_GetCCallable to obtain the function
pointer. It does not actually link to package A because that is in general not
possible - it simply obtains the pointers through R. In addition, LinkingTo:
makes sure that you have access to the header files of package A which help you
to cast the functions and define any data structures you may need. Since C++ is
a superset of C you can use this facility with C++ as long as you don't depend
on anything outside of the header files.
2) linking directly to another package's shared object is in general not
possible, because packages are not guaranteed to be dynamic libraries. They are
usually shared objects which may or may not be compatible with a dynamic
library on a given platform. Therefore the R-ext describes other way in which
you may provide some library independently of the package shared object to
other packages (see R-ext 5.8). The issue is that you have to create a separate
library (PKG/libs[/arch]/PKG.so won't work in general!) and provide this to
other packages. As 5.8 says, this is in general not trivial because it is very
platform dependent and the most portable way is to offer a static library.
To come back to your example, LinkingTo: A and B will work if you remove
Makevars from B (you don't want to link)and put your hello method into the A.h
header:
Sure. but in real life I can't realistically put everything in the
header files.
Thanks again.
Romain
library (B)
Loading required package: A
.Call(say_hello, PACKAGE = B)
[1] hello
However, your'e not really using the LinkingTo: facilities for the functions so
it's essentially just helping you to find the header file.
Cheers,
Simon
On Feb 11, 2010, at 4:08 AM, Romain Francois wrote:
Hello,
I've been trying to make LinkingTo work when the package linked to has c++ code.
I've put dumb packages to illustrate this emails here ;
http://addictedtor.free.fr/misc/linkingto
Package A defines this C++ class:
class A {
public:
A() ;
~A() ;
SEXP hello() ;
} ;
Package B has this function :
SEXP say_hello(){
A a ;
return a.hello() ;
}
headers of package A are copied into inst/include so that package B can have.
LinkingTo: A
in its DESCRIPTION file.
Also, package B has the R function ;
g- function(){
.Call(say_hello, PACKAGE = B)
}
With this I can compile A and B, but then I get :
$ Rscript -e B::g()
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '/usr/local/lib/R/library/B/libs/B.so':
/usr/local/lib/R/library/B/libs/B.so: undefined symbol: _ZN1AD1Ev
Calls: :: ... tryCatch - tryCatchList - tryCatchOne - Anonymous
If I then add a Makevars in B with this :
# find the root directory where A is installed
ADIR=$(shell $(R_HOME)/bin/Rscript -e cat(system.file(package='A')) )
PKG_LIBS= $(ADIR)/libs/A$(DYLIB_EXT)
Then it works:
$ Rscript -e B::g()
[1] hello
So it appears that adding the -I flag, which is what LinkingTo does is not enough when the package
linking from (B) actually has to link to the linked to package (A).
I've been looking at
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
but it seems only applicable to c(++) functions and not classes ...
What am I missing ? Should/can linkingto be extended in a way that accomodates
c++
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/NrTG : Rcpp 0.7.5
|- http://tr.im/MPYc : RProtoBuf: protocol buffers for R
`- http://tr.im/KfKn : Rcpp 0.7.2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes when setWinProgressBar is give a numeric value for label argument
Thanks, I would be happy with an error that did not crash R, coercion just makes life a little easier, but I can live without that if you are not sure or there are reasons not to (speed being on possibility). It looks like you just underestimated how stupid I could be. Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Thursday, February 11, 2010 11:05 AM To: Greg Snow Cc: r-devel Subject: Re: [Rd] R crashes when setWinProgressBar is give a numeric value for label argument Greg, winProgressBar() has internal checks for the argument types, and for some unaccounted-for reason I omitted them in setWinProgressBar(). So 2) is easy (cut-and-paste). I am less sure that we should add coercion, and sure that if we add it to setWinProgressBar() we should also add it to winProgressBar(). But as you suggested it, I've done so. Thanks for the report. Brian Ripely On Wed, 10 Feb 2010, Greg Snow wrote: This problem can be seen by the following commands: pb - winProgressBar(max=1000, label='0') b - 1 setWinProgressBar(pb, b, label=b) This set of commands (on windows of course, XP in this case) causes R to crash. This is not strictly a bug since the documentation states that the label argument should be a character string and using as.character(b) does work properly. But when I (and possibly others) forget this and use something like the above, having the whole R process crash seems a bit extreme. Possible responses: 1. ignore this and hope that after being punished for not remembering the correct syntax enough times I will eventually learn to do the correct thing. 2. add a check and generate an error if title or lab is not a character string (less severe punishment, I may learn eventually, but maybe not as quick). 3. add label - as.character(label) and same idea for title, so that the above code works without the user needing to remember the as.character. This may need a check for NULL values as well. 4. Something else that I have not thought of. Number 1 would be easiest for R core, hardest on me. Numbers 2 and 3 have the potential drawback of slowing things down slightly. My sessionInfo() sessionInfo() R version 2.10.1 Patched (2010-02-08 r51108) 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.1 Same thing happens in non-patched 2.10.1 Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LinkingTo and C++
On 02/11/2010 07:40 PM, Simon Urbanek wrote: On Feb 11, 2010, at 12:24 PM, Romain Francois wrote: Thanks. On 02/11/2010 05:55 PM, Simon Urbanek wrote: Romain, I think your'e confusing two entirely different concepts here: Yes. The name LinkingTo probably helped my confusion. Admittedly, it's probably not the best name ;). 1) LinkingTo: allows a package to provide C-level functions to other packages (see R-ext 5.4). Let's say package A provides a function foo by calling R_RegisterCCallable for that function. If a package B wants to use that function, it uses LinkingTo: and calls R_GetCCallable to obtain the function pointer. It does not actually link to package A because that is in general not possible - it simply obtains the pointers through R. In addition, LinkingTo: makes sure that you have access to the header files of package A which help you to cast the functions and define any data structures you may need. Since C++ is a superset of C you can use this facility with C++ as long as you don't depend on anything outside of the header files. 2) linking directly to another package's shared object is in general not possible, because packages are not guaranteed to be dynamic libraries. They are usually shared objects which may or may not be compatible with a dynamic library on a given platform. Therefore the R-ext describes other way in which you may provide some library independently of the package shared object to other packages (see R-ext 5.8). The issue is that you have to create a separate library (PKG/libs[/arch]/PKG.so won't work in general!) and provide this to other packages. As 5.8 says, this is in general not trivial because it is very platform dependent and the most portable way is to offer a static library. To come back to your example, LinkingTo: A and B will work if you remove Makevars from B (you don't want to link)and put your hello method into the A.h header: Sure. but in real life I can't realistically put everything in the header files. It was just an example based on your example ;) - which was not very realistic, either. It practice it is reasonable, because it is sufficient to declare in the headers whatever you're providing so the only homework is to cast function pointers you have obtained via R_GetCCallable to the declarations from the header file. I suspect what you meant is not as much related to LinkingTo: (since the mess C++ creates at the binary level is rather hard to pass through dl pointers - but if someone has a working solution it may be worth to create a package), but rather to provide a library. That is not covered by R at this point so you're in realm of R-ext 5.8. Given how non-trivial task this is (to get it right) it may be worthwhile thinking about a portable solution and add it to R, but I don't think anyone has done that yet (mainly due to the low benefit/cost ratio I suspect). For all cases so far it was sufficient to create C or R level API for other package to use. Cheers, Simon Yes. The goal is to provide a library that other packages can just use. I thought LinkingTo would help, but now I guess not. or maybe just so that B can find headers of A. The R_RegisterCCallable/R_GetCCallable business seems to be only applicable when you are developping both A and B and you deal with plain functions, otherwise the name mangling, overloading of methods, etc would make the task hard and not fun at all. So I guess, yes the question is how to reliably and portably provide a library for package A so that package B can just use it. This would be very valuable. Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/NrTG : Rcpp 0.7.5 |- http://tr.im/MPYc : RProtoBuf: protocol buffers for R `- http://tr.im/KfKn : Rcpp 0.7.2 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R projects with multiple external libraries
On 2/11/10 9:43 AM, rt wrote: Hi, I have just learned how to use compile and link libraries using make and how to create R projects using R CMD build or INSTALL. My understanding of both is somewhat limited and hence the question. I have a main library written in c which depends on other external libraries. Main library is to be called from R using .Call. The goal is to create a single R project that will compile all the external libraries, the main library, R-C wrappers and install it. I am unsure about the proper structure of R project directories and the general workflow such that: (a) external libraries and the main libraries are built first using make that I already have (b) R-C Wrapper is compiled and installed using R CMD install. I understand that there are issues using Makefiles and that there are preferred ways of doing these things. I am not sure how to use Makevars instead of Makefile for this purpose. Any help and in particular pointers to examples of R packages with multiple external libraries would be appreciated. 1.2.1 Using Makevars in WRE (R-ext manual) has some detail on this and suggests looking at fastICA for an example. Quote from manual: If you want to create and then link to a library, say using code in a subdirectory, use something like .PHONY: all mylibs all: $(SHLIB) $(SHLIB): mylibs mylibs: (cd subdir; make) + seth -- Seth Falcon | @sfalcon | http://userprimary.net/user __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Darwinian software development and the library function
Hi all, Legend has it, that polite R programmers don't overwrite, say, the print function. However, this seems quite un-Darwinian to me (especially given that I don't want to call all my arguments x and y). I might want a function print.foo (myfoo, ...). So I decided to be very impolite (in one of my packages) and overwrite a few standard generics. Plus, to the best of my knowledge it doesn't interfere with normal use (yay...). This brings us to the library function. Which by default gives a whole lot of warnings loading my package (and any other package that does something similar), scaring off polite R programmers and perhaps some mainstream R users. I'm starting to think that the default for library, should be warn.conflicts=FALSE. However, just reading the documentation, I noticed a reference to something called .conflicts.OK. Not sure what that does, however if it does what it sounds like, then it largely fixes the problem. The biggest issue though, is whether or not one should be impolite (i.e. Darwinian) and overwrite print etc in the first place...? I'm inclined to go in favour of overwriting the functions. However, it has the potential to introduce some technical problems. Other's opinions appreciated. kind regards -- Charlotte Maia http://sites.google.com/site/maiagx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] filenames with special characters in the R/ directory of a package?
According to R-exts.pdf (page 3):
For maximal portability filenames should only
contain only ASCII characters not excluded already (that is
A-Za-z0-9._!#$%+,;=...@^(){}’[]
I have some files with special characters like '[' and '%' e.g.
'[.set.R'. I also have some functions that also have those special
characters defined in those files exported in NAMESPACE.
I use the following command to install. And I get no warning or errors.
R CMD INSTALL -d -l my_custom_dir my.pkg
I then load the package. I get the following errors and warnings. I
changed a file to one without these special characters. Then the
corresponding warning/error disappears. Is it the case that there
should never be files with special characters as names?
library(my.pkg)
Error in namespaceExport(ns, exports) :
undefined exports: %is%
In addition: Warning message:
S3 methods ‘[.set’ were declared in NAMESPACE but not found
Error: package/namespace load failed for 'my.pkg'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
