Re: [Rd] about integration of a library into package creation
Hello, I dont understand such error coming from my installed package and dont appearing when i load the code source directly . The problem occur when the function capture the path value (FileIn), and so cannot find the file inside the directory. > findModelCluster(MetOpt, MetLab, Nu, q, K=1, G, Cx, Cy, DName="iris", fileIn="D:\\R\\library\\svcR\\data\\"); Erreur dans findModelCluster(MetOpt, MetLab, Nu, q, K = 1, G, Cx, Cy, DName = "iris", : impossible de changer la valeur d'un lien verrouillé (in English: impossible to change the value of a locked link) thank you --- Nicolas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in nortest cvm.test package (PR#8980)
I believe there to be a bug in the cvm.test module of the nortest package authored by Juergen Gross. I do not know how to contact the author directly. I've been running some normality tests using the nortest package. For some of my datasets the Cramer-von Mises normality test generates an extremely high probability (e.g., 1.637e+31) and indicates normality when the other tests do not. I don't believe the generated probability should exceed a value of "1". Below are the results of the tests and then, below that, I've provided the column of the datafile that results in the high value. Sincerely, Bob Powell Robert M. Powell Senior Project Scientist/Project Mgr. Horizon Environmental Corporation Suite 1700, Fisher Building 3011 W. Grand Blvd. Detroit, MI 48202 Tel (313) 874-0124 Fax (313) 874-0135 Cell(248) 977-0317 http://www.horizonenv.com > shapiro.test(Mn.Total..ug.kg) Shapiro-Wilk normality test data: Mn.Total..ug.kg W = 0.5269, p-value < 2.2e-16 > shapiro.test(ln.Mn.Total..ug/kg) Error in inherits(x, "factor") : object "ln.Mn.Total..ug" not found > shapiro.test(ln.Mn.Total..ug.kg) Shapiro-Wilk normality test data: ln.Mn.Total..ug.kg W = 0.943, p-value = 1.301e-06 > sf.test(Mn.Total..ug.kg) Shapiro-Francia normality test data: Mn.Total..ug.kg W = 0.5173, p-value < 2.2e-16 > sf.test(ln.Mn.Total..ug.kg) Shapiro-Francia normality test data: ln.Mn.Total..ug.kg W = 0.9403, p-value = 3.461e-06 > cvm.test(Mn.Total..ug.kg) Cramer-von Mises normality test data: Mn.Total..ug.kg W = 4.024, p-value = 1.637e+31 > cvm.test(ln.Mn.Total..ug.kg) Cramer-von Mises normality test data: ln.Mn.Total..ug.kg W = 0.356, p-value = 7.647e-05 > lillie.test(Mn.Total..ug.kg) Lilliefors (Kolmogorov-Smirnov) normality test data: Mn.Total..ug.kg D = 0.2325, p-value < 2.2e-16 > lillie.test(ln.Mn.Total..ug.kg) Lilliefors (Kolmogorov-Smirnov) normality test data: ln.Mn.Total..ug.kg D = 0.0869, p-value = 0.002011 OK, next the data column: Mn-Total, ug/kg 46 40 51 60 77 18 21 100 260 49 26 76 84 40 43 23 66 120 37 23 29 32 40 66 62 110 35 45 88 96 57 87 82 97 110 45 73 39 64 38 34 140 87 26 43 29 29 55 54 24 47 65 39 38 41 22 40 38 50 100 52 69 50 52 26 63 63 41 29 130 86 60 45 33 39 58 27 46 36 30 360 54 37 46 15 56 63 81 130 47 62 52 54 44 190 76 75 44 55 330 78 360 140 84 45 97 61 49 28 96 35 110 77 51 46 59 76 61 55 46 47 65 37 17 63 53 72 85 57 86 600 170 140 47 120 36 37 110 31 43 48 67 35 53 38 49 49 38 63 37 71 150 38 55 56 56 35 34 25 39 67 72 44 38 24 34 35 31 25 32 36 36 49 49 49 71 67 120 53 50 49 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] separators in data()
just out of curiosity: why is the default behavior in data() for reading in .csv files to use sep=";" (semicolon rather than comma)? is this a historical artifact of some sort, or is there other logic to it? It caught me by surprise since I was expecting it to be sep="," as in read.csv() ... cheers Ben Bolker -- 620B Bartram Hall[EMAIL PROTECTED] Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker Box 118525 (ph) 352-392-5697 Gainesville, FL 32611-8525 (fax) 352-392-3704 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug or not? (PR#8977)
Hi,
I am writing this email, because I am not sure if the issue I have
discovered is a bug or not.
For a few days I have been fiddling around with a small program that
calculates the reflectance of multilayer dielectric mirrors (eg. bragg
mirrors). It does not really matter what I did, what matters is that I
could not do that using R.
I had some sample data which I used to test if my R program works
correctly (if it fits the data it works). This sample data was for two
different incident angles with respect to the normal of the hypothetical
bragg mirror (0=B0 and 70=B0). The plots for 0=B0 matched perfectly but t=
hose
for 70=B0 were quite a bit off. After trying out all sorts of things for
several days, I tried the same algorithm in octave (matlab clone, but
open source). There, I got a perfect match for both 0=B0 and 70=B0. I alm=
ost
could not believe it, R must have calculated wrong.
The R version I use at home at the moment is 2.2.1 on gentoo linux. I
also tried version 2.1.0 at my university (debian stable), both had the
same result.
I uploaded everything to reproduce this to
http://n.ethz.ch/student/homartin/r-vs-octave/
There, you can also find the .pdf file of the comparison of the
reference, the R output and the one from octave.
The calculations are quite complex, nevertheless, I would be very happy
to read your reply concerning this problem.
Thanks in advance, best Regards,
Martin
I get only the r-devel digest, so I could'nt respond the direct way
(this message will not show up in the correct thread, probably), but:
there is nothing wrong with the R results AFAICS: I translated your
octave script one-to-one to R (see attachment). this produces (within
floating point prec. (double)) the same results. I propose you go
through this and your own R-script (which honestly was unreadable to me
:-)) with browser() or debug() and compare results for Ms1, Ms2, Msr on
the way to localise the differences in computation.
if you uncomment the last few lines, source("Rs.R") will give you
vectors which you can directly compare to the octave results (note that
the leading 499 zeros are still there, since I mimicked your octave script)
so: really no bug, right?
joerg
Rs <- function (lambda, theta, N) {
n0 = 3.66
n1 = 2.4
n2 = 1.45
nn = 1.00
lambda_ref = 1000
lambda_min = 500
lambda_max = 1500
increment = 5
ymin = 0
ymax = 1
d1 = lambda_ref / 4 / n1
d2 = lambda_ref / 4 / n2
theta0 = asin( nn / n0 * sin( theta ) )
theta1 = asin( nn / n1 * sin( theta ) )
theta2 = asin( nn / n2 * sin( theta ) )
etha_s0 = -n0 * cos( theta0 )
etha_s1 = n1 * cos( theta1 )
etha_s2 = n2 * cos( theta2 )
etha_sn = nn * cos( theta )
delta1 = 2 * pi / lambda * n1 * d1 * cos( theta1 )
delta2 = 2 * pi / lambda * n2 * d2 * cos( theta2 )
Ms1 = matrix(c(cos( delta1 ) , 1i / etha_s1 * sin( delta1 ) , 1i * etha_s1 *
sin( delta1) , cos( delta1 )),2,2,byrow=T)
Ms2 = matrix(c(cos( delta2 ) , 1i / etha_s2 * sin( delta2 ) , 1i * etha_s2 *
sin( delta2) , cos( delta2 )) ,2,2,byrow=T)
dum = Ms2 %*% Ms1
Msr <- diag(2)
for (i in 1:N) Msr <- dum %*% Msr
Rs = ( abs( ( etha_sn * ( Msr[1 , 1] - etha_s0 * Msr[ 1 , 2 ] ) - ( Msr[ 2 ,
1 ]
- etha_s0 * Msr[ 2 , 2 ] ) ) / ( etha_sn * ( Msr[ 1 , 1 ] - etha_s0 * Msr[
1 ,
2 ] ) + ( Msr[ 2 , 1 ] - etha_s0 * Msr[2 , 2] ) ) ) )^2
Rs
}
##r0deg <- r75deg <- numeric(1001)
##for (i in 500:1500) r0deg[i]=Rs(i,0,5)
##for (i in 500:1500) r75deg[i]=Rs(i,75*pi/180,5)
##
##oct0 <- read.table('o0deg,dat')
##oct75 <- read.table('o75deg,dat')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug or not? (PR#8977)
I think you are computing your matrix to power N+1 instead of N.
This code seems to work for me:
Rs <- function(lambda, theta, N){
n0 <- 3.66
n1 <- 2.4
n2 <- 1.45
nn <- 1.00
lambda_ref <- 1000
d1 <- lambda_ref / 4 / n1
d2 <- lambda_ref / 4 / n2
theta0 <- asin( nn / n0 * sin( theta ) )
theta1 <- asin( nn / n1 * sin( theta ) )
theta2 <- asin( nn / n2 * sin( theta ) )
etha_s0 <- -n0 * cos( theta0 )
etha_s1 <- n1 * cos( theta1 )
etha_s2 <- n2 * cos( theta2 )
etha_sn <- nn * cos( theta )
delta1 <- 2 * pi / lambda * n1 * d1 * cos( theta1 )
delta2 <- 2 * pi / lambda * n2 * d2 * cos( theta2 )
Ms1 <- matrix( c( cos( delta1 ) , 1i * etha_s1 * sin( delta1 ) ,
1i / etha_s1 * sin( delta1 ) , cos( delta1 ) ), 2 , 2 )
Ms2 <- matrix( c( cos( delta2 ) , 1i * etha_s2 * sin( delta2 ) ,
1i / etha_s2 * sin( delta2 ) , cos( delta2 ) ), 2 , 2 )
Mstmp <- Ms2 %*% Ms1
Msr <- Mstmp
for(i in 1:(N-1)) Msr <- Msr %*% Mstmp
Rs <- ( abs( ( etha_sn * ( Msr[1, 1] - etha_s0 * Msr[1, 2] ) - (
Msr[2 , 1] - etha_s0 * Msr[2, 2] ) ) / ( etha_sn * ( Msr[1, 1] -
etha_s0 * Msr[1, 2] ) + ( Msr[2, 1] - etha_s0 * Msr[2, 2] ) ) ) )^2
return(Rs)
}
lambda_range <- 500:1500
s0 <- sapply(lambda_range, Rs, theta = 0, N = 5)
s75 <- sapply(lambda_range, Rs, theta = 75*pi/180, N = 5)
ref <- read.table("Mathcad2.txt", header=FALSE, col.names=c('wl','a0', 'a75'))
o0deg<-scan("o0deg.dat", "numeric", sep=" ", skip=5)
o75deg<-scan("o75deg.dat", "numeric", sep=" ", skip=5)
o0deg<-o0deg[-1]
o75deg<-o75deg[-1]
pdf(file="comparison.pdf", width=11.8, height=8.3)
par(mar = c(3.5,3.5,4,3.5))
plot(ref$wl,ref$a0,ylim=c(0,
1),type="l",col="1",lty=2,xlab="",ylab="",axes=FALSE, lwd = 1.5)
lines(lambda_range,s0,type="l",col="2", lty=2, lwd = 2)
lines(lambda_range,o0deg,type="l",col="3", lty=2)
lines(ref$wl,ref$a75,type="l",col="1",lty=3, lwd = 1.5)
lines(lambda_range,s75,col="2", lty=3, lwd = 2)
lines(lambda_range,o75deg,col="3", lty=3)
axis(1, at=seq(lambda_min,lambda_max,20))
axis(2)
mtext("wavelength [nm]", side=1, line=2)
mtext("reflection", side=2, line=2)
mtext(paste("bragg mirror, s-polarized: central wavelength ",
lambda_ref," nm, ", N, " pairs of layers", seq=""), side=3, line=2.5,
cex=1.2)
mtext(paste("n0=", n0 (1), "; n1=", n1(1),"; n2=", n2(1),"; n3=",
nn(1)),side=3,line=1.5, cex=0.7)
legend("topleft", c("0A","75A"), lty=2:3)
legend("topright", c("Reference","R", "Octave"), col=1:3, lty=1)
dev.off()
--
Jean R. Lobry([EMAIL PROTECTED])
Laboratoire BBE-CNRS-UMR-5558, Univ. C. Bernard - LYON I,
43 Bd 11/11/1918, F-69622 VILLEURBANNE CEDEX, FRANCE
allo : +33 472 43 12 87 fax: +33 472 43 13 88
http://pbil.univ-lyon1.fr/members/lobry/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] More: Hopefully Final Fix for Bug 8141 (C stack overflow in substituteList)
Hi,
Just in case anyone is interested in bug 8141. With some further
testing, I found and fixed a small bug in my code and simplified it
a bit.
Here is the latest version of the coerce.c routine substituteList
that fixes the C stack overflow problem as documented in Bug 8141.
Comments welcome. If people are satisfied with this version I will
submit a final patch to r-devel sources.
Kevin
/* Work through a list doing substitute on the */
/* elements taking particular care to handle ... */
SEXP attribute_hidden substituteList(SEXP el, SEXP rho)
{
SEXP h, p, n = R_NilValue;
p = R_NilValue;
while (el != R_NilValue) {
if (CAR(el) == R_DotsSymbol) {
if (rho == R_NilValue)
h = R_UnboundValue; /* so there is no
substitution below */
else
h = findVarInFrame3(rho, CAR(el), TRUE);
if (h == R_UnboundValue)
h = lcons(R_DotsSymbol, R_NilValue);
else if (h == R_NilValue || h == R_MissingArg)
h = R_NilValue;
else if (TYPEOF(h) == DOTSXP)
h = substituteList(h, R_NilValue);
else {
error(_("... used in an incorrect context"));
h = R_NilValue;
}
}
else {
h = substitute(CAR(el), rho);
if (isLanguage(el))
h = LCONS(h, R_NilValue);
else
h = CONS(h, R_NilValue);
SET_TAG(h, TAG(el));
}
if (h != R_NilValue) {
if (n == R_NilValue)
PROTECT(n=h);
else
SETCDR(p,h);
while ( CDR(h) != R_NilValue ) h = CDR(h);
p = h;
}
el = CDR(el);
}
if (n != R_NilValue) {
UNPROTECT(1);
}
return n;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] a new way to crash R? (PR#8981)
This is a multi-part message in MIME format. --010500030900050501010804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear R Team, First, thank you for incredibly useful software! Now the bad news: The attached script (or the original version with real data) will reliably crash R on my machine. I am using: R version: either 2.2.1 or 2.3.1 Windows 2000 Professional, Service Pack 4 512 MB of RAM On my machine the script will crash R on line 42 [ probits21 <- lapply(... ]. In both this script and the "real" one, memory.size() indicates that R is about 512 MB just before executing the command that crashes it. In other contexts, R has been able to allocate virtual memory on this computer without any trouble. Thanks again for all your work on R. Regards, Joe Ritter -- Joseph A. Ritter Associate Professor Humphrey Institute of Public Affairs University of Minnesota Minneapolis, MN 55455 U.S.A. 612-625-0442 --010500030900050501010804 Content-Type: text/plain; name="crash.r" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crash.r" x1 <- rnorm(1) x2 <- rnorm(1) x3 <- rnorm(1) x4 <- rnorm(1) x5 <- rnorm(1) x6 <- rnorm(1) x7 <- rnorm(1) x8 <- rnorm(1) y <- round(runif(1)) specs <- list() specs$A <- formula(y~x1+x2+x3+x4+x5+x6+x7+x8) specs$B <- specs$A specs$C <- specs$A specs$D <- specs$A specs$E <- specs$A specs$F <- specs$A specs$H <- specs$A specs$I <- specs$A specs$J <- specs$A probits1 <- lapply(specs, glm, family=binomial(link="probit")) probits2 <- lapply(specs, glm, family=binomial(link="probit")) probits3 <- lapply(specs, glm, family=binomial(link="probit")) probits4 <- lapply(specs, glm, family=binomial(link="probit")) probits5 <- lapply(specs, glm, family=binomial(link="probit")) probits6 <- lapply(specs, glm, family=binomial(link="probit")) probits7 <- lapply(specs, glm, family=binomial(link="probit")) probits8 <- lapply(specs, glm, family=binomial(link="probit")) probits9 <- lapply(specs, glm, family=binomial(link="probit")) probits10 <- lapply(specs, glm, family=binomial(link="probit")) probits11 <- lapply(specs, glm, family=binomial(link="probit")) probits12 <- lapply(specs, glm, family=binomial(link="probit")) probits13 <- lapply(specs, glm, family=binomial(link="probit")) probits14 <- lapply(specs, glm, family=binomial(link="probit")) probits15 <- lapply(specs, glm, family=binomial(link="probit")) probits16 <- lapply(specs, glm, family=binomial(link="probit")) probits17 <- lapply(specs, glm, family=binomial(link="probit")) probits18 <- lapply(specs, glm, family=binomial(link="probit")) probits19 <- lapply(specs, glm, family=binomial(link="probit")) probits20 <- lapply(specs, glm, family=binomial(link="probit")) probits21 <- lapply(specs, glm, family=binomial(link="probit")) probits22 <- lapply(specs, glm, family=binomial(link="probit")) probits23 <- lapply(specs, glm, family=binomial(link="probit")) probits24 <- lapply(specs, glm, family=binomial(link="probit")) probits25 <- lapply(specs, glm, family=binomial(link="probit")) probits26 <- lapply(specs, glm, family=binomial(link="probit")) probits27 <- lapply(specs, glm, family=binomial(link="probit")) probits28 <- lapply(specs, glm, family=binomial(link="probit")) probits29 <- lapply(specs, glm, family=binomial(link="probit")) probits30 <- lapply(specs, glm, family=binomial(link="probit")) probits31 <- lapply(specs, glm, family=binomial(link="probit")) --010500030900050501010804-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug or not? (PR#8977)
Joerg van den Hoff wrote:
>
>> Hi,
>>
>> I am writing this email, because I am not sure if the issue I have
>> discovered is a bug or not.
>>
>> For a few days I have been fiddling around with a small program that
>> calculates the reflectance of multilayer dielectric mirrors (eg. bragg
>> mirrors). It does not really matter what I did, what matters is that I
>> could not do that using R.
>> I had some sample data which I used to test if my R program works
>> correctly (if it fits the data it works). This sample data was for two
>> different incident angles with respect to the normal of the hypothetical
>> bragg mirror (0=B0 and 70=B0). The plots for 0=B0 matched perfectly
>> but t=
>> hose
>> for 70=B0 were quite a bit off. After trying out all sorts of things for
>> several days, I tried the same algorithm in octave (matlab clone, but
>> open source). There, I got a perfect match for both 0=B0 and 70=B0. I
>> alm=
>> ost
>> could not believe it, R must have calculated wrong.
>>
>> The R version I use at home at the moment is 2.2.1 on gentoo linux. I
>> also tried version 2.1.0 at my university (debian stable), both had the
>> same result.
>>
>> I uploaded everything to reproduce this to
>>
>> http://n.ethz.ch/student/homartin/r-vs-octave/
>>
>> There, you can also find the .pdf file of the comparison of the
>> reference, the R output and the one from octave.
>>
>> The calculations are quite complex, nevertheless, I would be very happy
>> to read your reply concerning this problem.
>>
>> Thanks in advance, best Regards,
>> Martin
>>
>>
>
> I get only the r-devel digest, so I could'nt respond the direct way
> (this message will not show up in the correct thread, probably), but:
>
>
> there is nothing wrong with the R results AFAICS: I translated your
> octave script one-to-one to R (see attachment). this produces (within
> floating point prec. (double)) the same results. I propose you go
> through this and your own R-script (which honestly was unreadable to me
> :-)) with browser() or debug() and compare results for Ms1, Ms2, Msr on
> the way to localise the differences in computation.
> if you uncomment the last few lines, source("Rs.R") will give you
> vectors which you can directly compare to the octave results (note that
> the leading 499 zeros are still there, since I mimicked your octave script)
>
> so: really no bug, right?
>
> joerg
NO BUG! I found out what was wrong and it was all my fault!
The etha functions were the problem. They should be etha_sX(thetaX)
where thetaX is a function of theta. I made the etha_sX functions that
way and defined the etha_sX functions to be functions of theta, NOT thetaX.
But when I used these I called them with thetaX instead of only theta.
I would like to apologize for the "bug", I hope this didn't cost you too
much time. Rest assured I feel quite embarrassed now :-?.
I can imagine the script was hard to read, I am new to R and sometimes
it is still hard for me to get things done at all.
Thanks for your time and the great product of course ;-).
Best regards,
Martin
>
>
>
>
> Rs <- function (lambda, theta, N) {
>
>n0 = 3.66
>n1 = 2.4
>n2 = 1.45
>nn = 1.00
>
>lambda_ref = 1000
>lambda_min = 500
>lambda_max = 1500
>increment = 5
>ymin = 0
>ymax = 1
>
>d1 = lambda_ref / 4 / n1
>d2 = lambda_ref / 4 / n2
>
>theta0 = asin( nn / n0 * sin( theta ) )
>theta1 = asin( nn / n1 * sin( theta ) )
>theta2 = asin( nn / n2 * sin( theta ) )
>
>etha_s0 = -n0 * cos( theta0 )
>etha_s1 = n1 * cos( theta1 )
>etha_s2 = n2 * cos( theta2 )
>etha_sn = nn * cos( theta )
>
>delta1 = 2 * pi / lambda * n1 * d1 * cos( theta1 )
>delta2 = 2 * pi / lambda * n2 * d2 * cos( theta2 )
>
>Ms1 = matrix(c(cos( delta1 ) , 1i / etha_s1 * sin( delta1 ) , 1i * etha_s1
> * sin( delta1) , cos( delta1 )),2,2,byrow=T)
>Ms2 = matrix(c(cos( delta2 ) , 1i / etha_s2 * sin( delta2 ) , 1i * etha_s2
> * sin( delta2) , cos( delta2 )) ,2,2,byrow=T)
>
>dum = Ms2 %*% Ms1
>Msr <- diag(2)
>for (i in 1:N) Msr <- dum %*% Msr
>
>Rs = ( abs( ( etha_sn * ( Msr[1 , 1] - etha_s0 * Msr[ 1 , 2 ] ) - ( Msr[ 2
> , 1 ]
>- etha_s0 * Msr[ 2 , 2 ] ) ) / ( etha_sn * ( Msr[ 1 , 1 ] - etha_s0 *
> Msr[ 1 ,
> 2 ] ) + ( Msr[ 2 , 1 ] - etha_s0 * Msr[2 , 2] ) ) ) )^2
>Rs
> }
>
> ##r0deg <- r75deg <- numeric(1001)
> ##for (i in 500:1500) r0deg[i]=Rs(i,0,5)
> ##for (i in 500:1500) r75deg[i]=Rs(i,75*pi/180,5)
> ##
> ##oct0 <- read.table('o0deg,dat')
> ##oct75 <- read.table('o75deg,dat')
--
Sometimes I wonder if I'm in my right mind. Then it passes off and I'm
as intelligent as ever.
-- Samuel Beckett, "Endgame"
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/l
[Rd] package compile error on RHEL x86_64
I am unable to install the gmp package on an x86_64 (Xeon) machine. I have had the same problem with other packages (eg. MCMCpack) as well. I am running Red Hat Enterprise Linux 4.1. I get the following error: g++ -shared -L/usr/local/lib64 -o gmp.so biginteger.o biginteger_operator.o bigintegerR.o bigrational.o bigrational_operator.o bigrationalR.o factor.o -L/usr/local/lib/ -lgmp /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a: could not read symbols: Bad value However, I have found that if I run "R CMD SHLIB" twice in the src/ directory, once to build the .o files, and once to link, I can build the shared library. If I run it on the .o files instead of the .cc files it uses gcc instead of g++. This appears to be the change that allows the lib to build. "-fPIC" seems to have nothing to do with it. So my question is: How do I get "R CMD INSTALL" to link with gcc instead of g++? I have tried adding "LINK.cc = $(LINK.c)" to the top of src/Makevars.in and then running "R CMD check" in the top dir of the package, but it uses g++ anyway. Any other fix or workaround suggestions would be appreciated as well. A commandline transcript follows below. Thanks, Dan $ sudo R CMD INSTALL gmp_0.3-4.tar.gz * Installing *source* package 'gmp' ... creating cache ./config.cache checking for __gmpz_ui_sub in -lgmp... yes updating cache ./config.cache creating ./config.status creating src/Makevars ** libs g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c biginteger.cc -o biginteger.o g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c biginteger_operator.cc -o biginteger_operator.o g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c bigintegerR.cc -o bigintegerR.o g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c bigrational.cc -o bigrational.o g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c bigrational_operator.cc -o bigrational_operator.o g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c bigrationalR.cc -o bigrationalR.o g++ -I/usr/lib/R/include -I/usr/local/include/ -Wno-conversion -I/usr/local/include -fPIC -O2 -g -c factor.cc -o factor.o g++ -shared -L/usr/local/lib64 -o gmp.so biginteger.o biginteger_operator.o bigintegerR.o bigrational.o bigrational_operator.o bigrationalR.o factor.o -L/usr/local/lib/ -lgmp /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [gmp.so] Error 1 ERROR: compilation failed for package 'gmp' $ tar xzf gmp_0.3-4.tar.gz $ cd gmp/src $ R CMD SHLIB *.cc g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c biginteger.cc -o biginteger.o g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c biginteger_operator.cc -o biginteger_operator.o g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c bigintegerR.cc -o bigintegerR.o g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c bigrational.cc -o bigrational.o g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c bigrational_operator.cc -o bigrational_operator.o g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c bigrationalR.cc -o bigrationalR.o g++ -I/usr/lib/R/include -I/usr/local/include -fPIC -O2 -g -c factor.cc -o factor.o g++ -shared -L/usr/local/lib64 -o biginteger.so biginteger.o biginteger_operator.o bigintegerR.o bigrational.o bigrational_operator.o bigrationalR.o factor.o /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [biginteger.so] Error 1 $ R CMD SHLIB *.o gcc -shared -L/usr/local/lib64 -o biginteger.so biginteger.o biginteger_operator.o bigintegerR.o bigrational.o bigrational_operator.o bigrationalR.o factor.o $ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] loading library from network share (PR#8982)
Full_Name: roy kuraisa
Version: 2.2.1
OS: Windows XP SP2
Submission from: (NULL) (155.91.28.232)
When loading a library from network share drive (e.g., \\nnn\f1\f2\p1), when
First.lib is called, the libray name contains "/" instead of "\" resulting in an
invalid Windows filepath.
Here's an example:
>From R,
> library(foo.lib="kodak\\research_genetics\\rlibs");
Within First.lib,
.First.lib <-function(lib, pkg)
{
cat("lib name ",lib,"\n")
}
produces the output
lib name //kodak/research_genetics/rlibs
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package naming best practices
R-devel, I'm in the process of choosing a name for a new package. I've already decided that the name will have two parts, 'portfolio' and 'sim', but can't decide between 'portfolioSim' and 'portfolio.sim'. Is there any good reason to choose one over the other? Thanks in advance, Jeff -- Jeff Enos Kane Capital Management [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package naming best practices
Only personal preferences, although you might argue that the two naming schemes hints at a package using either S3 or S4 methodology. Some packages also has a all cap naming scheme like PortfolioSim. But why not follow part of the R community and choose an incomprehensible abbreviation like Ps614 (where 614 of course refer to the date that you posted this question on R-devel) or try to appeal to the script kiddies by something like P0rS1mRul3z /Kasper On Jun 14, 2006, at 3:03 PM, Jeff Enos wrote: > R-devel, > > I'm in the process of choosing a name for a new package. I've already > decided that the name will have two parts, 'portfolio' and 'sim', but > can't decide between 'portfolioSim' and 'portfolio.sim'. Is there any > good reason to choose one over the other? > > Thanks in advance, > > Jeff > > > -- > Jeff Enos > Kane Capital Management > [EMAIL PROTECTED] > > __ > 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
