[Rd] Fwd: AR(2) modelling
My email does not seem to receive any attention on R-help, so I
forward it on R-devel if someone has already faced the "problem".
Thanks in advance
Christophe
Début du message réexpédié :
> De : Christophe Dutang
> Date : 13 novembre 2009 23:30:14 HNEC
> À : r-h...@r-project.org
> Objet : AR(2) modelling
>
Hi useRs,
I'm trying to fit a basic AR(2) model with the 'ar' function. And when
I try to check the value of the coefficients, I could not find the
same value as the 'ar' function.
Here is my example:
myserie <- c(212, 205, 210, 213, 217, 222, 216, 218, 220, 212, 215, 236)
#plot(myserie, type="l")
myserieminus0 <- tail(myserie, -2)
myserieminus1 <- tail(head(myserie, -1), -1)
myserieminus2 <- head(myserie, -2)
###Yule Walker equations
r1 <- cor(myserieminus0, myserieminus1)
r2 <- cor(myserieminus0, myserieminus2)
#method 1
phihat1 <- r1*(1-r2)/(1-r1^2)
phihat2 <- (r2-r1^2)/(1-r1^2)
#method 2
bigR <- cbind(c(1, r1), c(r1, 1))
smallr <- c(r1, r2)
ressolve <- solve(bigR, smallr)
resaryw <- ar(myserie, method="yule-walker", order.max=2, aic=FALSE)
cat("\t\tmanual YW 1\t\tmanual YW 2\t\tar YW\n")
cat("first coef", phihat1,"\t", ressolve[1],"\t\t", resaryw$ar[1], "\n")
cat("first coef", phihat2,"\t", ressolve[2],"\t", resaryw$ar[2], "\n\n")
> manual YW 1 manual YW 2 ar YW
> first coef 0.2941808 0.2941808 0.1869641
> first coef -0.1316839 -0.1316839 -0.1038001
I do not understand why the "yule-walker" does not solve exactly the
Yule-Walker equations. A reference can be found here
http://www-stat.wharton.upenn.edu/~steele/Courses/956/ResourceDetails/YWSourceFiles/YW-Eshel.pdf
.
In the R source code (/src/library/stats/R), the file ar.R
contains the ar.yw.default function implements the function. For
univariate case (line 130), r_eureka function is used, which seems to
be implemented in the eureka.f function.
subroutine eureka (lr,r,g,f,var,a)
c
c solves Toeplitz matrix equation toep(r)f=g(1+.)
c by Levinson's algorithm
c a is a workspace of size lr, the number
c of equations
c
is supposed to implement the Yule-Walker equations...
Any help is welcome.
Just to be sure, I can do something I try to reconcile the ordinary
least square methods. And it works!
Christophe
PS : OLS code
###Ordinary Least Square
reslm <- lm(myserieminus0 ~ myserieminus1 + myserieminus2)
#summary(reslm)
coef1ols <- reslm$coefficients["myserieminus1"]
coef2ols <- reslm$coefficients["myserieminus2"]
resarols <- ar(myserie, method="ols", order.max=2, aic=FALSE)
cat("\t\tmanual ols\t\tar ols\n")
cat("first coef", coef1ols,"\t", resarols$ar[1], "\n")
cat("first coef", coef2ols,"\t", resarols$ar[2], "\n\n")
--
Christophe Dutang
Ph.D. student at ISFA, Lyon, France
website: http://dutangc.free.fr
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Add links to NEWS and CHANGES on help.start() page
On 13/11/2009 3:37 AM, Henrik Bengtsson wrote:
Hi,
right now it is actually a bit tricky to locate and view the NEWS and
the CHANGES files, especially if you are a beginning and don't even
know that you are supposed to look for them.
I'd like to recommend that links to (local) NEWS and CHANGES are added
to the help.start() overview pages. help("NEWS")/help("CHANGE LOG")
and help("CHANGES") could display/refer to them as well.
I've done this now in R-devel.
(I thought I'd written about this yesterday, but I don't see my post, so
maybe it never made it out. If it did, the text below may be a repeat.)
It would look better if the files were translated into HTML. Anyone
want to write a news2HTML function?
I haven't done any of the package-specific suggestions yet; they're
slightly trickier because packages are inconsistent in how they present
news. For those, I think we should use the news() function, but it
requires the news2HTML translation to give nice looking output.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] file.rename overwrites existing target (PR#14065)
Full_Name: Jens Oehlschlägel
Version: 2.10.0
OS: Windows XP Professional
Submission from: (NULL) (85.181.158.112)
file.rename() will successfully rename file a to b - even if b exists already.
Though the documentation does not state what file.rename() will do in this
case,
I guess the expected behaviour is to fail and return FALSE.
Kind regards
Jens Oehlschlägel
> cat("a\n", file="a.txt")
> cat("b\n", file="b.txt")
> file.rename("a.txt","b.txt")
[1] TRUE
> readLines("b.txt")
[1] "a"
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 10.0
year 2009
month 10
day26
svn rev50208
language R
version.string R version 2.10.0 (2009-10-26)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file.rename overwrites existing target (PR#14065)
On 15/11/09 16:35 PM, "jo...@web.de" wrote: > Full_Name: Jens Oehlschlägel > Version: 2.10.0 > OS: Windows XP Professional > Submission from: (NULL) (85.181.158.112) > > > file.rename() will successfully rename file a to b - even if b exists already. > Though the documentation does not state what file.rename() will do in this > case, > I guess the expected behaviour is to fail and return FALSE. The *expected* behaviour is to overwrite the old file. Your expectation seems to be different, but overwriting or deleting the old file has been the behaviour for ever (= since 1970s). This is how MacOS defines the behaviour of the system command 'rename': RENAME(2) BSD System Calls Manual NAME rename -- change the name of a file ... DESCRIPTION The rename() system call causes the link named old to be renamed as new. If new exists, it is first removed. The behaviour is the same in all posixy systems. Sebsinble systems like R follow the documented standard behaviour. Why would you expect that 'file.rename' fails if the 'new' file exists? The unix command 'mv' (move) that does the 'rename' has a switch to overturn the standard 'rename' system call, and prompt for the removal of the 'new' file. However, this switch is usually not the default in unixy systems, unless defined so in the shell start up script of the user. Cheers, Jari Oksanen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: AR(2) modelling
As you are sure of the accuracy of your code, why don't you tell me where is my mistake? Le 15 nov. 2009 à 12:03, Prof Brian Ripley a écrit : -- 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 -- Christophe Dutang Ph.D. student at ISFA, Lyon, France website: http://dutangc.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file.rename overwrites existing target (PR#14065)
On Sun, Nov 15, 2009 at 9:58 AM, Jari Oksanen wrote: > On 15/11/09 16:35 PM, "jo...@web.de" wrote: > >> Full_Name: Jens Oehlschlägel >> Version: 2.10.0 >> OS: Windows XP Professional >> Submission from: (NULL) (85.181.158.112) >> >> >> file.rename() will successfully rename file a to b - even if b exists >> already. >> Though the documentation does not state what file.rename() will do in this >> case, >> I guess the expected behaviour is to fail and return FALSE. > > The *expected* behaviour is to overwrite the old file. Your expectation > seems to be different, but overwriting or deleting the old file has been the On UNIX the expected behavior would be to overwrite but on Windows the rename command does not overwrite silently but fails so I think his expectation is in line with how Windows works at the command line level. It might be worthwhile to have an overwrite= argument on file.rename to control this. If it defaulted to TRUE then the expectation would be clear regardless of platform. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: AR(2) modelling
On Sun, 15 Nov 2009, Christophe Dutang wrote: As you are sure of the accuracy of your code, why don't you tell me where is my mistake? Because your supervisor is paid to do that. Le 15 nov. 2009 à 12:03, Prof Brian Ripley a écrit : -- 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 -- Christophe Dutang Ph.D. student at ISFA, Lyon, France website: http://dutangc.free.fr -- 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] Fwd: AR(2) modelling
Try this: debug(stats:::ar.yw.default) and then run the ar function to step through the ar code so you can see the results line by line and understand what it is doing at a very detailed level. On Sun, Nov 15, 2009 at 10:06 AM, Christophe Dutang wrote: > As you are sure of the accuracy of your code, why don't you tell me where is > my mistake? > > Le 15 nov. 2009 à 12:03, Prof Brian Ripley a écrit : > >> >> >> -- >> 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, UK Fax: +44 1865 272595 > > -- > Christophe Dutang > Ph.D. student at ISFA, Lyon, France > website: http://dutangc.free.fr > > __ > 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] Fwd: AR(2) modelling
Thanks Gabor, My mistake was I used the 'cor' function rather than the function 'acf' with "correlation" argument. Christophe Le 15 nov. 2009 à 18:13, Gabor Grothendieck a écrit : Try this: debug(stats:::ar.yw.default) and then run the ar function to step through the ar code so you can see the results line by line and understand what it is doing at a very detailed level. On Sun, Nov 15, 2009 at 10:06 AM, Christophe Dutang wrote: As you are sure of the accuracy of your code, why don't you tell me where is my mistake? Le 15 nov. 2009 à 12:03, Prof Brian Ripley a écrit : -- 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 -- Christophe Dutang Ph.D. student at ISFA, Lyon, France website: http://dutangc.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Christophe Dutang Ph.D. student at ISFA, Lyon, France website: http://dutangc.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem building package for R 2.10.0 on Mac OS X
Hi
I have submitted a package (rioja) to CRAN. It checks OK for all R versions
and OS's except r-release-macosx-ix86 where it fails when checking the
examples. Specifically, it fails because R can't find the package vegan which
is needed in a function. Here is the snippet from the check results:
### Begin snippet
checking examples ... ERROR
Running examples in 'rioja-Ex.R' failed.
The error most likely occurred in:
> ### * chclust
>
> flush(stderr()); flush(stdout())
>
> ### Name: chclust
> ### Title: Constrained hierarchical clustering
> ### Aliases: chclust plot.chclust bstick.chclust
> ### Keywords: cluster hplot
>
> ### ** Examples
>
> data(RLGH)
> diss <- dist(sqrt(RLGH$spec/100)^2)
> clust <- chclust(diss)
> bstick.chclust(clust, 10)
Loading required package: vegan
Warning in library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE, :
there is no package called 'vegan'
Error in bstick.chclust(clust, 10) : could not find function "bstick"
Execution halted
### End snippet
The function bstick.chclust listed below loads the package vegan which contains
bstick.default.
bstick.chclust <- function(n, ng=10, plot=TRUE, ...) {
if (n$method != "coniss")
stop("bstick cannot display conslink results")
require(vegan)
disp <- rev(n$height)
tot.disp <- disp[1]
disp <- abs(diff(disp))
nobj <- length(n$height)
bs <- bstick(nobj, tot.disp)
yR <- range(disp[1:(ng-1)], bs[1:(ng-1)])
if (plot) {
plot(2:ng, disp[1:(ng-1)], type="o", ylim=yR, ylab="Sum of Squares", xlab
= "Number of groups")
lines(2:ng, bs[1:(ng-1)], col="red", type="o")
}
invisible(data.frame(nGroups = 2:(ng), dispersion=disp[1:(ng-1)], bstick =
bs[1:(ng-1)]))
}
vegan is included as a Suggests in the DESCRIPTION file and the package checks
OK on r-oldrel-macosx-ix86. It also checks OK with R 2.10.0 on OS X on my own
Mac. My code could be improved and I should probably trap the warning issued
by require, but I don't understand why vegan is not loading when checking on
CRAN. Any help will be gratefully received!
Many thanks, Steve
Steve Juggins
School of Geography, Politics & Sociology
Newcastle University Tel: +44 (0)191 222 8799
Newcastle upon TyneFax: +44 (0)191 222 5421
NE1 7RU, UKMobile: +44 (0)7740054905
http://www.staff.ncl.ac.uk/staff/stephen.juggins/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Segmentation faults on SEXP conversion
Hello -
I am making a first attempt at writing a simple C++ routine to print
out R objects (this is a simple proof-of-concept as part of a larger
package development). The relevant C++ routine is as follows:
void Rwrite(SEXP fd, SEXP msg) {
int *ofd = INTEGER(fd);
const char * omsg = CHAR(asChar(msg));
printf("[%i] %s",*ofd,omsg);
}
And the corresponding interface in R is as follows:
ptest <- function()
{
cfd <- as.integer(2);
cmsg <- as.character("Hi");
storage.mode(cfd) <- "integer";
storage.mode(cmsg) <- "character";
.Call("Rwrite",
fd=cfd,
msg=cmsg,
PACKAGE="forkex"
);
}
Upon running the above code as a call to `ptest()`, I receive a
segmentation fault. Building the package as `R CMD check
--use-valgrind ...` provides the following memcheck output:
> ptest();
==12591== Invalid read of size 1
==12591==at 0x4D04209: SET_SYMVALUE (in /usr/lib64/R/lib/libR.so)
==12591==by 0x4D01E51: Rf_ReplIteration (in /usr/lib64/R/lib/libR.so)
==12591==by 0x4D020B7: (within /usr/lib64/R/lib/libR.so)
==12591==by 0x4D027CF: run_Rmainloop (in /usr/lib64/R/lib/libR.so)
==12591==by 0x40083A: main (in /usr/lib64/R/bin/exec/R)
==12591== Address 0x9 is not stack'd, malloc'd or (recently) free'd
[2] Hi
*** caught segfault ***
address 0x9, cause 'memory not mapped'
aborting ...
==12591==
==12591== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 18 from 1)
==12591== malloc/free: in use at exit: 22,564,238 bytes in 10,614 blocks.
==12591== malloc/free: 29,096 allocs, 18,482 frees, 44,702,479 bytes allocated.
==12591== For counts of detected errors, rerun with: -v
==12591== searching for pointers to 10,614 not-freed blocks.
==12591== checked 19,665,464 bytes.
==12591==
==12591== LEAK SUMMARY:
==12591==definitely lost: 0 bytes in 0 blocks.
==12591== possibly lost: 0 bytes in 0 blocks.
==12591==still reachable: 22,564,238 bytes in 10,614 blocks.
==12591== suppressed: 0 bytes in 0 blocks.
==12591== Rerun with --leak-check=full to see details of leaked memory.
The same segmentation fault occurs whether I try passing either the
`int` or `character` or both (as in the above). I have not tried other
types. However, I have attempted various type conversions in the
Rdefines.h header, but cannot avoid the segmentation fault. This is
the only code in the proof-of-concept pacakage (aside from useDynLoad
related registration structures and the R_init_??? call).
I have a feeling it is something simple, but I am not well versed in R
package development at this point. Please let me know if other
information is helpful.
I am running Linux 2.6.27.30-170.2.82.fc10.x86_64 with R 2.10.0.
Thanks!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13999) Extreme values of non-central chisq (was Accuracy)
You crossed the value ncp = 80: the help page warned you of cancellation there, and at p = 1 - 1e-12, that is what you got (badly). On Sun, 11 Oct 2009, witkov...@savba.sk wrote: Full_Name: Viktor Witkovsky Version: 2.9.2 OS: Windows XP Submission from: (NULL) (78.98.89.227) Hello, I have found strange behavior of the function qchisq (the non-central qchisq is based on inversion of pchisq, which is further based on pgamma). The function gives wrong results without any warning. For example: qchisq(1e-12,1,8.94^2,lower.tail=FALSE) gives 255.1840972465858 (notice that here the correct value should be 255.1841334848075), but qchisq(1e-12,1,8.95^2,lower.tail=FALSE) gives 1249.681320136836 Here, the correct value should be 255.5037231613135. So, it seems that qchisq is inaccurate for small probability values and larger non/centrality parameter. Actually, for probability values near 1, and it does say so in the documentation. But see qchisq(1e-12, 1, 81, lower.tail=FALSE) [1] 1258.412 qchisq(1-1e-12, 1, 81) [1] 257.1488 which I suggest gives you a workaround -- we'll look into giving a warning from the code. I am using the precompiled binary version of R, under Windows XP. _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 9.2 year 2009 month 08 day24 svn rev49384 language R version.string R version 2.9.2 (2009-08-24) __ 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] Problem building package for R 2.10.0 on Mac OS X
Please ask such questions on R-sig-mac, or directly to the Mac package
builder (Simon Urbanek).
As you will see from
http://cran.r-project.org/web/checks/check_summary.html
at least 150 packages are in the same boat (not building because
dependencies are missing), so something has gone wrong on the build
machine. There seem to be results for 'vegan', but they are for a
pre-release (2.10.0 alpha), not the released version.
Perhaps related, there have been no R-patched builds on
r.research.att.com for 'leopard' (the main R build for R 2.10.0) since
Nov 4.
Simon has been travelling, and will no doubt get to this when he has
time. Meanwhile, Mac users can fairly easily build packages from the
sources (provided they have installed Xcode), so this is not something
to fret about.
One point specific to Mac is that the distributed packages are
tri-architecture (i386, x86_64, ppc) and so need to work on all three
archs to get distributed (at least in principle). There have been
quite a few packages (including earlier versions of yours) that failed
on 64-bit platforms.
On Sun, 15 Nov 2009, Stephen Juggins wrote:
Hi
I have submitted a package (rioja) to CRAN. It checks OK for all R versions
and OS's except r-release-macosx-ix86 where it fails when checking the
examples. Specifically, it fails because R can't find the package vegan which
is needed in a function. Here is the snippet from the check results:
### Begin snippet
checking examples ... ERROR
Running examples in 'rioja-Ex.R' failed.
The error most likely occurred in:
### * chclust
flush(stderr()); flush(stdout())
### Name: chclust
### Title: Constrained hierarchical clustering
### Aliases: chclust plot.chclust bstick.chclust
### Keywords: cluster hplot
### ** Examples
data(RLGH)
diss <- dist(sqrt(RLGH$spec/100)^2)
clust <- chclust(diss)
bstick.chclust(clust, 10)
Loading required package: vegan
Warning in library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE, :
there is no package called 'vegan'
Error in bstick.chclust(clust, 10) : could not find function "bstick"
Execution halted
### End snippet
The function bstick.chclust listed below loads the package vegan which contains
bstick.default.
bstick.chclust <- function(n, ng=10, plot=TRUE, ...) {
if (n$method != "coniss")
stop("bstick cannot display conslink results")
require(vegan)
disp <- rev(n$height)
tot.disp <- disp[1]
disp <- abs(diff(disp))
nobj <- length(n$height)
bs <- bstick(nobj, tot.disp)
yR <- range(disp[1:(ng-1)], bs[1:(ng-1)])
if (plot) {
plot(2:ng, disp[1:(ng-1)], type="o", ylim=yR, ylab="Sum of Squares", xlab =
"Number of groups")
lines(2:ng, bs[1:(ng-1)], col="red", type="o")
}
invisible(data.frame(nGroups = 2:(ng), dispersion=disp[1:(ng-1)], bstick =
bs[1:(ng-1)]))
}
vegan is included as a Suggests in the DESCRIPTION file and the
package checks OK on r-oldrel-macosx-ix86. It also checks OK with R
2.10.0 on OS X on my own Mac. My code could be improved and I
should probably trap the warning issued by require, but I don't
understand why vegan is not loading when checking on CRAN. Any help
will be gratefully received!
Many thanks, Steve
Steve Juggins
School of Geography, Politics & Sociology
Newcastle University Tel: +44 (0)191 222 8799
Newcastle upon TyneFax: +44 (0)191 222 5421
NE1 7RU, UKMobile: +44 (0)7740054905
http://www.staff.ncl.ac.uk/staff/stephen.juggins/
__
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] Segmentation faults on SEXP conversion
On 15/11/2009 1:41 PM, nabble.30.miller_2...@spamgourmet.com wrote:
Hello -
I am making a first attempt at writing a simple C++ routine to print
out R objects (this is a simple proof-of-concept as part of a larger
package development). The relevant C++ routine is as follows:
void Rwrite(SEXP fd, SEXP msg) {
int *ofd = INTEGER(fd);
const char * omsg = CHAR(asChar(msg));
The "character" type in R corresponds to STRSXP in C, which is a vector
of CHARSXPs. So you need an extra step to get to the C string:
const char * omsg = CHAR(STRING_ELT(msg, 0));
Duncan Murdoch
printf("[%i] %s",*ofd,omsg);
}
And the corresponding interface in R is as follows:
ptest <- function()
{
cfd <- as.integer(2);
cmsg <- as.character("Hi");
storage.mode(cfd) <- "integer";
storage.mode(cmsg) <- "character";
.Call("Rwrite",
fd=cfd,
msg=cmsg,
PACKAGE="forkex"
);
}
Upon running the above code as a call to `ptest()`, I receive a
segmentation fault. Building the package as `R CMD check
--use-valgrind ...` provides the following memcheck output:
ptest();
==12591== Invalid read of size 1
==12591==at 0x4D04209: SET_SYMVALUE (in /usr/lib64/R/lib/libR.so)
==12591==by 0x4D01E51: Rf_ReplIteration (in /usr/lib64/R/lib/libR.so)
==12591==by 0x4D020B7: (within /usr/lib64/R/lib/libR.so)
==12591==by 0x4D027CF: run_Rmainloop (in /usr/lib64/R/lib/libR.so)
==12591==by 0x40083A: main (in /usr/lib64/R/bin/exec/R)
==12591== Address 0x9 is not stack'd, malloc'd or (recently) free'd
[2] Hi
*** caught segfault ***
address 0x9, cause 'memory not mapped'
aborting ...
==12591==
==12591== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 18 from 1)
==12591== malloc/free: in use at exit: 22,564,238 bytes in 10,614 blocks.
==12591== malloc/free: 29,096 allocs, 18,482 frees, 44,702,479 bytes allocated.
==12591== For counts of detected errors, rerun with: -v
==12591== searching for pointers to 10,614 not-freed blocks.
==12591== checked 19,665,464 bytes.
==12591==
==12591== LEAK SUMMARY:
==12591==definitely lost: 0 bytes in 0 blocks.
==12591== possibly lost: 0 bytes in 0 blocks.
==12591==still reachable: 22,564,238 bytes in 10,614 blocks.
==12591== suppressed: 0 bytes in 0 blocks.
==12591== Rerun with --leak-check=full to see details of leaked memory.
The same segmentation fault occurs whether I try passing either the
`int` or `character` or both (as in the above). I have not tried other
types. However, I have attempted various type conversions in the
Rdefines.h header, but cannot avoid the segmentation fault. This is
the only code in the proof-of-concept pacakage (aside from useDynLoad
related registration structures and the R_init_??? call).
I have a feeling it is something simple, but I am not well versed in R
package development at this point. Please let me know if other
information is helpful.
I am running Linux 2.6.27.30-170.2.82.fc10.x86_64 with R 2.10.0.
Thanks!
__
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] file.rename overwrites existing target (PR#14065)
Thanks, An overwrite flag would be great. Would make it cristal clear what the expected behaviour is. Agree that unix behaviour should in case of doubt have priority - in this case: documentation would help windows users. Regards Jens __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] OCaml-R and xts works!
Hi. I've managed to make a *very* simple wrapper around the xts library for R into OCaml. (Need to be downloaded from CRAN for OCaml users, but I expect other wrapping to be fairly similar...). The good, good, good thing (from my humble point of view) is that all loading is done statically: Loading the R interpreter is done statically. Loading the xts library is done statically... etc... See below. Hopefully, one may one day consider R to be a statically-typed, type-inferred, compiled, statistical language, with Lwt-style multithreading. :) yziq...@seldon:~/git/ocamlr-xts$ ocamlbuild xts.cmo Finished, 1 target (0 cached) in 00:00:00. + ocamlfind ocamlc -c -package R.interpreter -o xts.cmo xts.ml File "xts.ml", line 37, characters 4-9: Warning P: this pattern-matching is not exhaustive. Here is an example of a value that is not matched: [] Finished, 2 targets (0 cached) in 00:00:00. yziq...@seldon:~/git/ocamlr-xts$ cd _build/; ocaml-batteries Objective Caml version 3.11.1 _ | | | | [| + | | Batteries Included - | |___|_|___| _ | | | | | -Type '#help;;' | | + |] |___|_|___| # #require "R.interpreter";; R interpreter statically loaded. # #load "xts.cmo";; xts library statically loaded. Le chargement a nécessité le package : xts Le chargement a nécessité le package : zoo Attachement du package : 'zoo' The following object(s) are masked from package:base : as.Date.numeric xts now requires a valid TZ variable to be set no TZ var is set, setting to TZ=GMT Printing stuff at "compile-time"... That's ugly, I know... # R.sexptype Xts.xts;; - : R.sexptype = R.PromSxp So we indeed have a function. # let x = R.eval [Xts.xts];; val x : R.sexp = We construct a dummy time series... # R.sexptype x;; - : R.sexptype = R.RealSxp # Cool... The xts.ml code is essentially: (* You describe the library, its name and symbols. *) module Description : R.LibraryDescription = struct let name = "xts" let symbols = ["xts"] end (* You instatiate the library per se. *) module Library : R.Library = OCamlR.Require (Description) (* Then you name the sexps in the same order as the symbols above. *) let [xts] = Library.root The OCamlR wrapper and the xts binding are not finished at all, but an OCaml-R Debian package for 64 bits is available at http://yziquel.homelinux.org/topos/debian-ocamlr.html http://yziquel.homelinux.org/topos/debian-repository.html http://yziquel.homelinux.org/debian/pool/main/o/ocaml-r/ when my laptop's up, wifi working, et ceterae. All in french for now, and documentation is not up to date... That will come. OCaml-R itself is hosted here: https://gna.org/projects/ocaml-r/ -- Guillaume Yziquel http://yziquel.homelinux.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segmentation faults on SEXP conversion
nabble.30.miller_2...@spamgourmet.com wrote:
> On Sun, Nov 15, 2009 at 2:52 PM, Duncan Murdoch - murd...@stats.uwo.ca
> <+nabble+miller_2555+1412c7fca2.murdoch#stats.uwo...@spamgourmet.com>
> wrote:
>> On 15/11/2009 1:41 PM, nabble.30.miller_2...@spamgourmet.com wrote:
>> The "character" type in R corresponds to STRSXP in C, which is a vector of
>> CHARSXPs. So you need an extra step to get to the C string:
>>
>> const char * omsg = CHAR(STRING_ELT(msg, 0));
>>
>> Duncan Murdoch
>>
>
> Thank you for the suggestion. I have replaced the code as suggested,
> but I had attempted this conversion earlier. Unfortunately, I still
> receive the same segmentation fault (and backtrace). The underlying
> problem no longer appears to relate to type conversion. The following
> code represents the entirety of the extension's R and C code (and
> NAMESPACE file), and still causes the segmentation fault:
>
> NAMESPACE:
> ---
> useDynLib("tstlib")
> export( "ptest" )
>
>
> ptest.R:
> ---
> ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
>
>
> ptest.c:
> ---
> #include
> void Rwrite() { printf("[%i] %s",12,"Hi"); }
>
>
> ptest.R:
> ---
> ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
>
>
> zzz.R:
> ---
> .onLoad <- function(libname, pkgname)
> {
> }
> .onUnload <- function(libpath) {
> library.dynam.unload("forkex", libpath)
> }
>
>
> This is just about the most simple example I can think of, and don't
> really know why it would segfault (if I change the interface in
> ptest.R above from .Call to .C, no segfault occurs).
And that is your clue.
C routines that are invoked via .Call() _must_
return a SEXP object. Your routine (Rwrite)
has a return type of void. Since you use .Call(),
takes the return value from the stack and it is garbage.
Seg fault ensues.
Declare your Rwrite() routine to return a SEXP
and have it return the symbol R_NilValue, i.e.
SEXP Rwrite() { printf("[%i] %s",12,"Hi"); return(R_NilValue); }
and you can use .Call()
D.
D.
> The following is
> the output from `R CMD SHLIB ptest.c`:
>
> gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c
> ptest.c -o ptest.o
> gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o ptest.so ./ptest.o
> -L/usr/lib64/R/lib -lR
>
> __
> 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] Segmentation faults on SEXP conversion
On 15/11/2009 8:25 PM, nabble.30.miller_2...@spamgourmet.com wrote:
On Sun, Nov 15, 2009 at 2:52 PM, Duncan Murdoch -
nabble.30.miller_2...@spamgourmet.com
<>
wrote:
On 15/11/2009 1:41 PM, nabble.30.miller_2...@spamgourmet.com wrote:
The "character" type in R corresponds to STRSXP in C, which is a vector of
CHARSXPs. So you need an extra step to get to the C string:
const char * omsg = CHAR(STRING_ELT(msg, 0));
Duncan Murdoch
Thank you for the suggestion. I have replaced the code as suggested,
but I had attempted this conversion earlier. Unfortunately, I still
receive the same segmentation fault (and backtrace). The underlying
problem no longer appears to relate to type conversion. The following
code represents the entirety of the extension's R and C code (and
NAMESPACE file), and still causes the segmentation fault:
NAMESPACE:
---
useDynLib("tstlib")
export( "ptest" )
ptest.R:
---
ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
ptest.c:
---
#include
void Rwrite() { printf("[%i] %s",12,"Hi"); }
I forget if you said which system you're working on, but it may be that
you don't have an open file handle for printf to use. Use Rprintf
instead and things should be fine.
Duncan Murdoch
ptest.R:
---
ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
zzz.R:
---
.onLoad <- function(libname, pkgname)
{
}
.onUnload <- function(libpath) {
library.dynam.unload("forkex", libpath)
}
This is just about the most simple example I can think of, and don't
really know why it would segfault (if I change the interface in
ptest.R above from .Call to .C, no segfault occurs). The following is
the output from `R CMD SHLIB ptest.c`:
gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c
ptest.c -o ptest.o
gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o ptest.so ./ptest.o
-L/usr/lib64/R/lib -lR
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segmentation faults on SEXP conversion
On Sun, Nov 15, 2009 at 2:52 PM, Duncan Murdoch - murd...@stats.uwo.ca
<+nabble+miller_2555+1412c7fca2.murdoch#stats.uwo...@spamgourmet.com>
wrote:
> On 15/11/2009 1:41 PM, nabble.30.miller_2...@spamgourmet.com wrote:
>>
> The "character" type in R corresponds to STRSXP in C, which is a vector of
> CHARSXPs. So you need an extra step to get to the C string:
>
> const char * omsg = CHAR(STRING_ELT(msg, 0));
>
> Duncan Murdoch
>
Thank you for the suggestion. I have replaced the code as suggested,
but I had attempted this conversion earlier. Unfortunately, I still
receive the same segmentation fault (and backtrace). The underlying
problem no longer appears to relate to type conversion. The following
code represents the entirety of the extension's R and C code (and
NAMESPACE file), and still causes the segmentation fault:
NAMESPACE:
---
useDynLib("tstlib")
export( "ptest" )
ptest.R:
---
ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
ptest.c:
---
#include
void Rwrite() { printf("[%i] %s",12,"Hi"); }
ptest.R:
---
ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
zzz.R:
---
.onLoad <- function(libname, pkgname)
{
}
.onUnload <- function(libpath) {
library.dynam.unload("forkex", libpath)
}
This is just about the most simple example I can think of, and don't
really know why it would segfault (if I change the interface in
ptest.R above from .Call to .C, no segfault occurs). The following is
the output from `R CMD SHLIB ptest.c`:
gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c
ptest.c -o ptest.o
gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o ptest.so ./ptest.o
-L/usr/lib64/R/lib -lR
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segmentation faults on SEXP conversion 20)
On Sun, Nov 15, 2009 at 8:30 PM, Duncan Murdoch - murd...@stats.uwo.ca
<+nabble+miller_2555+1412c7fca2.murdoch#stats.uwo...@spamgourmet.com>
wrote:
> On 15/11/2009 8:25 PM, nabble.30.miller_2...@spamgourmet.com wrote:
>> ptest.c:
>> ---
>> #include
>> void Rwrite() { printf("[%i] %s",12,"Hi"); }
>
> I forget if you said which system you're working on, but it may be that you
> don't have an open file handle for printf to use. Use Rprintf instead and
> things should be fine.
>
> Duncan Murdoch
Thank you - I attempted to use Rprintf as suggested. I also attempted
fprintf() using stdout. The platform is Linux
2.6.27.30-170.2.82.fc10.x86_64. It's a Fedora Core v10. I encountered
the same issue with both R v. 2.9.2 and 2.10.0 (currently running the
latter). If it helps, the following is the memcheck output after
making the suggested changes:
==25809== Invalid read of size 1
==25809==at 0x4D04209: SET_SYMVALUE (in /usr/lib64/R/lib/libR.so)
==25809==by 0x4D01E51: Rf_ReplIteration (in /usr/lib64/R/lib/libR.so)
==25809==by 0x4D020B7: (within /usr/lib64/R/lib/libR.so)
==25809==by 0x4D027CF: run_Rmainloop (in /usr/lib64/R/lib/libR.so)
==25809==by 0x40083A: main (in /usr/lib64/R/bin/exec/R)
==25809== Address 0x3 is not stack'd, malloc'd or (recently) free'd
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segmentation faults on SEXP conversion
On 15/11/2009 8:25 PM, nabble.30.miller_2...@spamgourmet.com wrote:
On Sun, Nov 15, 2009 at 2:52 PM, Duncan Murdoch -
nabble.30.miller_2...@spamgourmet.com
<>
wrote:
On 15/11/2009 1:41 PM, nabble.30.miller_2...@spamgourmet.com wrote:
The "character" type in R corresponds to STRSXP in C, which is a vector of
CHARSXPs. So you need an extra step to get to the C string:
const char * omsg = CHAR(STRING_ELT(msg, 0));
Duncan Murdoch
Thank you for the suggestion. I have replaced the code as suggested,
but I had attempted this conversion earlier. Unfortunately, I still
receive the same segmentation fault (and backtrace). The underlying
problem no longer appears to relate to type conversion. The following
code represents the entirety of the extension's R and C code (and
NAMESPACE file), and still causes the segmentation fault:
Sorry, I missed something else that's obvious: .Call needs a return
value. The c function needs to include Rinternals.h, and the function
needs to return a SEXP. So this works:
#include
SEXP Rwrite() { Rprintf("[%i] %s",12,"Hi"); return R_NilValue; }
(and your ptest function will return NULL).
Duncan Murdoch
NAMESPACE:
---
useDynLib("tstlib")
export( "ptest" )
ptest.R:
---
ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
ptest.c:
---
#include
void Rwrite() { printf("[%i] %s",12,"Hi"); }
ptest.R:
---
ptest <- function() { .Call("Rwrite", PACKAGE="tstlib");};
zzz.R:
---
.onLoad <- function(libname, pkgname)
{
}
.onUnload <- function(libpath) {
library.dynam.unload("forkex", libpath)
}
This is just about the most simple example I can think of, and don't
really know why it would segfault (if I change the interface in
ptest.R above from .Call to .C, no segfault occurs). The following is
the output from `R CMD SHLIB ptest.c`:
gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c
ptest.c -o ptest.o
gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o ptest.so ./ptest.o
-L/usr/lib64/R/lib -lR
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segmentation faults on SEXP conversion 20)
On Sun, Nov 15, 2009 at 9:16 PM, Duncan Murdoch - murd...@stats.uwo.ca
<+nabble+miller_2555+1412c7fca2.murdoch#stats.uwo...@spamgourmet.com>
wrote:
>
> Sorry, I missed something else that's obvious: .Call needs a return value.
> The c function needs to include Rinternals.h, and the function needs to
> return a SEXP. So this works:
>
> #include
> SEXP Rwrite() { Rprintf("[%i] %s",12,"Hi"); return R_NilValue; }
>
> (and your ptest function will return NULL).
>
> Duncan Murdoch
Ah - I must not have read the documentation closely enough to realize
a return value was required for external functions using the .Call
interface. By not returning anything, I think my erroneous calls were
mangling the stack heap. Thanks!
Will
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Add links to NEWS and CHANGES on help.start() page
On 13/11/2009 7:39 AM, Gabor Grothendieck wrote:
Its also difficult to know about demos unless you specifically issue a
demo(package = "mypackage") command. It would be nice if these were
listed too.
This is in R-devel now.
Note that the NEWS and/or ChangeLog file are listed on the package's
CRAN page such as:
http://cran.r-project.org/package=zoo
but the demos are not listed even there.
The structure is in place for displaying package news, but it doesn't
display yet. I think Kurt Hornik is working on the actual display.
Duncan Murdoch
On Fri, Nov 13, 2009 at 3:37 AM, Henrik Bengtsson
wrote:
Hi,
right now it is actually a bit tricky to locate and view the NEWS and
the CHANGES files, especially if you are a beginning and don't even
know that you are supposed to look for them.
I'd like to recommend that links to (local) NEWS and CHANGES are added
to the help.start() overview pages. help("NEWS")/help("CHANGE LOG")
and help("CHANGES") could display/refer to them as well.
/Henrik
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
