[Rd] Small inconsistency with boxplot
Dear R-core team,
I think I found a small inconsistency in the boxplot function. I don't want to
post it as a bug since I'm not sure this might be considered as one according
to the FAQ --- and this is not a major problem. Don't hesitate to tell me if
I'm wrong.
If you try to do a boxplot on a matrix and set the "at" argument to some vector
different from 1:n, n is the number of columns of your matrix, then some
boxplots will be hidden since the default "xlim" value will be set to c(0.5, n
+ 0.5) during the call of the bxp function.
Currently you can easily bypass this problem by setting "xlim" appropriately
when calling the boxplot function.
I think it will be better if all boxplots were always shown unless the "xlim"
argument is specified. (I realized this behavior when I tried to do boxplots on
conditional simulations of a stochastic process ; in which case the suggested
behavior might be useful.)
Here's an example
par(mfrow = c(1, 3))
data <- matrix(rnorm(10 * 50), 50)
colnames(data) <- letters[1:10]
x.pos <- seq(-10, 10, length = 10)
boxplot(data, at = x.pos) ## only the last 5 boxplots will appear
boxplot(data, at = 1:10) ## all boxplots will appear
boxplot(data, at = x.pos, xlim = range(x.pos) + c(-0.5, 0.5)) ## all boxplots
will be shown
I tried to do a patch if you want to change the current behavior --- note this
is my first patch ever so maybe I'm doing it wrong.
*** Downloads/R-2.14.0/src/library/graphics/R/boxplot.R Mon Oct 3 00:02:21 2011
--- boxplot.R Thu Nov 17 23:02:45 2011
***
*** 203,209
}
if(is.null(pars$xlim))
! xlim <- c(0.5, n + 0.5)
else {
xlim <- pars$xlim
pars$xlim <- NULL
--- 203,209
}
if(is.null(pars$xlim))
! xlim <- c(min(at) - 0.5, max(at) + 0.5)
else {
xlim <- pars$xlim
pars$xlim <- NULL
-
I3M, UMR CNRS 5149
Universite Montpellier II,
4 place Eugene Bataillon
34095 Montpellier cedex 5 France
http://www.math.univ-montp2.fr/~ribatet
Tel: + 33 (0)4 67 14 41 98
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changing graphic titles when using bquote and resizing the graphic window
Dear list,
I found a strange behavior of the graphic display when using bquote to set a
title to a plot. The problem arise when you manually resize the graphic window
using the mouse. It happens on both quartz and x11 devices. Here's a
reproducible example:
par(mfrow = c(1,3))
for (i in 1:3){
title <- as.expression(bquote(gamma[.(i)]))
plot(1:10, main = title)
}
Once you ran the code, the figure displays as expected --- each title is
$\gamma_i$, $i=1, 2, 3$. Now if you resize manually the graphic window using
the mouse all the titles will be set to $\gamma_3$.
In case this is useful, here's the ouput of sessionInfo().
> sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Best,
Mathieu
-
I3M, UMR CNRS 5149
Universite Montpellier II,
4 place Eugene Bataillon
34095 Montpellier cedex 5 France
http://www.math.univ-montp2.fr/~ribatet
Tel: + 33 (0)4 67 14 41 98
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] OpenMP and random number generation
Dear all, Now that R has OpenMP facilities, I'm trying to use it for my own package but I'm still wondering if it is safe to use random number generation within a OpenMP block. I looked at the R writing extension document both on the OpenMP and Random number generation but didn't find any information about that. Could someone tell me if it is safe or not please ? Best, Mathieu - I3M, UMR CNRS 5149 Universite Montpellier II, 4 place Eugene Bataillon 34095 Montpellier cedex 5 France http://www.math.univ-montp2.fr/~ribatet Tel: + 33 (0)4 67 14 41 98 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to generate R objects in C?
This is indeed details in Writing R Extensions. You should have a closer look at sections 5.9.3 and 5.9.4. Look at the pieces of C code, they will help you a lot. cheers, Mathieu Le mercredi 03 juin 2009 à 00:44 +0200, Kynn Jones a écrit : > I'm in the process of coding a parser (in C) to generate R entities > (vectors, lists, etc.) from a text description (different from R). > The basic parser works, and now I need to tell it how to create R > entities. I need to be able to create character vectors (for unicode > strings), integers, floats, unnamed lists, named lists, boolean > values, and NA. With the exception of the two types of lists and the > character vectors, all the other objects I need to generate are > "scalars", so I suppose they will correspond to 1-element vectors in > R. I also need to be able to add R entities to both kinds of lists. > > I've been staring at various official documents (ch 5 of Writing R > Extensions, R Internals, Rinternals.h) for this kind of work for some > time, but I can't find the constructors for such objects (here I'm > using the term "constructor" loosely). I'm even further from finding > the C equivalent of "my.list[[ length(my.list) + 1 ]] <- new.thing". > > Can someone point me in the right direction? > > Thanks! > > Kynn > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Show location of workspace image on quit?
I guess that having something like this > q() > Save workspace image (/home/me/workspace/.RData)? [y/n/c/e]: where "e" means Editing the path should be clear enought, isn't it? Best, Mathieu Le vendredi 05 juin 2009 à 14:36 +0200, Wacek Kusnierczyk a écrit : > Duncan Murdoch wrote: > > On 05/06/2009 7:53 AM, Barry Rowlingson wrote: > >> When I quit R, it says: > >> > >> > q() > >> Save workspace image? [y/n/c]: > >> > >> and since I've probably got 3 R sessions running in however many > >> different directories and I might have jumped around with setwd() , I > >> forget exactly where R wants to save its workspace image. So could q() > >> be changed to say what file it is going to save to before it does? > >> > >> Currently I have to hit 'c', then do getcwd(), then quit again. > >> Would something like > >> > >> > q() > >> Save workspace image (/home/me/workspace/.RData)? [y/n/c]: > >> > >> be useful to anyone else? Just thought I'd ask before I dive into > >> internals or wrap the q function for myself. > > > > That sounds like a great suggestion. I might word it as > > > > Save workspace to "/home/me/workspace/.RData"? [y/n/c] > > but then what would happen if you choose 'n'? i'd expect a prompt for > another path -- and i'd suspect this is what others would expect, too. > with the message as barry suggests, exiting without saving is the most > natural thing, which is what happens in the current implementation. > > if you insist on your version, it would be better, i think, to change > the behaviour, too. > > > vQ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] beginner's guide to C++ programming with R packages?
An other possibility is to insert new features in your package once you
feel pretty confident with your new code. "R CMD SHLIB myfile.c" will
build the SHared LIBrary and then load it in R by invoking
"dyn.load("myfile.so")" in an R console.
Once you're satisfied with your code, just do as you did before - R CMD
build mypkg".
Cheers,
Mathieu
Le lundi 29 juin 2009 à 11:49 +0200, Douglas Bates a écrit :
> On Fri, Jun 26, 2009 at 2:43 PM, Paul Johnson wrote:
> > Hello, again.
> >
> > I'm interested to learn how programmers develop & test C/C++ code with
> > R packages in Linux. I've been reading R source and the manual on
> > Writing R Extensions but there are just a couple of details I can't
> > understand. I wish I could watch over a developer's shoulder to see
> > how people actually do this.
> >
> > I've tested a bit. I am able to take package.tar.gz file, open it up,
> > fiddle the source code, and then run
> >
> > R CMD check package-dir
> >
> > from the directory above "package-dir" ,
> >
> > R CMD build package-dir
> >
> > and
> >
> > R CMD INSTALL
>
> For your purposes it is probably better to avoid building a new tar.gz
> file and combine the last two steps as
>
> R CMD INSTALL package-dir
>
> The install process uses the make utility which will check which of
> the object files need to be recompiled. If you only modify one source
> file it will be the only file recompiled.
> > on the tarball that is produced. Then in R, I can load the package and use
> > it.
> >
> > That part is "all good", but somewhat tedious. I don't want to
> > entirely recompile and reinstall the whole package just to test one
> > function. I notice that R CMD check creates a new directory called
> > "package.Rcheck" and the shared objects and example code of the
> > package are in there. Can I force R to use those *.so files instead
> > of the ones in /usr/lib/R ?
> >
> >
> > I also wonder "what is wrong with gprof? In the Writing R Extensions
> > manual, it describes "oprofile" and "sprof" for Linux. I will try
> > them, but they are unfamilar to me. I've used gprof in the past in C
> > projects, and it is a pretty painless thing to add a compiler flag
> > -pg, run the program, and then review gmon.out. The Writing R
> > Extensions manual does not mention gprof in its section on Linux, but
> > it does mention it under Solaris. There is a somewhat ambiguous
> > statement:
> >
> > 3.4.2 Solaris
> >
> > On 64-bit (only) Solaris, the standard profiling tool gprof collects
> > information from shared libraries compiled with -pg.
> >
> > Does "(only)" here mean to differentiate Solaris from other Linux/Unix
> > systems? Or does it differentiate 64bit Solaris from other Solaris?
> >
> > But this draws me back to the basic question. I don't want to run R
> > CMD INSTALL 20 times per hour. How do developers "actually" test
> > their code?
> >
> > pj
> > --
> > Paul E. Johnson
> > Professor, Political Science
> > 1541 Lilac Lane, Room 504
> > University of Kansas
> >
> > __
> > 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
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Checking package on Windows (and seemingly irreproducible errors in CRAN checks)
Dear Carlos,
>From your check results:
cbc.data <- cbc.read.table( system.file("data",
"cbc.test.data.txt", package = "colbycol"), sep = "\t" )
Warning in file(file, "r") :
cannot open file '0001': No such file or directory
I think you're trying to read the file "cbc.test.data.txt" located in
the folder "data" of your package skeleton. Is that right? If so, maybe
using
paste(system.file(package = "colbycol"),
"data/cbc.test.data.txt", sep="/")
will solve your issue - although I didn't try.
Best,
Mathieu
Le mardi 28 juillet 2009 à 22:31 +0200, Carlos J. Gil Bellosta a écrit :
> Hello,
>
> I submitted a small package, colbycol, to CRAN. I developed it on Linux
> and tested it on my Linux box and another Windows machine. Besides,
> other people kindly tested it in their systems.
>
> The package seems to "compile" correctly in r-forge for Windows. In
> fact, you can find the binary package at
>
> http://r-forge.r-project.org/R/?group_id=426.
>
> However, in CRAN, the Windows package cannot be built according to
>
> http://cran.r-project.org/web/checks/check_results_colbycol.html
>
> I cannot reproduce the error. I can guess very little more about what
> could have gone wrong. The error seems to happen at a time when R tries
> to read a temporary file (in a temporary folder) that has just been
> created in a call to a non-R piece of code that does not catch its IO
> exceptions, if any.
>
> Any ideas? Suggestions?
>
> Best regards,
>
> Carlos J. Gil Bellosta
> http://www.datanalytics.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem in matrix definition?
Dear Fabio, The problem is that L[k,1:(r-1)] is not anymore a matrix but a vector. Hence when you do t(L[k,1:(r-1)]) you get a matrix with only one row while I think you expected one column instead. You can see this feature with a simpler example like the following one: x <- runif(10) is.vector(x) dim(t(x))##1,10 dim(t(t(x)))##10,1 Getting back to your code, you probably want that L[k,1:(r-1)] is a matrix with r-1 columns. This is possible by substituting t(L[k,1:(r-1)]) for t(t(L[k,1:(r-1)])) or matrix(L[k,1:(r-1)], nrow = 1) Maybe somebody else will find a more elegant fix for your problem. However, I tried and it did solve your issue. Cheers, Mathieu Le lundi 31 août 2009 à 19:09 +0200, Fabio Mathias Corrêa a écrit : > The problem is that arrays are the same size. The only difference is how they > were built! > > The way to build the matrix should not influence in the outcome! > > Below is the commented code in MatLab! > > Neural Information Processing - Letters and Reviews Vol.8, No.2, August 2005 > > function Y = geninv(G) > % Returns the Moore-Penrose inverse of the argument > % Transpose if m < n >[m,n]=size(G); transpose=false; >if m transpose=true; > A=G*G'; > n=m; >else >A=G'*G; >end >% Full rank Cholesky factorization of A >dA=diag(A); tol= min(dA(dA>0))*1e-9; >L=zeros(size(A)); >r=0; >for k=1:n > r=r+1; > L(k:n,r)=A(k:n,k)-L(k:n,1:(r-1))*L(k,1:(r-1))'; > % Note: for r=1, the substracted vector is zero > if L(k,r)>tol > L(k,r)=sqrt(L(k,r)); > if k L((k+1):n,r)=L((k+1):n,r)/L(k,r); > end > else > r=r-1; > end >end >L=L(:,1:r); > % Computation of the generalized inverse of G >M=inv(L'*L); >if transpose > Y=G'*L*M*M*L'; >else > Y=L*M*M*L'*G'; >end > > > Thanks! > >Fábio Mathias Corrêa > Estatística e Experimentação Agropecuária/UFLA > Brazil > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible bug in the Rd parser?
Dear list,
I got an automatic email complaining than some of my packages didn't
pass 'R CMD check' for R-2.10.0 alpha anymore. Both of them make use of
the "cases" LaTeX environment.
Inspecting the log outputs I got:
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
! Misplaced alignment tab character &.
I noticed that the Rd parser changed quite recently and that '#', '_'
and '&' must not be escaped according to "Writing R extensions".
However, the problematic .Rd portion seems (to me) OK
\deqn{\theta(h) =
\begin{cases}
u_\beta \left(\mu + \frac{\nu(h)}{\Gamma(1 - \xi)}
\right),&\xi \neq 0\\
\exp\left(\frac{\nu(h)}{\sigma}\right),&\xi = 0
\end{cases}
}{u_beta (mu + nu(h) / Gamma(1 - \xi)), if \xi < 1,
exp(nu(h)/sigma), otherwise}
Removing the alignment tab character '&' solves the issue but doesn't
produce the expected LaTeX output. Do I miss something with the new Rd
parser requirements?
I'm not 100% sure but it also seems like that "\\' symbol isn't
interpreted as a break line - in the "cases" environment at least. This
might be one reason why the alignment tab '&' is misplaced.
Best,
Mathieu
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in the Rd parser?
Thanks Duncan for all these answers. Indeed I should have checked that
the "cases" environment was provided by Rd.sty. Mea culpa.
The good point is that before 2.10.0 alpha "R CMD check" finished
without any error but the output was wrong - because of the cases
environment as you said. Now it fails and this is a good point as I,
maybe others??, usually don't have a look at "mypkg-manual.pdf" but only
at the html version of it.
Cheers,
Mathieu
Le samedi 10 octobre 2009 à 20:40 +0200, Duncan Murdoch a écrit :
> On 10/10/2009 2:25 PM, Duncan Murdoch wrote:
> > On 10/10/2009 8:07 AM, Mathieu Ribatet wrote:
> >> Dear list,
> >>
> >> I got an automatic email complaining than some of my packages didn't
> >> pass 'R CMD check' for R-2.10.0 alpha anymore. Both of them make use of
> >> the "cases" LaTeX environment.
> >>
> >> Inspecting the log outputs I got:
> >>
> >> LaTeX errors when creating PDF version.
> >> This typically indicates Rd problems.
> >> LaTeX errors found:
> >> ! Misplaced alignment tab character &.
> >>
> >> I noticed that the Rd parser changed quite recently and that '#', '_'
> >> and '&' must not be escaped according to "Writing R extensions".
> >> However, the problematic .Rd portion seems (to me) OK
> >>
> >> \deqn{\theta(h) =
> >> \begin{cases}
> >> u_\beta \left(\mu + \frac{\nu(h)}{\Gamma(1 - \xi)}
> >> \right),&\xi \neq 0\\
> >> \exp\left(\frac{\nu(h)}{\sigma}\right),&\xi = 0
> >> \end{cases}
> >> }{u_beta (mu + nu(h) / Gamma(1 - \xi)), if \xi < 1,
> >> exp(nu(h)/sigma), otherwise}
> >>
> >
> > One more followup: the problem appears to be in the "cases"
> > environment. If I rewrite that block using "array" instead, things are
> > fine:
> >
> > \deqn{\theta(h) =
> > \left\{\begin{array}{ll}
> > u_\beta \left(\mu + \frac{\nu(h)}{\Gamma(1 - \xi)}
> > \right),&\xi \neq 0\\
> > \exp\left(\frac{\nu(h)}{\sigma}\right),&\xi = 0
> > \end{array}\right.
> >}{u_beta (mu + nu(h) / Gamma(1 - \xi)), if \xi < 1,
> > exp(nu(h)/sigma), otherwise}
> >
> > This makes me think it's a bug in the LaTeX package that provides
> > "cases", or a conflict with our Rd.sty file, but I don't know which.
>
> And the final answer: the "cases" environment is in the amsmath
> package, which is not used by R. You need to use regular LaTeX, not
> fancy stuff like that. (There's a \cases macro in LaTex, which doesn't
> know what to do with alignment tabs: that's why you got the error you did.)
>
> Duncan Murdoch
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check: Error in .C
Dear Etienne,
You probably want to create a zzz.R file in the /mypkg/R/ folder which
is just
.First.lib <- function(lib, pkg){
library.dynam("MyPkgName", package = pkg, lib.loc = lib)
return(invisible(0))
}
This would ensure that your shared library will be loaded.
Best,
Mathieu
Le lundi 26 octobre 2009 à 03:58 +0100, Etienne Laliberté a écrit :
> Function/file names are hypothetical. Say I have written myfunction.R,
> which calls myfunction.c via .C("myfunction", ...).
>
> I've compiled successfully myfunction.c via R CMD SHLIB myfunction.c
> in the terminal. Then, in the R console:
>
> dyn.load("myfunction.so")
> source("myfunction.R")
> test <- myfunction() # works fine
>
> So everything is in order, myfunction works perfectly.
>
> Now I want to include myfunction() into a package called mypackage.
> Here's what I did:
>
> 1) I've added PACKAGE = "mypackage" in the .C() line in myfunction.R.
> 2) I put myfunction.R into the R folder of mypackage
> 3) I put myfunction.c into the src folder of mypackage
> 4) I created myfunction.Rd into the man folder
>
> I then build the package via R CMD build mypackage. All good. However,
> when I run R CMD check mypackage, I get the following error (note that
> I translated from french, might be a bit different in english):
>
> Error in .C("myfunction", ...): C symbol name "myfunction" cannot be
> found in the DLL for package "mypackage"
>
> I would appreciate some help here. Please do not refer my to "Writing
> R extensions" - if the answer's in there, I don't understand it.
>
> Many thanks.
>
> --
> Etienne Laliberté
>
> Rural Ecology Research Group
> School of Forestry
> University of Canterbury
> Private Bag 4800
> Christchurch 8140, New Zealand
> Phone: +64 3 366 7001 ext. 8365
> Fax: +64 3 364 2124
> www.elaliberte.info
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Matrix multiplication in a C code
Dear list members, I've got a small question on matrix multiplications in a C code. Because of a really cpu demanding likelihood, I had to use a C code within an R function wrapper. I'm pretty sure that there is already one good code for matrix multiplication in C - maybe in the R source code itself - but I wasn't able to find it. Anyone as an idea on how to handle matrix multiplications? Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix multiplication in a C code
First, sorry for the delayed reply. You were right matprod will do exactly what I want. Thanks. On another point, are you aware about a BLAS routine to test for semi-definite positive matrix ? This is required for my loglikelihood and thus should return -\infty if not. Best, Mathieu Prof Brian Ripley a écrit : > On Sun, 6 Apr 2008, Mathieu Ribatet wrote: > >>Dear list members, >> >> I've got a small question on matrix multiplications in a C code. Because >> of a really cpu demanding likelihood, I had to use a C code within an R >> function wrapper. I'm pretty sure that there is already one good code >> for matrix multiplication in C - maybe in the R source code itself - but >> I wasn't able to find it. >> >> Anyone as an idea on how to handle matrix multiplications? > > Well, R does use fast C code where available: see matmult in > src/main/array.c which calls the BLAS. It works best if you have an > optimized BLAS: otherwise it may not be as fast as the simple version > used when there are NAs present. > -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] && and ||
Well, you just have to use "&", "|" instead of "&&", "||". Best, Mathieu Yuan Jian a écrit : > Hello there, > > I got a small problem about logical calculation: > we can get a sequene from a+b as below: > > > a<-c(1,2) > >> b<-c(3,4) >> a+b >> > [1] 4 6 > > but when the sequences are logical. (I want to get (True,False) && (True, > True) ==> (True, False), but when I do as below. > >> e<-c(T,T) >> f<-c(F,T) >> e >> > [1] TRUE TRUE > >> f >> > [1] FALSE TRUE > >> g<-e && f >> > **g becomes one logical value only > >> g >> > [1] FALSE > > what should I do when I want to get a sequence for operate && or ||? > > kind regards > Yu > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incorrect @INC: Rcmd SHLIB error under Windows (2.6.2, 44383) (PR#11165)
Has your environment variable path been set correctly? It's been a while that I'm not using R under windows but remember had experienced the same error. I remember that I had to put many paths as environment variable to build R packages properly. Best, Mathieu [EMAIL PROTECTED] a écrit : > Hi, R team. > > I'm trying to build a dll from a c program to be invoked within R using > the .C() functionality. > > Everything works like a charm on my Linux (Centos 5) (also 2.6.2) machines--- > but under windows (Vista Ultimate) upon running (in either the windows 'Cmd' > command window or a Bash window) the command > > Rcmd SHLIB myfun.c > > I receive the error: > > Can't locate R/Utils.pm in > @INC (@INC contains: c \PROGRA~1\R\R-26~1.2\share\perl; > /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 > /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 > /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin > /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at > c:\PROGRA~1\R\R-26~1.2/bin/SHLIB line 22. > BEGIN failed--compilation aborted at c:\PROGRA~1\R\R-26~1.2/bin/SHLIB line > 22. > > -- -- -- -- -- > > Notice the first entry in @INC is incorrect--- the item > >c \PROGRA~1\R\R-26~1.2\share\perl; > > SHOULD be > >c:\PROGRA~1\R\R-26~1.2\share\perl; > > but a space appears where the colon should be. > > The neeeded file 'R/Utils.pm' is in fact located where it should be, > below 'c:\PROGRA~1\R\R-26~1.2\share\perl', but perl can't find it because > INC is set incorrectly. > > Any suggestions? Where IS 'INC' set? Cheers,-R > > -- > Prof. Robert L. Wolpert : <[EMAIL PROTECTED]> : +1-919-684-3275 > Duke Univ. Dept. of Statistical Science : 211c Old Chem, Box 90251 > & Nicholas School of the Environment : www.stat.Duke.edu/~rlw/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incorrect @INC: Rcmd SHLIB error under Windows (2.6.2, 44383) (PR#11161)
Has your environment variable path been set correctly? It's been a while that I'm not using R under windows but remember had experienced the same error. I remember that I had to put many paths as environment variable to build R packages properly. Best, Mathieu [EMAIL PROTECTED] a écrit : > Hi, R team. > > I'm trying to build a dll from a c program to be invoked within R using > the .C() functionality. > > Everything works like a charm on my Linux (Centos 5) (also 2.6.2) machines--- > but under windows (Vista Ultimate) upon running (in either the windows 'Cmd' > command window or a Bash window) the command > > Rcmd SHLIB myfun.c > > I receive the error: > > Can't locate R/Utils.pm in > @INC (@INC contains: c \PROGRA~1\R\R-26~1.2\share\perl; > /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 > /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 > /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin > /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at > c:\PROGRA~1\R\R-26~1.2/bin/SHLIB line 22. > BEGIN failed--compilation aborted at c:\PROGRA~1\R\R-26~1.2/bin/SHLIB line > 22. > > -- -- -- -- -- > > Notice the first entry in @INC is incorrect--- the item > >c \PROGRA~1\R\R-26~1.2\share\perl; > > SHOULD be > >c:\PROGRA~1\R\R-26~1.2\share\perl; > > but a space appears where the colon should be. > > The neeeded file 'R/Utils.pm' is in fact located where it should be, > below 'c:\PROGRA~1\R\R-26~1.2\share\perl', but perl can't find it because > INC is set incorrectly. > > Any suggestions? Where IS 'INC' set? Cheers,-R > > -- > Prof. Robert L. Wolpert : <[EMAIL PROTECTED]> : +1-919-684-3275 > Duke Univ. Dept. of Statistical Science : 211c Old Chem, Box 90251 > & Nicholas School of the Environment : www.stat.Duke.edu/~rlw/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Extending R formulas
Dear list, I'm currently trying to write a new R package to model spatial extremes. In particular, for a model fitting procedure, I'd like to use flexible response surfaces (like linear models, splines, ...) for the parameters of my model. Following this idea, I'd like to allow "a new interpretation" of an R formula given by the user, like y ~ x1 + rb(x2, knots, degree, penalty) where x1, x2 are covariates and rb stands for using a radial basis smooth splines with given knots, degree and penalty coefficient. Such "new formula" should then provide the appropriate design matrix. I know that existing packages have done this way too - e.g. mgcv; but their codes are quite hard to understand - for me I mean. Does anyone can provide some useful guidelines to do this kind of stuffs or provide more readable codes? In advance, thank you Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(0, 1:1000) ; 0 * Inf etc
I definitely do agree with you. Basically, I see two different ways to proceed: 1. one could first check if there are any 0 in the vector and then return 0 without computing the product 2. or convert prod(x1, x2, x3) in prod(c(x1, x2, x3)) Both approaches are similar except for the pathological case where one vector x1 is really huge. An example: prod(0, 1:1e25) 1. will give 0 2. will give an error stating that the vector c(0, 1:1e255) will be too large - in length I mean Consequently, my opinion will be that approach 1 will be better - and maybe faster because it'll avoide useless computations. Best, Mathieu Martin Maechler a écrit : > I think most of us would expect prod(0:1000) to return 0, and ... > > > ... it does. > > However, many of us also expect > prod(x1, x2)to be equivalent to > prod(c(x1,x2)) > the same as we can expect that for min(), max(), sum() and such > members of the "Summary" group. > > Consequently, prod(0, 1:1000) should also return 0, > but as you see, it gives NaN which may be a bit puzzling... > The explanation is relatively simple: > > 1) The internal implementation uses > > prod(x1, x2) := prod(x1) * prod(x2) > >which in this case is > > 2) 0 * Infand that is not 0, but NaN; > > not necessarily because we would want that, but I think just > because the underlying C math library does so. > > > I would personally like to change both behaviors, > but am currently only proposing to change prod() such as to > return 0 in such cases. > This would be S-plus compatible, in case that matters. > > Opinions? > > Martin Maechler, ETH Zurich & R-core > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(0, 1:1000) ; 0 * Inf etc
>> I definitely do agree with you.
>> Basically, I see two different ways to proceed:
>>
>>1. one could first check if there are any 0 in the vector and then
>> return 0 without computing the product
>>
>
> That would fail for prod(0,Inf), which should return the same
> thing as 0*Inf=NaN. Similarly for prod(0,NA) and prod(0,NaN).
> Scanning for all these things might well be slower than just
> doing the multiplications. Scanning also means that 0 is treated
> more commutatively than other numbers.
>
>
Yes you're right when vectors have special values - oupppsss. However,
for the "more commutatively behaviour of 0", to me this is not a problem
- just a computational trick. We all know easily how to multiply by 11.
This is just the same. What we want is that the operator is still
commutative which (of course) is still the case.
However, you're probably right with the time consuming approach of
checking 0 (as well as special values) within the vector. The question
is what is the main objective? Fast computations but could lead to
miss-calculations - in rarely cases. Or run codes a little bit slower
while returning the appropriate values - a little bit more often.
I'm not sure users do so many times products of really huge length
vectors though - but this is only my point of view.
Best,
Mathieu
>>2. or convert prod(x1, x2, x3) in prod(c(x1, x2, x3))
>>
>
> c() can convert values of classy objects in undesirable ways.
> E.g.,
>> now<-Sys.time()
>> min(now-file.info(".")$mtime, now-file.info("..")$mtime)
>Time difference of 3787.759 secs
>> min(c(now-file.info(".")$mtime, now-file.info("..")$mtime))
>[1] 1.052155
>
> This may be considered a bug in c(), at least for class
> "timediff" (and "factor" and "ordered"), but c() removes
> attributes.
>
>
>> Martin Maechler a ?crit :
>>
>>> I think most of us would expect prod(0:1000) to return 0, and ...
>>>
>>>
>>> ... it does.
>>>
>>> However, many of us also expect
>>> prod(x1, x2)to be equivalent to
>>> prod(c(x1,x2))
>>> the same as we can expect that for min(), max(), sum() and such
>>> members of the "Summary" group.
>>>
>>> Consequently, prod(0, 1:1000) should also return 0,
>>> but as you see, it gives NaN which may be a bit puzzling...
>>> The explanation is relatively simple:
>>>
>>> 1) The internal implementation uses
>>>
>>> prod(x1, x2) := prod(x1) * prod(x2)
>>>
>>>which in this case is
>>>
>>> 2) 0 * Infand that is not 0, but NaN;
>>>
>>> not necessarily because we would want that, but I think just
>>> because the underlying C math library does so.
>>>
>>>
>>> I would personally like to change both behaviors,
>>> but am currently only proposing to change prod() such as to
>>> return 0 in such cases.
>>> This would be S-plus compatible, in case that matters.
>>>
>>> Opinions?
>>>
>>> Martin Maechler, ETH Zurich & R-core
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>> --
>> Institute of Mathematics
>> Ecole Polytechnique F?d?rale de Lausanne
>> STAT-IMA-FSB-EPFL, Station 8
>> CH-1015 Lausanne Switzerland
>> http://stat.epfl.ch/
>> Tel: + 41 (0)21 693 7907
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
> Bill Dunlap
> Insightful Corporation
> bill at insightful dot com
> 360-428-8146
>
> "All statements in this message represent the opinions of the author and do
> not necessarily reflect Insightful Corporation policy or position."
>
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: R_Visible" (PR#11265)
> I tried installing r on my computer, and didn't manage to get the program > running. > After having installed littler, typing r into the bash results in following > message: > > r: symbol lookup error: r: undefined symbol: R_Visible > Did you invoke "r" or "R" because it is totally different *NIX sytems are case sensitive. You could also run "R --verbose" to see what's going wrong if any... Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: (PR#11273)
> I tried installing r on my computer, and didn't manage to get the program > running. > After having installed littler, typing r into the bash results in following > message: > > r: symbol lookup error: r: undefined symbol: R_Visible > Did you invoke "r" or "R" because it is totally different *NIX sytems are case sensitive. You could also run "R --verbose" to see what's going wrong if any... Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Have you ever experienced this problem with REAL in a C code
Dear all, I'm currently experiencing big troubles with my C code called by .Call in a R function. I know this may not be the right place for such things but these errors are driving me crazy. And I hope other people may have already experienced these problems so that they could give me good suggestions. Sorry if I'm completely out of topic. Well let's go... I'm writing a MCMC algo for Bayesian analysis. The MCMC part is written in C but call R objects (e.g. output and arguments are SEXP). The C is called by a wrapper R function through .Call. The posterior density is computed using a R code that calls 2 different codes: one for the prior distribution and one for the likelihood. The prior distribution is fully written in R while the likelihood is computed using a C code. Both of these codes are (seem to be) ok and *always* return numeric - and no special values as Inf, NA,... When I'm running my codes (enclosed you'll find the C code), I get one of the following error - *when error occurs*: Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'raw' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'list' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not an 'integer' The problem is that REAL seems not to be applied to a list (I've got no list objects), and not to an integer too. I checked for wrong allocation memory, infinite values but found nothing... Any suggestions for possible reasons would be definitively appreciated. Again, if this mail has no reason to be in this list; sorry and forget it. Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Have you ever experienced this problem with REAL in a C code
Thanks. These are good suggestions. I'll have a closer look (again) at the code. Best, Mathieu Prof Brian Ripley a écrit : These messages mean that R's internal code is encountering the wrong SEXPTYPE. This almost always means one of - lact of PROTECTion, so objects have been garbage-collected before use. - memory corruption, most often by writing outside array bounds. See the chapter in 'Writing R Extensions' about this, and if possible make use of valgrind. On Fri, 9 May 2008, Mathieu Ribatet wrote: Dear all, I'm currently experiencing big troubles with my C code called by .Call in a R function. I know this may not be the right place for such things but these errors are driving me crazy. And I hope other people may have already experienced these problems so that they could give me good suggestions. Sorry if I'm completely out of topic. Well let's go... I'm writing a MCMC algo for Bayesian analysis. The MCMC part is written in C but call R objects (e.g. output and arguments are SEXP). The C is called by a wrapper R function through .Call. The posterior density is computed using a R code that calls 2 different codes: one for the prior distribution and one for the likelihood. The prior distribution is fully written in R while the likelihood is computed using a C code. Both of these codes are (seem to be) ok and *always* return numeric - and no special values as Inf, NA,... When I'm running my codes (enclosed you'll find the C code), I get one of the following error - *when error occurs*: Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'raw' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not a 'list' or Error in gibbs(1000, init, prior.p, "whitmat", data = ms1, coord = locations, : REAL() can only be applied to a 'numeric', not an 'integer' The problem is that REAL seems not to be applied to a list (I've got no list objects), and not to an integer too. I checked for wrong allocation memory, infinite values but found nothing... Any suggestions for possible reasons would be definitively appreciated. Again, if this mail has no reason to be in this list; sorry and forget it. Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem in conditional looping
Why don't you consider a "while" loop e.g. while (Pij < 0) ##Then you resample according to your code Nadeem Shafique a écrit : Respected All, I am writing a program in R and facing some problem with applying "if statment". Program first draw random numbers from bivariate normal distribution then compute variable say Pi and Pij from that sample and then further computation . . . In some samples Pij is appearing with negitive sign and ultimately resulted in an negative variance estimator. Now i want to design the program like this if the Pij is negative then go back and draw another sample until we get a sample that produces positive Pij and then move forward for further processing. Best Regards, Nadeem Shafique Butt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Editing the "..." argument
Dear all, I'd like tweaking the ... arguments that one user can pass in my function for fitting a model. More precisely, my objective function is (really) problematic to optimize using the "optim" function. Consequently, I'd like to add in the "control" argument of the latter function a "ndeps = rep(something, #par)" and/or "parscale = something" if the user has not specified it already. Do you know a way to deal with this point? In advance, thanks. Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package has a loading problem
Have you create a zzz.R file in the R folder? I think your issue is
related to this...
Example of the zzz.R file:
".First.lib" <-
function(lib, pkg)
{
library.dynam("your_pkd_name", package = pkg, lib.loc = lib)
return(invisible(0))
}
This is required when you have C/Fortran code. See the writing R
extension manual.
Best,
Mathieu
Yulia Arzhaeva a écrit :
Hello,
I have difficulties in finding why I cannot load a custom R package in
Linux (Suse 10). When I run R CMD check for a package source folder I
get the following message:
".
Error in dyn.load(file, ...) :
unable to load shared library
'/home/yarz/projects/Riman/Riman.Rcheck/Riman/libs/Rimanlib.so':
/home/yarz/projects/Riman/Riman.Rcheck/Riman/libs/Rimanlib.so:
undefined symbol: immagnify
Error in library(Riman) : .First.lib failed for 'Riman'
Execution halted
It looks like this package has a loading problem: see the messages for
details. "
The same message I get when I call library(Riman) inside R after
installation of the package.
The installation via R CMD INSTALL caused no error messages. However,
Riman.so had been built before R CMD INSTALL was called, and put into
the source subfolder Riman/inst/libs. It was built via a usual gcc
call and linked with all the necessary libraries (so it is weird that
references seemed to be undefined).
The strange thing is that when I borrow Riman.so built by some other
person in my group and replace my copy with it, loading problem
disappears! We both use the same server with Linux Suse 10, the same
R installation, the same version of gcc and the same Makefiles for
building Riman.so . We went through variables I might have omitted to
set correctly, but they seemed OK.
If you could give me any hint on what might be a problem, where else
to look, I would be very happy. Many thanks in advance.
Regards,
Yulia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adding .PDF files to a package
Dear Rense, The way you included your pdf file in your package is appropriate. Normally, when invocking "help.start()" and going to your package link, you should have two links overview and directory where your pdf file should be located. Best, Mathieu Rense Nieuwenhuis a écrit : Deal all, new as I am to developing packages for R-Project, I apologize on beforehand for questions that are too obvious. I am trying to 'add' a PDF document containing some detailed information to a package. The way I understand the Rexts.pdf document, I should add my .PDF document to the /inst/doc/ folder, and links to the files should be build automatically. However, after building it on MacOSX (10.4) using 'R CMD build' and checking it using 'R CMD check', no links seems to be present. All checks are OK, but no vignette or whatever appears in the help-files of the package. Clearly, I'm missing something. I would really appreciate some pointers on how to integrate an 'additional' pdf file to my package. Thanks in advance, Rense Nieuwenhuis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Numerical optimisation and "non-feasible" regions
Dear list,
I'm currently writing a C code to compute the (composite) likelihood -
well this is done but not really robust. The C code is wrapped in an R
one which call the optimizer routine - optim or nlm. However, the
fitting procedure is far from being robust as the parameter space
depends on the parameter - I have a covariance matrix that should be a
valid one for example.
Currently, I set in my header file something like #define MINF -1.0e120
and test if we are in a non-feasible region, then setting the
log-composite likelihood to MINF. The problem I see with this approach
is that for a quite large non-feasible region, we have a kind of plateau
where the log-composite likelihood is constant and may have potential
issues with the optimizer. The other issue is that the gradient is now
badly estimated using finite-differences.
Consequently, I'm not sure this is the most relevant approach as it
seems that (especially the BFGS method, probably due to the estimation
of the gradient) the optimization is really sensitive to this "strategy"
and fails (quite often).
As I'm (really) not an expert in optimization problems, do you know good
ways to deal with non-feasible regions? Or do I need to reparametrize my
model so that all parameters belong to $\mathbb{R}$ - which should be
not so easy...
Thanks for your expertise!
Best,
Mathieu
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical optimisation and "non-feasible" regions
Thanks Ben for your tips. I'm not sure it'll be so easy to do (as the non-feasible regions depend on the model parameters), but I'm sure it's worth giving a try. Thanks !!! Best, Mathieu Ben Bolker a écrit : Mathieu Ribatet epfl.ch> writes: Dear list, I'm currently writing a C code to compute the (composite) likelihood - well this is done but not really robust. The C code is wrapped in an R one which call the optimizer routine - optim or nlm. However, the fitting procedure is far from being robust as the parameter space depends on the parameter - I have a covariance matrix that should be a valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical optimisation and "non-feasible" regions
Dear Patrick (and other), Well I used the Sylvester's criteria (which is equivalent) to test for this. But unfortunately, this is not the only issue! Well, to sum up quickly, it's more or less like geostatistics. Consequently, I have several unfeasible regions (covariance, margins and others). The problem seems that the unfeasible regions may be large and sometimes lead to optimization issues - even when the starting values are well defined. This is the reason why I wonder if setting by myself a $-\infty$ in the composite likelihood function is appropriate here. However, you might be right in setting a tolerance value 'eps' instead of the theoretical bound eigen values > 0. Thanks for your tips, Best, Mathieu Patrick Burns a écrit : If the positive definiteness of the covariance is the only issue, then you could base a penalty on: eps - smallest.eigen.value if the smallest eigen value is smaller than eps. Patrick Burns [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") Mathieu Ribatet wrote: Thanks Ben for your tips. I'm not sure it'll be so easy to do (as the non-feasible regions depend on the model parameters), but I'm sure it's worth giving a try. Thanks !!! Best, Mathieu Ben Bolker a écrit : Mathieu Ribatet epfl.ch> writes: Dear list, I'm currently writing a C code to compute the (composite) likelihood - well this is done but not really robust. The C code is wrapped in an R one which call the optimizer routine - optim or nlm. However, the fitting procedure is far from being robust as the parameter space depends on the parameter - I have a covariance matrix that should be a valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion for the optimization code
Dear list, Here's a suggestion about the different optimization code. There are several optimization procedures in the base package (optim, optimize, nlm, nlminb, ..). However, the output of these functions are slightly different. For instance, 1. optim returns a list with arguments par (the estimates), value the minimum (maxima) of the objective function, convergence (optim .convergence) 2. optimize returns a list with arguments minimum (or maximum) giving the estimates, objective the value of the obj. function 3. nlm returns a list with arguments minimum giving the minimum of the obj. function, minimum the estimates, code the optim. convergence 4. nlminb returns a list with arguments par (the estimates), objective, convergence (conv. code), evaluations Furthermore, optim keeps the names of the parameters while nlm, nlminb don't. s I believe it would be nice if all these optimizers have a kind of homogenized output. This will help in writing functions that can call different optimizers. Obviously, we can write our own function that homogenized the output after calling the optimizer, but I still believe this will be more user-friendly. Do you think this is a reasonable feature to implement - despite it isn't an important point? Best, Mathieu * BTW, if this is relevant, I could try to do it. -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion for the optimization code
Ok, please consider it as a bad call. Thanks for your answers. Best, Mathieu Prof Brian Ripley a écrit : On Fri, 8 Aug 2008, Mathieu Ribatet wrote: Dear list, Here's a suggestion about the different optimization code. There are several optimization procedures in the base package (optim, optimize, nlm, nlminb, ..). However, the output of these functions are slightly different. For instance, 1. optim returns a list with arguments par (the estimates), value the minimum (maxima) of the objective function, convergence (optim .convergence) 2. optimize returns a list with arguments minimum (or maximum) giving the estimates, objective the value of the obj. function 3. nlm returns a list with arguments minimum giving the minimum of the obj. function, minimum the estimates, code the optim. convergence 4. nlminb returns a list with arguments par (the estimates), objective, convergence (conv. code), evaluations Furthermore, optim keeps the names of the parameters while nlm, nlminb don't. s I believe it would be nice if all these optimizers have a kind of homogenized output. This will help in writing functions that can call different optimizers. Obviously, we can write our own function that homogenized the output after calling the optimizer, but I still believe this will be more user-friendly. Do you think this is a reasonable feature to implement - despite it isn't an important point? This would be essentially impossible without breaking most existing code, and in the case of optimize() and nlminb() that goes back many years to uses in S(-PLUS). Best, Mathieu * BTW, if this is relevant, I could try to do it. -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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 -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] any suggestions to deal with 'Argument list too long' for a R CMD check?
Just a suggestion. I googled for your error message you got e.g. "make ... error 127" and I got Yeah, error 127 indicates that make can't find a program that it needs to run a command. My guess would be that she doesn't have g++ installed (some distributions package it separately from gcc so it is possible to have the c compiler installed but not the c++ compiler) Maybe it will be worthwhile to check if you have installed every required header files or needed compilers/libraries. But as I mentioned, this is just a suggestion. Cheers, Mathieu Whit Armstrong a écrit : I love xargs for all kinds of stuff, but I really don't want to write my own configure script. looks like simple solution is to recombine into one big source file rather than splitting each function out. pita... -Whit On Tue, Dec 9, 2008 at 4:23 PM, Jeff Ryan <[EMAIL PROTECTED]> wrote: Never used, but I seem to recall that this was good for that: http://en.wikipedia.org/wiki/Xargs Jeff On Tue, Dec 9, 2008 at 3:13 PM, Whit Armstrong <[EMAIL PROTECTED]> wrote: Since, gcc was using upwards of 2gb of ram to compile my package, I just split all the functions into individual files. I guess I'm too clever for myself, because now I get hit with the "Argument list too long" error. Is there a way to deal with this aside from writing my own configure script (which could possibly feed the gcc commands one by one). -Whit RHEL 5 [EMAIL PROTECTED] uname -a Linux linuxsvr.kls.corp 2.6.18-92.1.18.el5 #1 SMP Wed Nov 5 09:00:19 EST 2008 x86_64 x86_64 x86_64 GNU/Linux from 00install.out: * Installing *source* package 'RFincad' ... ** libs g++ -I/usr/local/lib64/R/include -I/usr/local/include -I./RAbstraction -I./R.tslib.backend -I./tslib -fpic -g -O2 -c aaAccrual_days_act252.cpp -o aaAccrual_days_act2\ 52.o make: execvp: g++: Argument list too long make: *** [aaAccrual_days_act252.o] Error 127 ERROR: compilation failed for package 'RFincad' ** Removing '/home/whit/dvl/fincad.utils/fincad.generate.R/RFincad.Rcheck/RFincad' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan [EMAIL PROTECTED] ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
Dear Terry,
One way to locate which file is wrong - surely not the most brillant
way! You could do an R script that sources each of your .R files within
a "for (file in file.names)" loop.
When R will stop, it will indicate which file has a wrong syntax and
more info.
Cheers,
Mathieu
Terry Therneau a écrit :
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really nice
instructions about how to lay out the directories, order the files, and
run tests for DISTRIBUTION of a product, but I can't find anything on how
to set up a reasonable DEVELOPMENT environment.
In my local world, I had the .c and .s files in a common directory, with
a Makefile that I had created, and the test suite in a subdirectory. Debugging
and development was quite nice.
make
cd test
R
attach("..")
try something and perhaps it fails
q()
cd ..
Fix and repeat. The Makefile took some time to create, but paid for itself a
hundred times over.
So, I've now rearranged everything into standard R order. Then I did the
only thing I could find
R CMD INSTALL ~/myRlib survival
where "survival" is said directory. This turns out to be not useful at all.
The survival package is large, and I rather suspected that I would goof
something up, and I did, resulting in the following message
Error in parse(n = -1, file = file) : unexpected end of input at
14450: }
14451:
It is not exactly obvious which of the 132 files in my R/ directory is the
culprit here.
In general:
1. The library is large, and recompiling/reparsing everything is very far from
instantaneous. It is not the edit/load cycle I desire.
2. I take testing seriously: the test suite takes on the order of 15 minutes to
run on a fast machine. I most certainly don't want to run it in the mid cycle.
Someone must have tackled this. I'm hoping that there is some documentation
that I have managed to overlook which discussess a good setup for this middle
ground between concieving of a library and packaging it for delivery; the
"build, test, make sure it acually works" part of development.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
Dear Simone, Did mean that the legend (text and/or box) overlap with the Normal density? If so then I think there's no problem as the legend is placed where you told R to do. And R won't check (for you) if it will overlap or not with pre-existing graphical elements. On my computer, I got the expected results - if I understood correctly your issue though. For information: R version 2.8.1 (2008-12-22) Linux mathieu-laptop 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 i686 GNU/Linux (Ubuntu Intrepid) Cheers, Mathieu Simone Giannerini a écrit : Dear all, there seems to be a problem with displayed legends when a multiple figure environment is used, see the following example: par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) legend(-4,0.2,legend="curve",lty=1,col=4) On my machines the first time the command legend() is issued the legend box stretches over the curve. Subsequent calls to legend seems to produce a correct box instead. openSuse 11.0 platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Patched major 2 minor 8.1 year 2009 month 01 day07 svn rev47501 language R version.string R version 2.8.1 Patched (2009-01-07 r47501) I see this on the same version of R on Windows VISTA 32 bit as well; I do not see this behaviour on a machine with R 2.8.0. Thank you, Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] uninitialised value in R (PR#13476)
Hi Martin,
I wasn't able to compile your files. Replacing "extern "C" SEXP XXX();"
by "SEXP XXX();" solve the issue and I got no message from valgrind -
I'm not sure this is what you really want to do though.
I hope this might help.
Cheers,
Mathieu
schlat...@math.uni-goettingen.de a écrit :
Hi,
I get an "Conditional jump or move depends on uninitialised value(s)"
from valgrind when using 'solve' in combination with some simple
C-code. (I did not use other functions of R besides 'solve'.)
In detail: running
R --vanilla -d "valgrind --tool=memcheck --memcheck:leak-check=yes
--num-callers=20 "
and calling
.Call("XXX")
nd <- 3
solve(diag(nd) , as.vector(1:nd))
.Call("XXX")
gives the above valgrind message for the second call of "XXX".
Without "solve" in the middle, there is no message
from valgrind.
Best regards,
Martin
/// C source file u.cc
#include "u.h"
SEXP XXX() {
SEXP ans;
PROTECT (ans = allocVector(INTSXP, 1));
INTEGER(ans)[0] = 1;
UNPROTECT(1);
return ans;
}
/// header file u.h
#ifndef RFsimu_public_H
#define RFsimu_public_H 1
#include
#include
#include
#include
extern "C" SEXP XXX();
#endif /* RF_simu_PUBLIC_H*/
--please do not edit the information below--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status = Under development (unstable)
major = 2
minor = 9.0
year = 2009
month = 01
day = 13
svn rev = 47573
language = R
version.string = R version 2.9.0 Under development (unstable)
(2009-01-13 r47573)
Locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] uninitialised value in R (PR#13476)
Hi Martin,
Sorry I was stupid. Indeed, I named the file tom.c instead of tmp.cc.
Now with the right extension, it works with the 'extern "C"' piece of code.
However, for your (ii) point, this shouldn't be related to the omission
of 'extern "C"' but to the fact that the shared library is not loaded in R.
I used "dyn.load("tmp.so")" (or "tmp.dll" under Windows) before running
your example. With this, you should not have the message "Error in
.Call("XXX") : C symbol name "XXX" not in load table ".
It seems weired that you didn't get the message with the "extern "C"".
Is the loaded shared library the latest version of your code - i.e. I
mean that did you recompile and reload the latest version of your c++ code?
I hope this will help,
Cheers,
Mathieu
Martin Schlather a écrit :
Hi Mathieu,
Very strange.
(i) The whole package RandomFields is written with ` extern "C" '
and seems working. There is no message from valgrind
anywhere, except in two situations that I have boiled
down to the code in the bug report.
(ii) without ` extern "C" ' I get a warning plus an
error:
.Call("XXX")
==18032== Conditional jump or move depends on uninitialised value(s)
==18032==at 0x401620C: (within /lib/ld-2.8.so)
==18032==by 0x42825C3: (within /lib/libc-2.8.so)
==18032==by 0x4282989: _dl_sym (in /lib/libc-2.8.so)
==18032==by 0x417ADE7: (within /lib/libdl-2.8.so)
==18032==by 0x400DE25: (within /lib/ld-2.8.so)
==18032==by 0x417B0DB: (within /lib/libdl-2.8.so)
==18032==by 0x417AD72: dlsym (in /lib/libdl-2.8.so)
==18032==by 0x811012D: R_dlsym (Rdynload.c:787)
==18032==by 0x8110A98: R_FindSymbol (Rdynload.c:836)
==18032==by 0x816E41C: resolveNativeRoutine (dotcode.c:240)
==18032==by 0x817473A: do_dotcall (dotcode.c:825)
==18032==by 0x8194C12: Rf_eval (eval.c:487)
==18032==by 0x805B163: Rf_ReplIteration (main.c:257)
==18032==by 0x805B3E7: R_ReplConsole (main.c:306)
==18032==by 0x805B6D7: run_Rmainloop (main.c:966)
==18032==by 0x8058F80: main (Rmain.c:33)
Error in .Call("XXX") : C symbol name "XXX" not in load table
Have you named the file u.c or u.cc?
Cheers,
Martin
Mathieu Ribatet wrote:
Hi Martin,
I wasn't able to compile your files. Replacing "extern "C" SEXP XXX();"
by "SEXP XXX();" solve the issue and I got no message from valgrind -
I'm not sure this is what you really want to do though.
I hope this might help.
Cheers,
Mathieu
schlat...@math.uni-goettingen.de a écrit :
Hi,
I get an "Conditional jump or move depends on uninitialised value(s)"
from valgrind when using 'solve' in combination with some simple
C-code. (I did not use other functions of R besides 'solve'.)
In detail: running
R --vanilla -d "valgrind --tool=memcheck --memcheck:leak-check=yes
--num-callers=20 "
and calling
.Call("XXX")
nd <- 3
solve(diag(nd) , as.vector(1:nd))
.Call("XXX")
gives the above valgrind message for the second call of "XXX".
Without "solve" in the middle, there is no message
from valgrind.
Best regards,
Martin
/// C source file u.cc
#include "u.h"
SEXP XXX() {
SEXP ans;
PROTECT (ans = allocVector(INTSXP, 1));
INTEGER(ans)[0] = 1;
UNPROTECT(1);
return ans;
}
/// header file u.h
#ifndef RFsimu_public_H
#define RFsimu_public_H 1
#include
#include
#include
#include
extern "C" SEXP XXX();
#endif /* RF_simu_PUBLIC_H*/
--please do not edit the information below--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status = Under development (unstable)
major = 2
minor = 9.0
year = 2009
month = 01
day = 13
svn rev = 47573
language = R
version.string = R version 2.9.0 Under development (unstable)
(2009-01-13 r47573)
Locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behavior of C compiled program
Hi Christophe,
The problem might be that you used %d when printing. I guess that your
variables dist and tmp are double so you have to use %f instead.
Best,
Mathieu
Le dimanche 08 février 2009 à 23:37 +0100, Christophe Genolini a écrit :
> Hi the list,
>
> I need to include some C code in R, but the behavior of the C code is
> strange : Here is my code :
> --- 8< ---
> Rprintf("\n mTraj=%f
> mClus=%f",mTraj[i+nbId*c],mClustersCenter[j+nbClusters*c]);
>
> Rprintf("\nDistA=%d Tmp=%d",dist,tmp);
> tmp = mTraj[i+nbId* c] - mClustersCenter [j+nbClusters* c];
>
> Rprintf("\nDistB=%d Tmp=%d",dist,tmp);
> dist += (tmp * tmp);
>
> Rprintf("\nDistC=%d Tmp=%d",dist,tmp);
> --- 8<
>
> Herer are the stranges results it gives :
>
> mTraj=1.00 mClus=3.00
> DistA=0 Tmp=0
> DistB=0 Tmp=0
> DistC=0 Tmp=1074790400
>
> I ask on a C chat, but no one can answer me.
> Any idea of what wrong ?
>
> Thanks
> Christophe
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behavior of C compiled program
You might have a look at the "Writing R Extensions" manual - especially
valgrind and/or gdb.
By the way, your error is probably due to array size problem - i.e. tmp
is of size n and you call tmp[n+1] for example. Valgrind will detect in
automagically for you.
Best,
Mathieu
Le lundi 09 février 2009 à 10:05 +0100, Christophe Genolini a écrit :
> Thanks, that was a stupid mistake (I did not know that this is so
> important).
>
> So I still have a problem realy more complex and I do not know was is
> wrong. I am running a .C procedure in a R loop.
> After 4, 5 or sometimes 6 call to the C procedure, Rgui crash (it closes
> asking me if I want to send a report to Microsoft).
> Is there a debuger that can run the C code with some R in it ? And what
> kind of mistake can provoque such a crash ?
>
> Thanks
> Christophe
>
>
> So I thaught that I find t
> > On 08/02/2009 5:37 PM, Christophe Genolini wrote:
> >> Hi the list,
> >>
> >> I need to include some C code in R, but the behavior of the C code is
> >> strange : Here is my code :
> >> --- 8< ---
> >> Rprintf("\n mTraj=%f
> >> mClus=%f",mTraj[i+nbId*c],mClustersCenter[j+nbClusters*c]);
> >>
> >> Rprintf("\nDistA=%d Tmp=%d",dist,tmp);
> >> tmp = mTraj[i+nbId* c] - mClustersCenter [j+nbClusters* c];
> >>
> >> Rprintf("\nDistB=%d Tmp=%d",dist,tmp);
> >> dist += (tmp * tmp);
> >>
> >> Rprintf("\nDistC=%d Tmp=%d",dist,tmp);
> >> --- 8<
> >>
> >> Herer are the stranges results it gives :
> >>
> >> mTraj=1.00 mClus=3.00
> >> DistA=0 Tmp=0
> >> DistB=0 Tmp=0
> >> DistC=0 Tmp=1074790400
> >>
> >> I ask on a C chat, but no one can answer me.
> >> Any idea of what wrong ?
> >
> > You likely have the wrong types for the variables you're printing. In
> > C, the format has to match the type of the variable; if you use the
> > wrong one, you get garbage.
> >
> > Duncan Murdoch
> >
>
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R does not start on my MacBook Pro3,1 (PR#13565)
I'm not sure this will work under MacOS but you should try to run R from a shell and see any informative message displayed in it. Cheers, Mathieu * it might be useful to give us some details about the code you ran and caused the issue. Le lundi 02 mars 2009 à 17:15 +0100, marycme...@mac.com a écrit : > Help! I was running R code and started getting error messages that > would not stop repeating. I force-quit R, but when I attempted to run > it again, it would not start (Icon kept bouncing until I force-quit > again). I restarted the computer, then I reinstalled R, but that did > not fix the problem. I deleted everything I could find related to R, > and installed again. Each time I install I get a "successful" message, > but it does not start. I don't know what to try next. > > I have the latest versions of the operating system. > > Thanks very much for your time. > > Sincerely, > Mary Meyer > Statistics Department > Colorado State University > > me...@stat.colostate.edu > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hello! I got error in C - R
Dear Ick Hoon Jin,
Your problem is probably due to a misspecification in memory allocation
within your C code. To solve this you can:
* check by yourself whenever there is C memory allocation - by the
way I think it's best to use R memory allocation i.e. R_alloc
* use valgrind (see Writing R extension for this) as you're under
Linux and this will give you some guidance to find where the
problem is.
Best,
Mathieu
Le vendredi 03 avril 2009 à 03:47 +0200, kent...@stat.tamu.edu a écrit :
> Hello,
> My name is Ick Hoon Jin and I am Ph. D. student in Texas A & M Univ..
> When I run the C embedded in R in the Linux system, I confront the
> following error after 6,000 iteration. By googling I found this error is
> from the problem in C.
>
> *** caught segfault ***
> address (nil), cause 'memory not mapped'
>
> My C code is following:
>
> ---
> #include
> #include
> #include
> #include
> #include
>
> #define Min(X,Y) ((X) < (Y) ? (X) : (Y))
>
> void SecondMH(int *n, int *X, int *length_X, double *theta_new, int
> *n_para, double *out);
> int MH_Result(double *theta_new, int n_para, int *M1, int *M2, int n);
> double Count_Edges(int *X, int n);
> double Cal_GWD(int *X, int n);
> int Cal_Degree(int *M3, int n);
> double Inner_Product( double *vector1, double *vector2, int length);
> int rdtsc();
>
> void SecondMH(int *n, int *X, int *length_X, double *theta_new, int
> *n_para, double *out)
> {
> int i, j, a, k;
> int *M1, *M2;
> M1 = (int *)calloc(*length_X, sizeof(int));
> M2 = (int *)calloc(*length_X, sizeof(int));
>
> for(i = 1; i < *n; i++)
> {
> for(j = 0; j < i; j++)
> {
> for(k = 0; k < *length_X; k++ )
> {
> M1[k] = X[k];
> M2[k] = X[k];
> }
>
> if(X[i * *n + j] == 1)
> {
> M1[i * *n + j] = 0;
> a = MH_Result(theta_new, *n_para, M1, M2, *n);
> if(a == 1)
> {
> X[i * *n + j] = 0;
> }
> }
> else
> {
> M1[i * *n + j] = 1;
> a = MH_Result(theta_new, *n_para, M1, M2, *n);
> if(a == 1)
> {
> X[i * *n + j] = 1;
> }
> }
> }
> }
>
> for(i = 1; i < *n; i++)
> {
> for(j = 0; j < i; j++)
> {
> X[j * *n + i] = 0;
> }
> }
>
> for(i = 0; i < *length_X; i++)
> {
> out[i] = (double)X[i];
> }
>
> free(M1);
> free(M2);
>
> return;
> }
>
> int MH_Result(double *theta_new, int n_para, int *M1, int *M2, int n)
> {
> double *M1_STAT, *M2_STAT;
> double pi_Num, pi_Denom, MH_Ratio, v;
>
> M1_STAT = (double *)calloc( n_para, sizeof( double ) );
> M2_STAT = (double *)calloc( n_para, sizeof( double ) );
>
> M1_STAT[0] = Count_Edges(M1, n);
> M2_STAT[0] = Count_Edges(M2, n);
>
> M1_STAT[1] = Cal_GWD(M1, n);
> M2_STAT[1] = Cal_GWD(M2, n);
>
> pi_Num = Inner_Product(theta_new, M1_STAT, n_para);
> pi_Denom = Inner_Product(theta_new, M2_STAT, n_para);
> MH_Ratio = pi_Num - pi_Denom;
>
> srand(rdtsc());
> v = (double)rand() / ( (double)RAND_MAX + (double)1 );
>
> if( log( v ) < Min( 0, MH_Ratio ) )
> return 1;
> else
> return 0;
>
> free(M1_STAT);
> free(M2_STAT);
> }
>
> double Count_Edges(int *X, int n)
> {
> double temp;
> int i, j;
>
> temp = 0;
>
> for(i = 1; i < n; i++)
> {
> for(j = 0; j < i; j++)
> {
> temp += X[i * n + j];
> }
> }
>
> return temp;
> }
>
> double Cal_GWD(int *X, int n)
> {
>
> int *M3, *Degree, *D_Y;
> int i, j;
> double theta = 0.25;
> double GWD = 0.00;
>
> M3 = (int *)calloc(n, sizeof(int));
> Degree = (int *)calloc(n, sizeof(int));
> D_Y = (int *)calloc((n - 1), sizeof(int));
>
> for(i = 0; i < n; i++)
> {
> for(j = 0; j < n; j++)
> {
> M3[j] = X[i * n + j];
> }
>
> Degree[i] = Cal_Degree(M3, n);
> }
>
> for(i = 0; i < n - 1; i++)
> {
> D_Y[i] = 0;
>
> for(j = 0; j < n; j++)
> {
> if(Degree[j] = i
Re: [Rd] 'is.integer' (PR#13671)
To the best of my knowledge this is not a bug. According to FAQ 3.3.3 "Numeric constants with no fractional and exponent (i.e., only integer) part are taken as integer in S-Plus 6.x or later, but as double in R." You can see it by invoking >storage.mode(1) [1] "double" Hence, if you really want to have integers, you need to use as.integer i.e. > storage.mode(as.integer(1)) [1] "integer" Cheers, Mathieu Le mercredi 22 avril 2009 à 19:45 +0200, hzambran.newsgro...@gmail.com a écrit : > Full_Name: Mauricio > Version: 2.9.0 (2009-04-17) > OS: i486-pc-linux-gnu > Submission from: (NULL) (193.205.203.3) > > > This is a very simple function that seems not to be working, according to the > definition given by '?is.integer'. > > I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't > find any related message. > > The possible problem is: > > > > is.integer(1) > [1] FALSE > > and 1 is obviously an integer value. > > > I would really appreciate if you could clarify if this is really a bug or not. > > Thanks in advance, > > Mauricio > > > version >_ > platform i486-pc-linux-gnu > arch i486 > os linux-gnu > system i486, linux-gnu > status > major 2 > minor 9.0 > year 2009 > month 04 > day17 > svn rev48333 > language R > version.string R version 2.9.0 (2009-04-17) > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
