Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 23/09/2009 11:21 PM, Gabor Grothendieck wrote:
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch wrote:
- Ways to link from man pages to vignettes. The reverse would be nice, but
it's not possible with the current design, so that would be far off.
If feasible I would like to be able to link to any text, html or pdf
file in the package. For example, it would be nice to be able to link
to the NEWS file and pdf files that are included in the package even
if they are not vignettes, etc.
The \Sexpr mechanism probably allows this, though there are currently no
built-in support functions to help you get there. As I mentioned, that
could all be done by code in a contributed package.
One way would be to have one help page which contains only
\Sexpr[stage=render, results=rd]{generatePage()}
and it will be 100% generated at render time, containing whatever you
want it to contain. (Presumably you'll have some way to communicate
what you want through variables that generatePage() can see.) Each time
you link to it you'll see something different.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 09/24/2009 11:28 AM, Duncan Murdoch wrote:
On 23/09/2009 11:21 PM, Gabor Grothendieck wrote:
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch
wrote:
- Ways to link from man pages to vignettes. The reverse would be
nice, but
it's not possible with the current design, so that would be far off.
If feasible I would like to be able to link to any text, html or pdf
file in the package. For example, it would be nice to be able to link
to the NEWS file and pdf files that are included in the package even
if they are not vignettes, etc.
The \Sexpr mechanism probably allows this, though there are currently no
built-in support functions to help you get there. As I mentioned, that
could all be done by code in a contributed package.
One way would be to have one help page which contains only
\Sexpr[stage=render, results=rd]{generatePage()}
and it will be 100% generated at render time, containing whatever you
want it to contain. (Presumably you'll have some way to communicate what
you want through variables that generatePage() can see.) Each time you
link to it you'll see something different.
Duncan Murdoch
Brilliant. Thanks. That solves my question as well.
I did not see results = documented in ?Rd2HTML, what is allowed ?
Is \Sexpr ignored when rendering other formats (tex, ...) ?
or is there a way (similar to #ifdef) to only provide some content to
some renderers ?
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
|- http://tr.im/yw8E : New R package : sos
`- http://tr.im/y8y0 : search the graph gallery from R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 24/09/2009 5:42 AM, Romain Francois wrote:
On 09/24/2009 11:28 AM, Duncan Murdoch wrote:
On 23/09/2009 11:21 PM, Gabor Grothendieck wrote:
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch
wrote:
- Ways to link from man pages to vignettes. The reverse would be
nice, but
it's not possible with the current design, so that would be far off.
If feasible I would like to be able to link to any text, html or pdf
file in the package. For example, it would be nice to be able to link
to the NEWS file and pdf files that are included in the package even
if they are not vignettes, etc.
The \Sexpr mechanism probably allows this, though there are currently no
built-in support functions to help you get there. As I mentioned, that
could all be done by code in a contributed package.
One way would be to have one help page which contains only
\Sexpr[stage=render, results=rd]{generatePage()}
and it will be 100% generated at render time, containing whatever you
want it to contain. (Presumably you'll have some way to communicate what
you want through variables that generatePage() can see.) Each time you
link to it you'll see something different.
Duncan Murdoch
Brilliant. Thanks. That solves my question as well.
I did not see results = documented in ?Rd2HTML, what is allowed ?
Is \Sexpr ignored when rendering other formats (tex, ...) ?
or is there a way (similar to #ifdef) to only provide some content to
some renderers ?
As of yesterday, it's documented in Writing R Extensions. \Sexpr is
format-agnostic: it doesn't output HTML, it outputs plain text which is
wrapped in the appropriate HTML/LaTeX/whatever, or Rd input which is
processed by the whole system. So the generator would currently have to
use sneaky methods to figure out the format, looking at which function
called it, etc. I imagine in the long run we'll define some state
variables which the code can look at, but I'd rather see use-cases
before deciding what those should be.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash due to extreme example
Now fixed, in R-devel and R-patched.
Duncan Murdoch
On 23/09/2009 7:10 PM, Saptarshi Guha wrote:
Hello,
I was trying this bit of code (i know it is an extreme case)
g=function(r){
if(r==1)
return(list(x=1))
else
return(list(x=g(r-1)))
}
For z=g(500), the code runs but when I print z i.e
>> z
I get
*** caught bus error ***
address 0x1, cause 'non-existent physical address'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
Running on Leopard, Macbook (intel, 4gb ram)
R version 2.9.2 (2009-08-24)
(No libraries loaded)
Saptarshi Guha | saptarshi.g...@gmail.com | http://www.stat.purdue.edu/~sguha
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 09/24/2009 12:04 PM, Duncan Murdoch wrote:
>
> On 24/09/2009 5:42 AM, Romain Francois wrote:
>> On 09/24/2009 11:28 AM, Duncan Murdoch wrote:
>>> On 23/09/2009 11:21 PM, Gabor Grothendieck wrote:
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch
wrote:
> - Ways to link from man pages to vignettes. The reverse would be
> nice, but
> it's not possible with the current design, so that would be far off.
>
If feasible I would like to be able to link to any text, html or pdf
file in the package. For example, it would be nice to be able to link
to the NEWS file and pdf files that are included in the package even
if they are not vignettes, etc.
>>> The \Sexpr mechanism probably allows this, though there are
currently no
>>> built-in support functions to help you get there. As I mentioned, that
>>> could all be done by code in a contributed package.
>>>
>>> One way would be to have one help page which contains only
>>>
>>> \Sexpr[stage=render, results=rd]{generatePage()}
>>>
>>> and it will be 100% generated at render time, containing whatever you
>>> want it to contain. (Presumably you'll have some way to communicate
what
>>> you want through variables that generatePage() can see.) Each time you
>>> link to it you'll see something different.
>>>
>>> Duncan Murdoch
>>
>> Brilliant. Thanks. That solves my question as well.
>>
>> I did not see results = documented in ?Rd2HTML, what is allowed ?
>> Is \Sexpr ignored when rendering other formats (tex, ...) ?
>> or is there a way (similar to #ifdef) to only provide some content to
>> some renderers ?
>
> As of yesterday, it's documented in Writing R Extensions. \Sexpr is
> format-agnostic: it doesn't output HTML, it outputs plain text which is
> wrapped in the appropriate HTML/LaTeX/whatever, or Rd input which is
> processed by the whole system. So the generator would currently have to
> use sneaky methods to figure out the format, looking at which function
> called it, etc. I imagine in the long run we'll define some state
> variables which the code can look at, but I'd rather see use-cases
> before deciding what those should be.
>
> Duncan Murdoch
Sure. One last thing, can the \Sexpr trigger some code that redirects to
some other page ? I suppose one could just call browseURL, but this
would bring another tab, ...
Do I need to depend on R >= 2.10.0 if I use \Sexpr ?
Gabor, would you like to team up to generate some sort of incubator
package to take advantage of the new system ?
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
|- http://tr.im/yw8E : New R package : sos
`- http://tr.im/y8y0 : search the graph gallery from R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 24/09/2009 6:29 AM, Romain Francois wrote:
On 09/24/2009 12:04 PM, Duncan Murdoch wrote:
>
> On 24/09/2009 5:42 AM, Romain Francois wrote:
>> On 09/24/2009 11:28 AM, Duncan Murdoch wrote:
>>> On 23/09/2009 11:21 PM, Gabor Grothendieck wrote:
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch
wrote:
> - Ways to link from man pages to vignettes. The reverse would be
> nice, but
> it's not possible with the current design, so that would be far off.
>
If feasible I would like to be able to link to any text, html or pdf
file in the package. For example, it would be nice to be able to link
to the NEWS file and pdf files that are included in the package even
if they are not vignettes, etc.
>>> The \Sexpr mechanism probably allows this, though there are
currently no
>>> built-in support functions to help you get there. As I mentioned, that
>>> could all be done by code in a contributed package.
>>>
>>> One way would be to have one help page which contains only
>>>
>>> \Sexpr[stage=render, results=rd]{generatePage()}
>>>
>>> and it will be 100% generated at render time, containing whatever you
>>> want it to contain. (Presumably you'll have some way to communicate
what
>>> you want through variables that generatePage() can see.) Each time you
>>> link to it you'll see something different.
>>>
>>> Duncan Murdoch
>>
>> Brilliant. Thanks. That solves my question as well.
>>
>> I did not see results = documented in ?Rd2HTML, what is allowed ?
>> Is \Sexpr ignored when rendering other formats (tex, ...) ?
>> or is there a way (similar to #ifdef) to only provide some content to
>> some renderers ?
>
> As of yesterday, it's documented in Writing R Extensions. \Sexpr is
> format-agnostic: it doesn't output HTML, it outputs plain text which is
> wrapped in the appropriate HTML/LaTeX/whatever, or Rd input which is
> processed by the whole system. So the generator would currently have to
> use sneaky methods to figure out the format, looking at which function
> called it, etc. I imagine in the long run we'll define some state
> variables which the code can look at, but I'd rather see use-cases
> before deciding what those should be.
>
> Duncan Murdoch
Sure. One last thing, can the \Sexpr trigger some code that redirects to
some other page ? I suppose one could just call browseURL, but this
would bring another tab, ...
Do I need to depend on R >= 2.10.0 if I use \Sexpr ?
I think so.
Duncan Murdoch
Gabor, would you like to team up to generate some sort of incubator
package to take advantage of the new system ?
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 24/09/2009 7:30 AM, Duncan Murdoch wrote:
On 24/09/2009 6:29 AM, Romain Francois wrote:
On 09/24/2009 12:04 PM, Duncan Murdoch wrote:
>
> On 24/09/2009 5:42 AM, Romain Francois wrote:
>> On 09/24/2009 11:28 AM, Duncan Murdoch wrote:
>>> On 23/09/2009 11:21 PM, Gabor Grothendieck wrote:
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch
wrote:
> - Ways to link from man pages to vignettes. The reverse would be
> nice, but
> it's not possible with the current design, so that would be far off.
>
If feasible I would like to be able to link to any text, html or pdf
file in the package. For example, it would be nice to be able to link
to the NEWS file and pdf files that are included in the package even
if they are not vignettes, etc.
>>> The \Sexpr mechanism probably allows this, though there are
currently no
>>> built-in support functions to help you get there. As I mentioned, that
>>> could all be done by code in a contributed package.
>>>
>>> One way would be to have one help page which contains only
>>>
>>> \Sexpr[stage=render, results=rd]{generatePage()}
>>>
>>> and it will be 100% generated at render time, containing whatever you
>>> want it to contain. (Presumably you'll have some way to communicate
what
>>> you want through variables that generatePage() can see.) Each time you
>>> link to it you'll see something different.
>>>
>>> Duncan Murdoch
>>
>> Brilliant. Thanks. That solves my question as well.
>>
>> I did not see results = documented in ?Rd2HTML, what is allowed ?
>> Is \Sexpr ignored when rendering other formats (tex, ...) ?
>> or is there a way (similar to #ifdef) to only provide some content to
>> some renderers ?
>
> As of yesterday, it's documented in Writing R Extensions. \Sexpr is
> format-agnostic: it doesn't output HTML, it outputs plain text which is
> wrapped in the appropriate HTML/LaTeX/whatever, or Rd input which is
> processed by the whole system. So the generator would currently have to
> use sneaky methods to figure out the format, looking at which function
> called it, etc. I imagine in the long run we'll define some state
> variables which the code can look at, but I'd rather see use-cases
> before deciding what those should be.
>
> Duncan Murdoch
Sure. One last thing, can the \Sexpr trigger some code that redirects to
some other page ? I suppose one could just call browseURL, but this
would bring another tab, ...
Sorry, I missed this. The answer is no, not currently, but it could
generate a link for the user to manually navigate there.
Duncan Murdoch
Do I need to depend on R >= 2.10.0 if I use \Sexpr ?
I think so.
Duncan Murdoch
Gabor, would you like to team up to generate some sort of incubator
package to take advantage of the new system ?
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R + C + Lapack toy regression example
On Wed, Sep 23, 2009 at 2:39 AM, Vinh Nguyen wrote:
> dear list,
>
> since matrix manipulations is often of interest in statistical
> computations, i'd like to get a working example of using Lapack for
> regression. However, i run into an error.
>
> My matrix-lapack-example.c file:
> #include
>
> void reg(const char* trans, const int* m, const int* n,
> const int* nrhs, double* a, const int* lda,
> double* b, const int* ldb,
> double* work, const int* lwork, int* info)
> {
> F77_CALL(dgels)(trans, m, n, nrhs, a, lda, b, ldb, work, lwork, info);
> }
>
> My matrix-lapack-example.R file:
> dyn.load( "matrix-lapack-example.so" )
>
> regression <- function( X, Y ){
> m <- nrow( X )
> n <- ncol( X )
> stopifnot( m >= n , is.vector( Y ), n != length( Y ) )
> mn <- min( m, n )
> lwork <- mn + max( mn, 1 )
> ### to be used with dgels
> ### http://www.netlib.org/lapack/double/dgels.f
> rslt <- .C( "reg"
> , trans=as.character( "N" )
In your C code you are treating that object as a C character string
(char*) but that is not what is being passed. Look at section 5.2 of
"Writing R Extensions" - a character variable in R is passed by .C as
a char**, not a char*.
I find it much easier to use the .Call interface instead of the .C
interface for applications like this. You do need to learn some of
the mysteries of the functions declared in Rinternals.h but, once you
do, it is much easier to pass a matrix from R with and extract all the
fussy details within the C code. Several of the C source code files
in the Matrix package are devoted to exactly the kind of operation you
want to carry out. Look at the function lsq_dense_QR in
Matrix/src/dense.c, for example. (Although now that I look at it
myself I see some questionable programming practices - I should have
PROTECTed the result of coerceVector but it happens that it would not
have needed protection. Rather than coercing I should just check
isInteger on the dim attribute.)
> , m=as.integer( m ), n=as.integer( n )
> , nrhs=as.integer( 1 ), a=as.double( X )
> , lda=as.integer( m ), b=as.double( Y )
> , ldb=as.integer( m ) , work=double( lwork )
> , lwork=as.integer( lwork )
> , info=integer( 1 ) )
> ##F77_NAME(dgels)(const char* trans, const int* m, const int* n,
> ## const int* nrhs, double* a, const int* lda,
> ## double* b, const int* ldb,
> ## double* work, const int* lwork, int* info);
> return( rslt )
> }
>
> n <- 100
> x <- rnorm( 100 )
> y <- 2.5 + 3*x + rnorm( n )
> X <- cbind( 1, x )
>
> temp <- regression( X=X, Y=y )
>
>
> dgels does linear least squares. the C code compile fines with a
> warning (ld: warning, duplicate dylib
> /usr/local/lib/libgcc_s.1.dylib). in R, i get the following when i
> run regression():
>> temp <- regression( X=X, Y=y )
> Parameter 1 to routine DGELS was incorrect
> Mac OS BLAS parameter error in DGELS , parameter #0, (unavailable), is 0
>
> Process R exited abnormally with code 1 at Wed Sep 23 00:21:59 2009
>
> am i doing something wrong? is my as.character() used wrong here?
>
> i know R uses fortran code for lm. but suppose i wanted to do
> regression in C/C++. is this lapack method the recommended / "best
> practice" route? i just want to know whats the recommended method for
> doing matrix manipulations in C. thanks!
>
> vinh
>
> __
> 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] Crash due to extreme example
Thanks.
What caused problem?
Regards
Saptarshi
On Thu, Sep 24, 2009 at 6:20 AM, Duncan Murdoch wrote:
> Now fixed, in R-devel and R-patched.
>
> Duncan Murdoch
>
> On 23/09/2009 7:10 PM, Saptarshi Guha wrote:
>>
>> Hello,
>> I was trying this bit of code (i know it is an extreme case)
>>
>> g=function(r){
>> if(r==1)
>> return(list(x=1))
>> else
>> return(list(x=g(r-1)))
>> }
>>
>> For z=g(500), the code runs but when I print z i.e
>> >> z
>> I get
>>
>>
>> *** caught bus error ***
>> address 0x1, cause 'non-existent physical address'
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>>
>> Running on Leopard, Macbook (intel, 4gb ram)
>> R version 2.9.2 (2009-08-24)
>>
>>
>> (No libraries loaded)
>>
>> Saptarshi Guha | saptarshi.g...@gmail.com |
>> http://www.stat.purdue.edu/~sguha
>>
>> __
>> 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] Crash due to extreme example
On 9/24/2009 11:00 AM, Saptarshi Guha wrote:
Thanks.
What caused problem?
R builds up the element name (x$x$x ...) in a fixed size buffer. There
was code to detect when the buffer was full and stop building the name,
but it was buggy. I patched the bug.
Duncan Murdoch
Regards
Saptarshi
On Thu, Sep 24, 2009 at 6:20 AM, Duncan Murdoch wrote:
Now fixed, in R-devel and R-patched.
Duncan Murdoch
On 23/09/2009 7:10 PM, Saptarshi Guha wrote:
Hello,
I was trying this bit of code (i know it is an extreme case)
g=function(r){
if(r==1)
return(list(x=1))
else
return(list(x=g(r-1)))
}
For z=g(500), the code runs but when I print z i.e
>> z
I get
*** caught bus error ***
address 0x1, cause 'non-existent physical address'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
Running on Leopard, Macbook (intel, 4gb ram)
R version 2.9.2 (2009-08-24)
(No libraries loaded)
Saptarshi Guha | saptarshi.g...@gmail.com |
http://www.stat.purdue.edu/~sguha
__
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
Re: [Rd] R + C + Lapack toy regression example
thank you William Dunlap and professor Bates for your responses. Since the first argument is always an "N" for linear regression, i just placed const char* trans = "N"; in my .c file and things worked. See some comments below. On Thu, Sep 24, 2009 at 5:50 AM, Douglas Bates wrote: > In your C code you are treating that object as a C character string > (char*) but that is not what is being passed. Look at section 5.2 of > "Writing R Extensions" - a character variable in R is passed by .C as > a char**, not a char*. > so i suppose you can't get char* from R? i tried as.raw and that didn't work either. > I find it much easier to use the .Call interface instead of the .C > interface for applications like this. You do need to learn some of > the mysteries of the functions declared in Rinternals.h but, once you > do, it is much easier to pass a matrix from R with and extract all the > fussy details within the C code. Several of the C source code files > in the Matrix package are devoted to exactly the kind of operation you > want to carry out. Look at the function lsq_dense_QR in > Matrix/src/dense.c, for example. (Although now that I look at it > myself I see some questionable programming practices - I should have > PROTECTed the result of coerceVector but it happens that it would not > have needed protection. Rather than coercing I should just check > isInteger on the dim attribute.) So if someone were to re-implement linear regression using C/C++ and not fortran, would u imagine it being implemented via the .C() function and using Lapack? Or how would the matrix manipulations be handled in C? Thanks. Vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R + C + Lapack toy regression example
On Thu, Sep 24, 2009 at 11:49 AM, Simon Urbanek wrote: > As Doug pointed out you don't want to be using .C(). As for matrix > manipulations - they are usually done directly on the objects which are > vectors stored in column-major order. i meant .Call(). also, sorry for the poor word choice, i meant matrix computations, not matrix manipulations. i guess i just want some recommendations for future references on what C library to use if i were doing something like re-implement linear regression (hypothetically speaking). i assumed it would be lapack. is this the recommended approach? vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected behavior of `[<-` method for class unit.arithmetic
Dear list,
Consider the following,
library(grid)
w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = w + unit(1, "mm")
w[2] <- 0
w2[2] <- 0
convertUnit(w, "mm")
#[1] 25.4mm 0mm
convertUnit(w2, "mm")
#Error in grid.Call("L_convert", x, as.integer(whatfrom),
as.integer(whatto), :
# INTEGER() can only be applied to a 'integer', not a 'NULL'
The last line fails, as the naive replacement has destroyed the
structure of w2 instead of having assigned a value of 0 to the second
unit element.
I've also tried,
w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = w + unit(1, "mm")
w2[[2]][2] <- 0
but this time, if the structure is licit, it's the result that's not
as I intended:
convertUnit(w2,"mm")
#[1] 26.4mm 1mm
My limited understanding is that an object of class unit.arithmetic is
waiting until the last moment to actually perform its operation,
stored in a tree-like structure. With this premise, I can't think of a
good way to modify one element of a list of unit elements.
As a workaround, I can only think of the following hack where the
objects are forced to be evaluated,
w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = convertUnit(w + unit(1, "mm"), "mm", valueOnly=TRUE)
w2[2] <- 0
w2 <- unit(w2, "mm")
but it clearly isn't a very desirable route.
What is the recommended way to modify one element of a unit vector?
Digging in grid/R/unit.R , I found the following comment,
# Write "[<-.unit" methods too ??
which probably explains the above. Would it be possible to add such a method,
"[<-.unit.list" <- function(x, index, value, top=TRUE, ...) {
this.length <- length(x)
index <- (1L:this.length)[index]
if (top && any(index > this.length))
stop("Index out of bounds (unit list subsetting)")
cl <- class(x)
result <- unclass(x)
result[(index - 1) %% this.length + 1] <- value
class(result) <- cl
result
}
a = unit.c(unit(1,"mm"),unit(2,"in"))
a[2] <- unit(3,"in")
a
but for unit.arithmetic also?
Regards,
baptiste
sessionInfo()
R version 2.9.2 (2009-08-24)
i386-apple-darwin8.11.1
locale:
en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] speedup approxfun (code suggestion)
Dear R developers,
this e-mail concerns a code suggestion to slightly change approxfun, so
that it is more efficient when called several times.
We are using approxfun (not approx) to update external variables
(time-series) to current time points while integrating our ODE models.
It is not uncommon for these models to take in the order of 10^4 time
steps, and sometimes we run a model > 1000 times, so approxfun is called
many-many times. For such applications approxfun is a serious
performance bottleneck, so we first tried to develop own functions with
less overhead.
Then, one of us (Karline Soetart) noticed, that in the C-code of
R_approx, each time approxfun is called, it checks the input data for
NAs in the x and y, as well as the validity of the method and f.
For common data sets this takes about 40% of the computation time.
While testing is of course necessary for "approx", we think that for
"approxfun", testing could be done only once, before the function is
created.
Testing validity of the input only once, makes approxfun about 40-45%
faster, e.g. for:
x <- seq(0, 1)
y <- x*2
F1<- approxfun(x, y)
system.time(
for ( i in 1:1)
F1(i)
)
5.50 sec for the original approxfun
2.97 sec for the patched version
This is of course just a suggestion, but we think that a patch for
package "stats" may be of general interest and therefore more
appropriate than providing a modified approxfun in our own package.
The code suggestion was tested with R-devel rev. 49803 and several
contributed packages and we found no negative side effects. Please find
the suggested patch below and please excuse if we overlooked something.
Thanks for your consideration
Best wishes,
Karline Soetaert & Thomas Petzoldt
Index: R/approx.R
===
--- R/approx.R (revision 49817)
+++ R/approx.R (working copy)
@@ -114,10 +114,19 @@
force(f)
stopifnot(length(yleft) == 1, length(yright) == 1, length(f) == 1)
rm(o, rule, ties)
-function(v) .C("R_approx", as.double(x), as.double(y), as.integer(n),
- xout = as.double(v), as.integer(length(v)),
- as.integer(method), as.double(yleft), as.double(yright),
- as.double(f), NAOK = TRUE, PACKAGE = "stats")$xout
+
+## Changed here:
+## suggestion:
+# 1. Test input consistency once
+.C("R_approxtest",as.double(x), as.double(y), as.integer(n),
+as.integer(method), as.double(f), NAOK = TRUE,
+PACKAGE = "stats")
+
+# 2. Create and return function that does not test input validity...
+function(v) .C("R_approxfun", as.double(x), as.double(y), as.integer(n),
+xout = as.double(v), as.integer(length(v)), as.integer(method),
+as.double(yleft), as.double(yright), as.double(f), NAOK = TRUE,
+PACKAGE = "stats")$xout
}
### This is a `variant' of approx( method = "constant" ) :
Index: src/approx.c
===
--- src/approx.c(revision 49789)
+++ src/approx.c(working copy)
@@ -128,3 +128,44 @@
if(!ISNA(xout[i]))
xout[i] = approx1(xout[i], x, y, *nxy, &M);
}
+
+/* Testing done only once - in a separate function */
+void R_approxtest(double *x, double *y, int *nxy,
+ int *method, double *f)
+{
+int i;
+
+switch(*method) {
+ case 1: /* linear */
+ break;
+ case 2: /* constant */
+ if(!R_FINITE(*f) || *f < 0 || *f > 1)
+ error(_("approx(): invalid f value"));
+ break;
+ default:
+ error(_("approx(): invalid interpolation method"));
+ break;
+ }
+/* check interpolation method */
+ for(i=0 ; i<*nxy ; i++)
+ if(ISNA(x[i]) || ISNA(y[i]))
+ error(_("approx(): attempted to interpolate NA values"));
+}
+
+/* R Frontend for Linear and Constant Interpolation, no testing */
+
+void R_approxfun(double *x, double *y, int *nxy, double *xout, int *nout,
+ int *method, double *yleft, double *yright, double *f)
+{
+int i;
+appr_meth M = {0.0, 0.0, 0.0, 0.0, 0}; /* -Wall */
+
+M.f2 = *f;
+M.f1 = 1 - *f;
+M.kind = *method;
+M.ylow = *yleft;
+M.yhigh = *yright;
+for(i=0 ; i < *nout; i++)
+ if(!ISNA(xout[i]))
+xout[i] = approx1(xout[i], x, y, *nxy, &M);
+}
Index: src/init.c
===
--- src/init.c (revision 49789)
+++ src/init.c (working copy)
@@ -67,6 +67,8 @@
static R_NativePrimitiveArgType band_den_bin_t[] = {INTSXP, INTSXP, REALSXP,
REALSXP, INTSXP};
static R_NativePrimitiveArgType R_approx_t[] = {REALSXP, REALSXP, INTSXP,
REALSXP, INTSXP, INTSXP, REALSXP, REALSXP, REALSXP};
+static R_NativePrimitiveArgType R_approxtest_t[] = {REALSXP, REALSXP, INTSXP,
INTSXP, REALSXP};
+static R_NativePrimitiveArgType R_approxfun_t[] = {REALSXP, REALSXP, INTSXP,
REALSXP, I
[Rd] crash with NAs in subscripted assignment of a raw vector
Hi,
> x <- charToRaw("ABCDEFGx")
> x[c(1:3, NA, 6)] <- x[8]
*** caught segfault ***
address 0x8402423f, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Cheers,
H.
> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-09-02 r49537)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behavior of `[<-` method for class unit.arithmetic
Hi
The bit you found that says ...
# Write "[<-.unit" methods too ??
... is the crucial bit.
Would it be possible to add such a method?
Almost certainly, it just needs someone to repeatedly bug the person who
can make the change :) Thanks for the suggestion for code BTW; I'll
take a look at that.
In the meantime, the fact that this has only come up once before, while
surprising, suggests that people may have written code in a different
style. Can you give a succinct example that demonstrates a situation
where you want to assign to a subset of a unit (rather than, say,
calculating values, setting some to 0, then building a unit from the
values) ?
Paul
baptiste auguie wrote:
Dear list,
Consider the following,
library(grid)
w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = w + unit(1, "mm")
w[2] <- 0
w2[2] <- 0
convertUnit(w, "mm")
#[1] 25.4mm 0mm
convertUnit(w2, "mm")
#Error in grid.Call("L_convert", x, as.integer(whatfrom),
as.integer(whatto), :
# INTEGER() can only be applied to a 'integer', not a 'NULL'
The last line fails, as the naive replacement has destroyed the
structure of w2 instead of having assigned a value of 0 to the second
unit element.
I've also tried,
w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = w + unit(1, "mm")
w2[[2]][2] <- 0
but this time, if the structure is licit, it's the result that's not
as I intended:
convertUnit(w2,"mm")
#[1] 26.4mm 1mm
My limited understanding is that an object of class unit.arithmetic is
waiting until the last moment to actually perform its operation,
stored in a tree-like structure. With this premise, I can't think of a
good way to modify one element of a list of unit elements.
As a workaround, I can only think of the following hack where the
objects are forced to be evaluated,
w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = convertUnit(w + unit(1, "mm"), "mm", valueOnly=TRUE)
w2[2] <- 0
w2 <- unit(w2, "mm")
but it clearly isn't a very desirable route.
What is the recommended way to modify one element of a unit vector?
Digging in grid/R/unit.R , I found the following comment,
# Write "[<-.unit" methods too ??
which probably explains the above. Would it be possible to add such a method,
"[<-.unit.list" <- function(x, index, value, top=TRUE, ...) {
this.length <- length(x)
index <- (1L:this.length)[index]
if (top && any(index > this.length))
stop("Index out of bounds (unit list subsetting)")
cl <- class(x)
result <- unclass(x)
result[(index - 1) %% this.length + 1] <- value
class(result) <- cl
result
}
a = unit.c(unit(1,"mm"),unit(2,"in"))
a[2] <- unit(3,"in")
a
but for unit.arithmetic also?
Regards,
baptiste
sessionInfo()
R version 2.9.2 (2009-08-24)
i386-apple-darwin8.11.1
locale:
en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] crash with NAs in subscripted assignment of a raw vector
2009/9/24 Hervé Pagès :
> > x <- charToRaw("ABCDEFGx")
> > x[c(1:3, NA, 6)] <- x[8]
>
> *** caught segfault ***
> address 0x8402423f, cause 'memory not mapped'
Thanks for the report. I have a fix which I will commit after some testing.
--
Seth Falcon | @sfalcon | http://userprimary.net/user
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
