[Rd] C-Side: Applying a function (given as param) to data (given as param)
Hello, I'm implementing a package (C-extension), where one function gets data and a function that needs to be applied to the data. I want to apply the function to (parts of) the data on the C-side. 1) how do I apply a function (given via SEXP) to data 2) how do I select parts of the data (also provided via SEXP)? Comment on 2: I want to implement a moving/rolling/running apply on the data, so I want to select a data window. How can this be done, and how can it be done efficiently? For example on page 101 of "Writing R extensions" there was a trick on how to use REAL on the result, before using it in a loop. Can this be used for efficiency reasons in general? Ciao, Oliver P.S.: What do these macros (like REAL()) do? Do they convert data or rather cast datatypes? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-Side: Applying a function (given as param) to data (given as param)
On Fri, Jun 03, 2011 at 11:14:39AM -0500, Douglas Bates wrote:
> On Fri, Jun 3, 2011 at 5:17 AM, oliver wrote:
> > Hello,
> >
> > I'm implementing a package (C-extension),
> > where one function gets data and a function
> > that needs to be applied to the data.
> >
> > I want to apply the function to (parts of)
> > the data on the C-side.
> >
> > 1) how do I apply a function (given via SEXP) to data
> > 2) how do I select parts of the data (also provided via SEXP)?
>
> Not to be facetious but you begin by reading the "Writing R Extensions"
> manual.
I already read inside it.
If there would be no question open i would not have registered to this mailing
list
and woulod not have asked that question.
Obviously my question was not answered in the "Writing R Extensions",
so if you can give me a hint this would be nice.
>
> An alternative is to read the vignette Rcpp-Introduction available as
> http://dirk.eddelbuettel.com/code/rcpp/Rcpp-introduction.pdf and soon
I use C, not C++.
But maybe it helps too.
I already created my own package with R and C successfully some days ago.
But so far I did not used fucntion pointers coming in via SEXP parameters.
And that was my specific question.
> to be in The R Journal. They show an explicit example of apply in
> compiled code (C++ using the Rcpp structures, in their case).
As just mentioned: I already created successfully a C-extension for R.
But I would like to know, how to call a function that I get via
SEXP as parameter. How can I find out the function definition,
for example the arity of the function and which arguments
a function uses.
The problem is, that the C-standard (at least the first ANSI-C standard)
does not guarantee portability for C-pointers.
To be portable, for example the function pointer you use must
definitely be of same type as the function you use.
So I need to know how I can use the SEXP-function pointers.
To be more concrete, this is how my function's API looks like
at the moment:
SEXP movapply( SEXP data, SEXP width, SEXP func )
{
/* some code */
return ( result );
}
data will be vector or list or matrix
width will be int value (I think vector of length 1)
func will be a function pointer of the type that is given as argument
I don't know on which kind of pointer to cast.
I think I will cast to a pure C-type, but then all data also must
match to the function definition.
What if the function wants to work on integer, but the data is double?
Somehow this must be handled, and I think the experts here can just point me
directly to some kind of docs or maybe older postinmgs here, which explain this?
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-Side: Applying a function (given as param) to data (given as param)
On Sat, Jun 04, 2011 at 07:51:08AM -0400, Duncan Murdoch wrote: > On 11-06-03 4:19 PM, oliver wrote: > >On Fri, Jun 03, 2011 at 11:14:39AM -0500, Douglas Bates wrote: > >>On Fri, Jun 3, 2011 at 5:17 AM, oliver wrote: > >>>Hello, > >>> > >>>I'm implementing a package (C-extension), > >>>where one function gets data and a function [...] [...] > >>to be in The R Journal. They show an explicit example of apply in > >>compiled code (C++ using the Rcpp structures, in their case). > > > > > >As just mentioned: I already created successfully a C-extension for R. > > > >But I would like to know, how to call a function that I get via > >SEXP as parameter. How can I find out the function definition, > >for example the arity of the function and which arguments > >a function uses. > > You should almost certainly do this in R, not in C. If you are > doing it in C code you'll just be duplicating the implementation > from R, and your code will break if that implementation ever > changes. [...] The reason why I wanted to do this in C, not in R, is speed as well as consistency. I have about 700 MB data that I want to analyse And loops might be to slow in R. Some of the apply functions might help and I already implemented some stuff in R, but the result values that some of the apply functions give me, are changing under certain circumstances, for example list or matrix or vector. Also a lot of conversions and value-extracting is needed. It looked to me as if doing in C would be the better way. So I want to have the possibility to do that in C, then loops are no problem, and I can create a certain result value type, as well as some other features I have in mind. Also in R the automatic coercion to some types sometimes is not necessary, and working on the raw values might be better, it seems to me. Also I want to learn the C-interface, so that in later cases I know how to use it. For simple values I already know how to use it. But the problem is there, when functions are given as parameters. That is a very powerful feature. If that only is manageable easy in R, it might always be a performance bottleneck. > > In R you use formals(fn) to extract the function header. OK, thanks. > > > > >The problem is, that the C-standard (at least the first ANSI-C standard) > >does not guarantee portability for C-pointers. > >To be portable, for example the function pointer you use must > >definitely be of same type as the function you use. > > > >So I need to know how I can use the SEXP-function pointers. > > They are not function pointers, they are pointers to R objects. [...] Aha, good to know. Do I have to look at S3 and S4 methods and classses, if I wish to make it in C? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-Side: Applying a function (given as param) to data (given as param)
Hello Jeff, thanks for the hints and details. I just downloaded xts-sources and hope it shows me the dark secrets of R ;) Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Packages for R-CRAN (organizing aspects)
Hello, I have some ideas for packages that I want to provide on R-CRAN. One package alreads is working, but I have some warnings in when compiling. Also I don't know if the libraries in use are only working on Unix/Linux. So I have some general questions: - If I'm not sure if the code would also work on windows (needing some ceratain libraries or tools), would it be better to mark it as Unix-like only? Would other people, who are interested in using the package on Windows, then look for the other issues? (I'm just interested in providing the functionality, and I don't use Windows, so compatibility would not be my main goal, if it's using certain libraries; but if the code is not relying on certain libs or tools I of course write code ANSI-conform, so that it *should* compile on windows too.) I mean: I just want to have the work for Unix/Linux, but in general like the platform-independent approach. I just have no interest, looking at the windows side too much. Are there people from R-CRAN team, who help at that point to make things available on many platforms? - I have in mind packages for reading a lot of different files / fileformat. How to name them? it would be consequent to name them read. but I'm not sure if this naming style is reserved for OO-methods only, and that topic I will learn later in detail, so that at the moment I just would provide the raw functionality. Maybe the name of the reading function should then better be named read or read ? - There are a lot of different fileformats that I want to read in. Would it be better to make for each format one different package, or rather put them all together as a package "Readmisc"? For example the following formats I have in mind: - jpeg (libjpeg62) => already working, I want to clean up the code and documentation soon and then provide on R-CRAN - bvh (maybe (f)lex or yacc or pcre) => want to start this soon - apachelogfile /maybe using pcre) => starting date not planned - some other formats also - Other package ideas: rolling application (which uses R's built in types, not like zoo() using special types) Can you give me some general advice on how to organize this best, so that it also fits into the R / R-CRAN philosophy?! Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "warning: assignment discards qualifiers from pointer target type"
Hello,
following an advice here from the list I looked into sources of other
packages (xts) and found the TYPEOF() macro/function, which really is
helpful.
I iused the follwong code snippet:
switch( TYPEOF( filename_sexp ) )
{
case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
break;
default: error("filename argument must be a string");
break;
}
Here, filename is of type char*
and one function opens a file with that name.
So it is purely intended to just grab out the char* from the
String-Expression.
Am I doing something wrong here, or is it ok, but I have somehow
to say the extracting macros/functions, that it is really intended
to throw away information and that a warning is not necessary?
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages for R-CRAN (organizing aspects)
On Tue, Jun 07, 2011 at 10:30:12AM -0400, Gabor Grothendieck wrote:
> On Tue, Jun 7, 2011 at 9:03 AM, oliver wrote:
> > Hello,
> >
> > I have some ideas for packages that I want to provide on R-CRAN.
> >
> > One package alreads is working, but I have some warnings in
> > when compiling. Also I don't know if the libraries in use are only
> > working on Unix/Linux.
> >
> > So I have some general questions:
> >
> > - If I'm not sure if the code would also work on windows
> > (needing some ceratain libraries or tools),
> > would it be better to mark it as Unix-like only?
> >
> > Would other people, who are interested in using the package
> > on Windows, then look for the other issues?
> >
> > (I'm just interested in providing the functionality, and I don't use
> > Windows,
> > so compatibility would not be my main goal, if it's using certain
> > libraries;
> > but if the code is not relying on certain libs or tools I of course
> > write
> > code ANSI-conform, so that it *should* compile on windows too.)
> >
> > I mean: I just want to have the work for Unix/Linux, but in general like
> > the
> > platform-independent approach. I just have no interest, looking at the
> > windows
> > side too much. Are there people from R-CRAN team, who help at that point
> > to make
> > things available on many platforms?
> >
> >
> > - I have in mind packages for reading a lot of different files /
> > fileformat.
> > How to name them?
> > it would be consequent to name them
> > read.
> > but I'm not sure if this naming style is reserved for OO-methods only,
> > and that topic I will learn later in detail, so that at the moment
> > I just would provide the raw functionality.
> >
> > Maybe the name of the reading function should then better be named
> > read or read ?
> >
> > - There are a lot of different fileformats that I want to read in.
> >
> > Would it be better to make for each format one different package,
> > or rather put them all together as a package "Readmisc"?
> >
> > For example the following formats I have in mind:
> >
> > - jpeg (libjpeg62) => already working, I want to
> > clean up the code and
> > documentation
> > soon and then provide on
> > R-CRAN
> >
>
> Note existence of read.jpeg in the rimage package, read.gif in the
> caTools package and readPNG in the png package.
read.jpeg in rimage does not give me a matrix like I would extpect in R,
for further working with the data.
It gives me an imagmatrix, which's value I can't access directly.
I only have a data structure that is closed to the functionality that the
rimage module provides.
Maybe I have overseen something,
but how would I plot a histogram
of R, G and B values and the according
grayvalue's histogram?
With my libjpeg reader it would be:
library(libjpeg)
pic <- readjpeg( picfilename )
par(mfrof=c(4,1))
hist( pic$r, breaks = 256, col="red")
hist( pic$g, breaks = 256, col="green")
hist( pic$b, breaks = 256, col="blue")
hist( pic$bw, breaks = 256)
How would that be possible with rimage?
read.gif in caTools is giving back a matrix, and hence it's a fine function.
caTools btw. offers a lot of very interesting functions. :-)
readPNG of png package is agood hint,
I didn't knew that.
>
> > - bvh (maybe (f)lex or yacc or pcre) => want to start this soon
> >
> > - apachelogfile /maybe using pcre) => starting date not planned
> >
> > - some other formats also
> >
> >
> > - Other package ideas: rolling application (which uses R's built in types,
> > not like zoo() using special types)
>
> rollapply and related functions in the development version of zoo do
> work with ordinary vectors and matrices:
Ah the it's a new feature, which is not offered in the packages I can install
with install.packages and the default settings for this.
I had to use as.zoo() around my data to use rollapply from zoo-package.
> # install development version of zoo
> install.packages("zoo", repos = "http://r-forge.r-project.org";)
Aha.
OK, thanks.
What about the documentation.
if I look for it on r-cran, but the module is form r-forge there will
be a mismatch.
> >
> > library(zoo)
> > rollmean(1:10, 2)
> [1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
> > rollapply(1:10, 2, sum)
> [1] 3 5 7 9 11 13 15 17 19
> > rollmean(1:10, 2)
> [1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5
> > rollapply(cbind(a = 1:10, b = 11:20), 3, sum)
Yes, with that version it works. :-)
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
> On Tue, 7 Jun 2011, Duncan Murdoch wrote:
>
> >On 07/06/2011 9:08 AM, oliver wrote:
> >>Hello,
> >>
> >>following an advice here from the list I looked into sources of other
> >>packages (xts) and found the TYPEOF() macro/function, which really is
> >>helpful.
>
> It is documented, of course, but actually better alternatives are
> described in 'Writing R Extensions'.
>
> We would urge you to study the R sources rather than copy bad habits
> from randomly chosen package sources.
[...]
Hmhh, it was not randomly chosen, it was, what I got as a hint here on the list.
>
> >>I iused the follwong code snippet:
> >>
> >>
> >> switch( TYPEOF( filename_sexp ) )
> >> {
> >> case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
> >> break;
> >>
> >> default: error("filename argument must be a string");
> >> break;
> >> }
> >>
> >>
> >>Here, filename is of type char*
> >>and one function opens a file with that name.
> >>So it is purely intended to just grab out the char* from the
> >>String-Expression.
> >>
> >>Am I doing something wrong here, or is it ok, but I have somehow
> >>to say the extracting macros/functions, that it is really intended
> >>to throw away information and that a warning is not necessary?
> >
> >The result of calling CHAR should be a "const char *". You are
> >not allowed to touch the string it points to.
>
> Note too that isString() exists for this purpose,
[...]
OK, I also sometimes used that (maybe I threw it out or used it in other
modules).
> and there is no
> check in that code that LENGTH(filename_sexp) > 0 (or == 1). In the
> R sources you will often see things like
>
> if(!isString(sfile) || LENGTH(sfile) < 1)
> error("invalid '%s' argument", "description");
[...]
If it's a vector, I can just pic the first element.
Or does LENGTH(sfile) give the length of the string itself
(like strlen(3))?
If the latter, then my file-opeing operation would faile with an error.
Of course I check if my fopen() gibves back NULL.
>
> Then, reading on,
>
> file = translateChar(STRING_ELT(sfile, 0));
translateChar is explained on page 120 of the extension writing do.
I'm not in this point of the documentation.
And I often need to look around, when I want to find a function,
as they are documented/explained somewhere during the flow of the text.
Something like a API description that is brief would help.
For example something like in the manuals of the OCaml language:
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html
That's very brief.
Chapter 6 of the "Writing R Extensions" is rather in this style
and gives a good overview.
Something like that for the macros would be helpful.
>
> for you cannot (in general) assume that the character vector passed
> is in the native encoding.
I try to do some coercions (e.g. as.integer())
when I need integer in the C-code and then
in the C-part rigidly check on integer.
About the char-encodings I have not thought much.
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Ctrl-C of functions that allocated mem
Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation? Normally in an interactive session "some memory" might not be a problem, because it will be run shortly; but I prefer clean solutions. And also, if it's much mem, which is allocated each time, and one does many trials and Ctr-C's, even an interactive session might eat a lot of mem. So I would be interested in a solution to this (potential) problem. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Wed, Jun 08, 2011 at 02:23:29PM -0400, Simon Urbanek wrote:
>
> On Jun 8, 2011, at 12:08 PM, oliver wrote:
>
> > On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
> >> On Tue, 7 Jun 2011, Duncan Murdoch wrote:
> >>
> >>> On 07/06/2011 9:08 AM, oliver wrote:
> >>>> Hello,
> >>>>
> >>>> following an advice here from the list I looked into sources of other
> >>>> packages (xts) and found the TYPEOF() macro/function, which really is
> >>>> helpful.
> >>
> >> It is documented, of course, but actually better alternatives are
> >> described in 'Writing R Extensions'.
> >>
> >> We would urge you to study the R sources rather than copy bad habits
> >> from randomly chosen package sources.
> > [...]
> >
> > Hmhh, it was not randomly chosen, it was, what I got as a hint here on the
> > list.
> >
>
> It was not provided to you to look at how it checks arguments. For basic
> usage it's better to look at the R code. The coding styles vary a lot in
> packages (and so does the quality of packages) - some of them are really bad,
> but you have to remember that most people write packages in their free time
> and
> are not programmers...
OK, I see.
[...]
> >> and there is no
> >> check in that code that LENGTH(filename_sexp) > 0 (or == 1). In the
> >> R sources you will often see things like
> >>
> >>if(!isString(sfile) || LENGTH(sfile) < 1)
> >>error("invalid '%s' argument", "description");
> > [...]
> >
> > If it's a vector, I can just pic the first element.
>
> Yes, but only if it's not a vector of length zero - hence the necessary check.
>
>
> > Or does LENGTH(sfile) give the length of the string itself
> > (like strlen(3))?
> >
>
> No.
[...]
OK, I looked at this now.
LENGTH() checks the length of the vector.
Good to know this.
So the problem of a vector of length 0 can be with any arguments of type SEXP,
hence I will need to check ANY arg on it's length.
This is vital to stability under any situation.
Thanks for this valuable hint!
I will add checks for all my SEXP-args.
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote: [...] > OK, I looked at this now. > > LENGTH() checks the length of the vector. > > Good to know this. > > So the problem of a vector of length 0 can be with any arguments of type SEXP, > hence I will need to check ANY arg on it's length. > > This is vital to stability under any situation. > > Thanks for this valuable hint! > > I will add checks for all my SEXP-args. [...] Hey, LENGTH() does not work with String-vectors! :( Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Wed, Jun 08, 2011 at 08:35:34PM -0400, Simon Urbanek wrote:
>
> On Jun 8, 2011, at 8:32 PM, oliver wrote:
>
> > On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote:
> > [...]
> >> OK, I looked at this now.
> >>
> >> LENGTH() checks the length of the vector.
> >>
> >> Good to know this.
> >>
> >> So the problem of a vector of length 0 can be with any arguments of type
> >> SEXP,
> >> hence I will need to check ANY arg on it's length.
> >>
> >> This is vital to stability under any situation.
> >>
> >> Thanks for this valuable hint!
> >>
> >> I will add checks for all my SEXP-args.
> > [...]
> >
> > Hey, LENGTH() does not work with String-vectors! :(
> >
>
> Of course it does ...
>
>
It does not so on my R 2.10.1 installation.
In the R-Shell I get:
==
> length(c())
[1] 0
>
==
So c() is vec of length 0.
When I feed my readjpeg() with c() as filename arg,
testing with:
if( LENGTH( filename_sexp ) < 1 )
{
error("LENGTH( filename_sexp ) < 1");
//error("filename can't be vector of length 0");
}
else
{
error("LENGTH( filename_sexp ) is not < 1");
}
I got:
Error in readjpeg(filename = c()) : LENGTH( filename_sexp ) is not < 1
You can explain why?
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ctrl-C of functions that allocated mem
On Wed, Jun 08, 2011 at 08:40:21PM -0400, Simon Urbanek wrote:
>
> On Jun 8, 2011, at 8:06 PM, oliver wrote:
>
> >
> > Hello,
> >
> >
> > what happens, when a function (R-extension in C), that allocated memory
> > (strdup(), malloc()/calloc() and so on), and is used in interactive mode,
> > then
> > will be stopped via Ctrl-C?
> >
> > I would assume that there remains allocated memory,
> > which is not usable and also not accessable (hence no
> > way to free it).
> >
> > Are there any mechanisms in R that could help in rolling
> > back the allocation?
> >
>
> Yes, if you read R-exts:
> http://r.research.att.com/man/R-exts.html#Memory-allocation
> you would know that you're not supposed to use malloc/calloc at all and if
> you allow interruption ("regular" C code does not) R_alloc does what you
> asked about.
OK.
There are some pages I didn't read so far.
I'm just too unpatient
...maybe should go on reading ;)
Thanks for the hint to the R-exts.html.
I hope there I also will find a solution for my
filename-problem: want a char* on a filename, must use
const char* (strdup() would match that issue), and
I should not use my own allocation mechanisms.
Then there must be something to address this.
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Thu, Jun 09, 2011 at 07:43:20AM -0400, Duncan Murdoch wrote:
> On 11-06-09 7:27 AM, oliver wrote:
> >On Wed, Jun 08, 2011 at 08:35:34PM -0400, Simon Urbanek wrote:
> >>
> >>On Jun 8, 2011, at 8:32 PM, oliver wrote:
> >>
> >>>On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote:
> >>>[...]
> >>>>OK, I looked at this now.
> >>>>
> >>>>LENGTH() checks the length of the vector.
> >>>>
> >>>>Good to know this.
> >>>>
> >>>>So the problem of a vector of length 0 can be with any arguments of type
> >>>>SEXP,
> >>>>hence I will need to check ANY arg on it's length.
> >>>>
> >>>>This is vital to stability under any situation.
> >>>>
> >>>>Thanks for this valuable hint!
> >>>>
> >>>>I will add checks for all my SEXP-args.
> >>>[...]
> >>>
> >>>Hey, LENGTH() does not work with String-vectors! :(
> >>>
> >>
> >>Of course it does ...
> >>
> >>
> >
> >It does not so on my R 2.10.1 installation.
> >
> >
> >In the R-Shell I get:
> >
> > ==
> > > length(c())
> > [1] 0
> > >
> > ==
> >
> >So c() is vec of length 0.
> >
> >When I feed my readjpeg() with c() as filename arg,
> >
> >testing with:
> >
> > if( LENGTH( filename_sexp )< 1 )
> > {
> > error("LENGTH( filename_sexp )< 1");
> > //error("filename can't be vector of length 0");
> > }
> > else
> > {
> > error("LENGTH( filename_sexp ) is not< 1");
> > }
> >
> >
> >
> >I got:
> > Error in readjpeg(filename = c()) : LENGTH( filename_sexp ) is not< 1
> >
> >
> >You can explain why?
>
> c() doesn't create a STRSXP, it is NULL, which is a NILSXP.
> LENGTH() doesn't work on that object. (I'd recommend using length()
> rather than LENGTH(); it's a function, not a macro, and it does give
> the expected answer.)
[...]
Interestingly, c() as value for an integer value
can be testes correctly with LENGTH().
So the question arises: is c() always creating NILSXP,
or is it NILSXP only for STRSXP, and 0 otherwise?
NILSXP, as it might be close to a NULL might be interpreted as 0
length by LENGTH...
Nevertheless it's a littlebid confusing for people who don't know the
internals of R.
Will try length() soon.
Ciao,
Oliver
P.S.: To be picky: NOT knowing the internals and nevertheless using the
available
functions/macros is called encapsulation in OO or the difference between
interface and implementation... which is good style of programming.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ctrl-C of functions that allocated mem
On Wed, Jun 08, 2011 at 08:40:21PM -0400, Simon Urbanek wrote:
>
> On Jun 8, 2011, at 8:06 PM, oliver wrote:
>
> >
> > Hello,
> >
> >
> > what happens, when a function (R-extension in C), that allocated memory
> > (strdup(), malloc()/calloc() and so on), and is used in interactive mode,
> > then
> > will be stopped via Ctrl-C?
> >
> > I would assume that there remains allocated memory,
> > which is not usable and also not accessable (hence no
> > way to free it).
> >
> > Are there any mechanisms in R that could help in rolling
> > back the allocation?
> >
>
> Yes, if you read R-exts:
> http://r.research.att.com/man/R-exts.html#Memory-allocation
> you would know that you're not supposed to use malloc/calloc at all and if
> you allow interruption ("regular" C code does not) R_alloc does what you asked
> about.
[...]
In the printed (pdf) version of R-exts I found that
R_alloc() and S_alloc() and some other functions
from section 6.1.1 have return type char*.
This seesm to be a relict from the K&R era,
because since ANSI C void* is the type for generic pointers.
will it be changed in the future, so that
R_alloc() will be void* R_alloc() one day?
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ctrl-C of functions that allocated mem
On Thu, Jun 09, 2011 at 04:42:33PM +0200, oliver wrote:
> On Wed, Jun 08, 2011 at 08:40:21PM -0400, Simon Urbanek wrote:
> >
> > On Jun 8, 2011, at 8:06 PM, oliver wrote:
> >
> > >
> > > Hello,
> > >
> > >
> > > what happens, when a function (R-extension in C), that allocated memory
> > > (strdup(), malloc()/calloc() and so on), and is used in interactive mode,
> > > then
> > > will be stopped via Ctrl-C?
> > >
> > > I would assume that there remains allocated memory,
> > > which is not usable and also not accessable (hence no
> > > way to free it).
> > >
> > > Are there any mechanisms in R that could help in rolling
> > > back the allocation?
> > >
> >
> > Yes, if you read R-exts:
> > http://r.research.att.com/man/R-exts.html#Memory-allocation
> > you would know that you're not supposed to use malloc/calloc at all and if
> > you allow interruption ("regular" C code does not) R_alloc does what you
> > asked
> > about.
> [...]
>
> In the printed (pdf) version of R-exts I found that
> R_alloc() and S_alloc() and some other functions
> from section 6.1.1 have return type char*.
>
> This seesm to be a relict from the K&R era,
> because since ANSI C void* is the type for generic pointers.
>
> will it be changed in the future, so that
> R_alloc() will be void* R_alloc() one day?
[...]
..and btw: when casting to (void*) instead of mytype*
(as is seen on page 122 of "Writing R Extensions" (2011-04-13)
t's much better.
The the pointer is generic and will automatically be correctly
assigned to the left hand side.
But better would be of course to avoid any casts and make the
return type of the alloc-functions void*.
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] success of R_alloc (Re: Ctrl-C of functions that allocated mem)
In section 6.1.2 of Writing R Extensions, it is mentioned that if the function returns, success can be assumed. In section 6.1.1 this is not mentioned, but I assume the same holds true there too, even it is not mentioned there. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Thu, Jun 09, 2011 at 10:54:28AM -0400, Duncan Murdoch wrote:
> On 09/06/2011 9:28 AM, oliver wrote:
> >On Thu, Jun 09, 2011 at 07:43:20AM -0400, Duncan Murdoch wrote:
> >> On 11-06-09 7:27 AM, oliver wrote:
> >> >On Wed, Jun 08, 2011 at 08:35:34PM -0400, Simon Urbanek wrote:
> >> >>
> >> >>On Jun 8, 2011, at 8:32 PM, oliver wrote:
> >> >>
> >> >>>On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote:
> >> >>>[...]
> >> >>>>OK, I looked at this now.
> >> >>>>
> >> >>>>LENGTH() checks the length of the vector.
> >> >>>>
> >> >>>>Good to know this.
> >> >>>>
> >> >>>>So the problem of a vector of length 0 can be with any arguments of
> >> type SEXP,
> >> >>>>hence I will need to check ANY arg on it's length.
> >> >>>>
> >> >>>>This is vital to stability under any situation.
> >> >>>>
> >> >>>>Thanks for this valuable hint!
> >> >>>>
> >> >>>>I will add checks for all my SEXP-args.
> >> >>>[...]
> >> >>>
> >> >>>Hey, LENGTH() does not work with String-vectors! :(
> >> >>>
> >> >>
> >> >>Of course it does ...
> >> >>
> >> >>
> >> >
> >> >It does not so on my R 2.10.1 installation.
> >> >
> >> >
> >> >In the R-Shell I get:
> >> >
> >> >==
> >> >> length(c())
> >> >[1] 0
> >> >>
> >> >==
> >> >
> >> >So c() is vec of length 0.
> >> >
> >> >When I feed my readjpeg() with c() as filename arg,
> >> >
> >> >testing with:
> >> >
> >> >if( LENGTH( filename_sexp )< 1 )
> >> >{
> >> > error("LENGTH( filename_sexp )< 1");
> >> > //error("filename can't be vector of length 0");
> >> >}
> >> >else
> >> >{
> >> > error("LENGTH( filename_sexp ) is not< 1");
> >> >}
> >> >
> >> >
> >> >
> >> >I got:
> >> >Error in readjpeg(filename = c()) : LENGTH( filename_sexp ) is not<
> >> 1
> >> >
> >> >
> >> >You can explain why?
> >>
> >> c() doesn't create a STRSXP, it is NULL, which is a NILSXP.
> >> LENGTH() doesn't work on that object. (I'd recommend using length()
> >> rather than LENGTH(); it's a function, not a macro, and it does give
> >> the expected answer.)
> >[...]
> >
> >Interestingly, c() as value for an integer value
> >can be testes correctly with LENGTH().
>
> Presumably you converted it to an INTSXP. c() is NULL.
[...]
Ooops, yes. In the R-part. :-)
I did it, because when I don't get an int from the user's call,
I have set it to NA (default in the R-function definition).
I made
width <- as.integer(width)
for easy check inside the C-part, on integer.
(I really only need int, no floating point values.)
I thought this makes the C-code easier at that part.
Or I may check on NA inside the C-part.
How would I do that correctly?
After so much different opinions I read here, I'm rather puzzled on that now.
If there is already a R-extensions-FAQ I could collect the informations
from the mail sof the last days, so that the different opinions and the
discussion
can result in a some answers...
>
> >So the question arises: is c() always creating NILSXP,
> >or is it NILSXP only for STRSXP, and 0 otherwise?
>
> That question makes no sense at all.
It make sense for the picky.
As NULL is rather (void*)0 and a pointer is not an int (just can be coerced
normally) ;)
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Thu, Jun 09, 2011 at 12:56:09PM -0400, Simon Urbanek wrote:
>
> On Jun 9, 2011, at 11:15 AM, oliver wrote:
>
> > On Thu, Jun 09, 2011 at 10:54:28AM -0400, Duncan Murdoch wrote:
> >> On 09/06/2011 9:28 AM, oliver wrote:
> >>> On Thu, Jun 09, 2011 at 07:43:20AM -0400, Duncan Murdoch wrote:
> >>>> On 11-06-09 7:27 AM, oliver wrote:
> >>>>> On Wed, Jun 08, 2011 at 08:35:34PM -0400, Simon Urbanek wrote:
> >>>>>>
> >>>>>> On Jun 8, 2011, at 8:32 PM, oliver wrote:
> >>>>>>
> >>>>>>> On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote:
> >>>>>>> [...]
> >>>>>>>> OK, I looked at this now.
> >>>>>>>>
> >>>>>>>> LENGTH() checks the length of the vector.
> >>>>>>>>
> >>>>>>>> Good to know this.
> >>>>>>>>
> >>>>>>>> So the problem of a vector of length 0 can be with any arguments of
> >>>>>>>> type SEXP,
> >>>>>>>> hence I will need to check ANY arg on it's length.
> >>>>>>>>
> >>>>>>>> This is vital to stability under any situation.
> >>>>>>>>
> >>>>>>>> Thanks for this valuable hint!
> >>>>>>>>
> >>>>>>>> I will add checks for all my SEXP-args.
> >>>>>>> [...]
> >>>>>>>
> >>>>>>> Hey, LENGTH() does not work with String-vectors! :(
> >>>>>>>
> >>>>>>
> >>>>>> Of course it does ...
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> It does not so on my R 2.10.1 installation.
> >>>>>
> >>>>>
> >>>>> In the R-Shell I get:
> >>>>>
> >>>>> ==
> >>>>>> length(c())
> >>>>> [1] 0
> >>>>>>
> >>>>> ==
> >>>>>
> >>>>> So c() is vec of length 0.
> >>>>>
> >>>>> When I feed my readjpeg() with c() as filename arg,
> >>>>>
> >>>>> testing with:
> >>>>>
> >>>>> if( LENGTH( filename_sexp )< 1 )
> >>>>> {
> >>>>> error("LENGTH( filename_sexp )< 1");
> >>>>> //error("filename can't be vector of length 0");
> >>>>> }
> >>>>> else
> >>>>> {
> >>>>> error("LENGTH( filename_sexp ) is not< 1");
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>> I got:
> >>>>> Error in readjpeg(filename = c()) : LENGTH( filename_sexp ) is not<
> >>>>> 1
> >>>>>
> >>>>>
> >>>>> You can explain why?
> >>>>
> >>>> c() doesn't create a STRSXP, it is NULL, which is a NILSXP.
> >>>> LENGTH() doesn't work on that object. (I'd recommend using length()
> >>>> rather than LENGTH(); it's a function, not a macro, and it does give
> >>>> the expected answer.)
> >>> [...]
> >>>
> >>> Interestingly, c() as value for an integer value
> >>> can be testes correctly with LENGTH().
> >>
> >> Presumably you converted it to an INTSXP. c() is NULL.
> > [...]
> >
> > Ooops, yes. In the R-part. :-)
> > I did it, because when I don't get an int from the user's call,
> > I have set it to NA (default in the R-function definition).
> >
> > I made
> > width <- as.integer(width)
> > for easy check inside the C-part, on integer.
> >
> > (I really only need int, no floating point values.)
> >
> > I thought this makes the C-code easier at that part.
> >
> > Or I may check on NA inside the C-part.
> >
> > How would I do that correctly?
> >
> > After so much different opinions I read here, I'm rather puzzled on that
> > now.
>
Re: [Rd] Controlling stdin and stdout in an embedded R instance
Hello, I'm new in exploring R-internals, and also did not explored embedding R into C. I did some C-extensions for packages so far. Nevertheless I can give you a hint, which might be helpful; the example which you linked to, uses R.dll. DLL means: Dynamic linked library. On Unix and Linux the aequivalent is shared libraries, or also dynamic linked libraries; another term that is used here is "dynamic linking loader", which provides the possibilities to "load" those libraries, which means, make them available in your application. To use a shared library on Unix/Linux you can use the functions dlopen() dlerror() dlsym() dlclose() The manpages will explain you the details. Hope that helps. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
If you compile/link the code together,
and distribute the software, then the code must be GPL.
Seperate install makes sense. IMHO.
So then the user would put together the parts.
Not sure, but maybe the different parts also must be shipped seperated.
Ciao,
Oliver
On Tue, Aug 30, 2011 at 12:50:37PM -0500, Jeffrey Ryan wrote:
> R-devel,
>
> I am interested in creating a package that requires non-GPL'd (commercial) C
> code to work. In essence it is a single .c file with no use of R headers
> (all .C callable functions). For example's sake:
>
> 1 #include
> 2
> 3 void test (int *a) {
> 4 *a = 101;
> 5 }
>
> The package isn't destined for CRAN, and I realize that this isn't R-legal,
> but looking for some expert advice from anyone else who may have encountered
> this previously.
>
> The question is whether or not one can distribute code that has multiple
> licenses (.c or individual .R files), including some that are not
> GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
> process [R CMD ***] cause everything to become GPL, as we are using R itself
> to build the package?
>
> I can of course provide the C libs in this case as a separate install, but
> that adds complexity to the overall build and install process.
>
> Thanks,
> Jeff
>
> --
> Jeffrey Ryan
> jeffrey.r...@lemnica.com
>
> www.lemnica.com
> www.esotericR.com
>
> [[alternative HTML version deleted]]
>
> __
> 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] Non-GPL C (or R) inside of a package
On Wed, Aug 31, 2011 at 10:34:38AM -0500, Jeffrey Ryan wrote: [...] > My case is a bit more subtle, as the code that I am writing makes no > use of any GPL code, aside from the compilation and linking to allow > GPL "R" code to access it. [...] Just ask people from the FSF, if your issue is complicated. Or ask the owner of the nmon-GPLed code, if it is possible to make it open for your project. That does not necessarily mean that the same code in olther products of the company also needs to become open. It's possible to make a "fork". You just can't make GPLed code again closed. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is xtable still being maintained?
On Sat, Sep 10, 2011 at 07:40:24AM -0700, Spencer Graves wrote: > > > On 9/10/2011 6:06 AM, Uwe Ligges wrote: > > > > > >On 10.09.2011 13:26, Alastair wrote: > >>Hi, > >> > >>I wonder if anyone knows if the xtable package is still actively being > >>maintained? The last update to the CRAN was about 2 years ago. > >>Earlier in > >>the year I found I wanted to use the short caption option of > >>LaTeX tables to > >>display an abridged title in my table of contents. It was a relatively > >>simple change to get xtable to support this. I bundled up my changes and > >>sent the maintainer David B. Dahl an email and I got absolutely > >>no response? > > > >Try to "ping" - at least I do so in this case. No response would > >be unfortunate, of course. > > > David B. Dahl still has a web site as an Associate Professor > at Texas A&M U. > > > > > >>What's the etiquette for this kind of situation? I think he's done a > >>sterling job maintaining a really useful package; I wanted to help and > >>contribute to the community but if he's not doing it anymore how > >>can anyone > >>get their improvements / bug fixes into circulation? > > > >xtable's DESCRIPTION file says > > > >License:GPL (>= 2) > > > >so go ahead in case you do not get a response. > > > >Best, > >Uwe Ligges > > > xtable has a long list of reverse depends, imports, suggests > and enhances, so many people clearly think it's useful. > > > My preference is to encourage the maintainer(s) to migrate the > project to R-Forge where others can help maintain it and add [...] AFAIK xtable was also there available, but looking it up via search function it seems not to be the case. So I may have mixed up it with a different package... hmhhh ah, I think it was zoo-package. Hmhh, yes, I think zoo... and the r-forge zoo-package allows rollapply() also on any data type, wheras the older r-cran zoo only allowed rollapply() to zoo-dataytpe (at lkeast at that time when I compared both packages). If Rforge is the devel-hosting platform, but R-CRAN is the platform where packages should be downloadet from (at least it seems to be the default for install), then from time to time packages should be copied to R-CRAN, so that there the progress one day will pop up - maybe with a delay, and only hosting well tested packages. Something like "testing" and "stable" in Debian's distribution concept for the R-packages. It seems the R-Forge issue is not so well known. First time when I heard of R-forge is some months ago, and it was via #R channel on freenode, which I also can recommend for fast communication. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is xtable still being maintained?
On Sat, Sep 10, 2011 at 10:24:49AM -0700, Spencer Graves wrote: > On 9/10/2011 10:19 AM, oliver wrote: > >On Sat, Sep 10, 2011 at 07:40:24AM -0700, Spencer Graves wrote: > >> > >>On 9/10/2011 6:06 AM, Uwe Ligges wrote: > >>> > >>>On 10.09.2011 13:26, Alastair wrote: > >>>>Hi, > >>>> > >>>>I wonder if anyone knows if the xtable package is still actively being [...] long beard shaved away ;-) [...] > >If Rforge is the devel-hosting platform, but R-CRAN is the platform where > >packages > >should be downloadet from (at least it seems to be the default for install), > >then from time to time packages should be copied to R-CRAN, so that there the > >progress one day will pop up - maybe with a delay, and only hosting well > >tested > >packages. > > Exactly: R-Forge -> (log in and select a package for which you are > a maintainer or admin) -> "R packages" -> "[Submit this package to > CRAN]" -> (answer the questions) -> submit --- but only when you > feel the new version is ready. [...] I think, often things become unsupported, because too much overhead is annoying. But this sounds very good / supporting. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is xtable still being maintained?
Hello, On Sat, Sep 10, 2011 at 12:14:07PM -0500, David B. Dahl wrote: > Hello, > > Regarding whether xtable is still maintained, yes, but at a minimal level. > I am committed to ensuring that it passes the tests on the latest version > of R, but I am having difficulty finding the time and interest in > incorporating new features. [...] I also missed some features. I have written my own R-code for circumvent this, but it would be better toi enhance xtable, because the functionality otherwise would split into package-code and "user-code". So it would be better to incorporate some more features. If someone would want to take over maintenance, I had some feature wishes... Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "Speeding tickets for R and Stata"
Hello, an article on that topic: http://ekonometrics.blogspot.com/2011/04/speeding-tickets-for-r-and-stata.html Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash in R using embedded.
Hello, On Wed, Feb 01, 2012 at 10:24:23AM -0500, Dave Pugmire wrote: > Hi, > I'm new to R, and am trying to embed R into another application. > I'm calling gev.fit() from the ismev package, and it is crashing somewhere > inside it. > gdb is not catching it, and valgrind is not showing any memory corruption > issues. [...] valgrind? *shudder* ;-) > I suspect it's memory corruption, because it doesn't crash in exactly the > same spot each time. > I'm running R 2.12.2 on a 64 bit linux (Ubuntu 10.04) [...] You could analyze the coredump with gdb, if you allow one to be written. On Ubuntu the default is to set core size to 0 Bytes, so a crash will be silent. (I think this is also true on some (most? all?) other Linux distributions). You need to change this behaviour and then you might get some progress in your debugging attempts. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Thu, Mar 01, 2012 at 11:06:51AM -0600, Douglas Bates wrote: > My purpose in mentioning the Julia language (julialang.org) here is > not to start a flame war. I find it to be a very interesting > development and others who read this list may want to read about it > too. [...] Very interesting language. Thank you for mentioning it here. Compiling from the github-sources was easy. Will explore it during the next days. Seems not to be very specific to statistics, but good for math in general. Not sure, if it might make sense to combine R and Julia in the long run (I mean: combining via providing interfaces between them, calling the one via the other, merging code or using libs from the one or the other from each side). Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Mon, Mar 05, 2012 at 03:53:28PM +, William Dunlap wrote: > I haven't used Julia yet, but from my quick reading > of the docs it looks like arguments to functions are > passed by reference and not by value, so functions > can change their arguments. My recollection from when > I first started using S (in the course of a job helping > profs and grad students do statistical programming, c. 1983) > is that not having to worry about in-place algorithms changing > your data gave S a big advantage over Fortran or C. [...] C also uses Call-by-Value. Fortran I don't know in detail. > While this feature could slow things down and increase > memory code, I felt that it made it easier to write correct > code and to use functions that others had written. Yes, I also think, that call-by-value decreases errors in Code. What I read about Julia it's like MATLAB plus more features for programming. Does matlab also only use call-by-reference? > Does Julia have a const declaration or other > means of controlling or documenting that a given function > will or will not change the data passed into it? I did not explored it in detail so far. Maybe the orig-poster already did this in more depth? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Mon, Mar 05, 2012 at 03:58:59PM -0800, Hervé Pagès wrote: > Hi Oliver, > > On 03/05/2012 09:08 AM, oliver wrote: > >On Mon, Mar 05, 2012 at 03:53:28PM +, William Dunlap wrote: > >>I haven't used Julia yet, but from my quick reading > >>of the docs it looks like arguments to functions are > >>passed by reference and not by value, so functions > >>can change their arguments. My recollection from when > >>I first started using S (in the course of a job helping > >>profs and grad students do statistical programming, c. 1983) > >>is that not having to worry about in-place algorithms changing > >>your data gave S a big advantage over Fortran or C. > >[...] > > > > > >C also uses Call-by-Value. > > C *only* uses Call-by-Value. [...] Yes, that's what I meant. With "also" I meant, that it uses call-by-value, as some other languages also do. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Mon, Mar 05, 2012 at 04:54:05PM -0800, Nicholas Crookston wrote: > There are many experts on this topic. I'll keep this short. > > Newer Fortran Languages allow for call by value, but call by reference > is the typical and historically, the only approach (there was a time > when you could change the value of 1 to 2!). Oh, strange. > > C "only" calls by value except that the value can be a pointer! So, > havoc is just a * away. [...] For me there was no "havoc" at this point, but for others maybe. There are also other languages that only use call-by-value... ...functional languages are that way in principal. Nevertheless internally they may heavily use pointers and even if you have values that are large arrays for example, they internally just give a pointer to that data structure. (That's, why functional languages are not necessarily slow just because you act on large data and have no references in that language. (A common misunderstanding about functional languages must be slow because they have nor references.) The pointer-stuff is just hidden. Even they ((non-purely) functional languages) may have references, their concept of references is different. (See OCaml for example.) There you can use references to change values in place, but the reference itself is a functional value, and you will never have access to the pointer stuff directly. Hence no problems with mem-arithmetics and dangling pointer's or Null-pointers. [...] > I like R and will continue to use it. However, I also think that > strict "call by value" can get you into trouble, just trouble of a > different kind. Can you elaborate more on this? What problems do you have in mind? And what kind of references do you have in mind? The C-like pointers or something like OCaml's ref's? > I'm not sure we will ever yearn for "Julia ouR-Julia", > but it is sure fun to think about what might be possible with this > language. And having fun is one key objective. I have fun if things work. And if the tools do, what I want to achieve... ...and the fun is better, if they do it elegantly. Do you ask for references in R? And what kind of references do you have in mind, and why does it hurt you not to have them? Can you give examples, so that it's easier to see, whwere you miss something? Ciao, Oliver P.S.: The speed issue of R was coming up more than once; in some blog posts it was mentioned. would it make sense to start a seperated thread of it? In one of the blog-articles I read, it was mourned about how NA / missing values were handled, and that NA should maybe become thrown out, just to get higher speed. I would not like to have that. Handling NA as special case IMHO is a very good way. Don't remember if the article I have in mind just argued about HOW this was handled, or if it should be thrown out completely. Making the handling of it better and more performant I think is a good idea, ignoring NA IMHO is a bad idea. But maybe that really would be worth a seperate thread? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Mon, Mar 05, 2012 at 07:33:10PM -0500, Duncan Murdoch wrote: > On 12-03-05 6:58 PM, Hervé Pagès wrote: > >Hi Oliver, > > > >On 03/05/2012 09:08 AM, oliver wrote: > >>On Mon, Mar 05, 2012 at 03:53:28PM +, William Dunlap wrote: > >>>I haven't used Julia yet, but from my quick reading > >>>of the docs it looks like arguments to functions are > >>>passed by reference and not by value, so functions > >>>can change their arguments. My recollection from when > >>>I first started using S (in the course of a job helping > >>>profs and grad students do statistical programming, c. 1983) > >>>is that not having to worry about in-place algorithms changing > >>>your data gave S a big advantage over Fortran or C. > >>[...] > >> > >> > >>C also uses Call-by-Value. > > > >C *only* uses Call-by-Value. > > While literally true, the fact that you can't send an array by > value, and must send the value of a pointer to it, kind of supports > Bill's point: in C, you mostly end up sending arrays by reference. [...] It's a problem of how the term "reference" is used. If you want to limit the possible confsion, better say: giving the pointer-by-value. Or: giving the address-value of the array/struct/... by value. To say, you give the array reference is a shorthand, which maybe creates confusion. Just avoiding the word "reference" here would make it more clear. AFAIK in C++ references are different to pointers. (Some others who know C++ in detail might explain this in detail.) So, using the same terms for many different concepts can create a mess in understanding. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Tue, Mar 06, 2012 at 12:35:32AM +, William Dunlap wrote: [...] > I find R's (& S+'s & S's) copy-on-write-if-not-copying-would-be-discoverable- > by-the-uer machanism for giving the allusion of pass-by-value a good way > to structure the contract between the function writer and the function user. [...] Can you elaborate more on this, especially on the ...-...-...-if-not-copying-would-be-discoverable-by-the-uer stuff? What do you mean with discoverability of not-copying? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Wed, Mar 07, 2012 at 10:31:14AM -0500, Dominick Samperi wrote:
> On Tue, Mar 6, 2012 at 3:56 AM, oliver wrote:
> > On Mon, Mar 05, 2012 at 04:54:05PM -0800, Nicholas Crookston wrote:
> >> There are many experts on this topic. I'll keep this short.
> >>
> >> Newer Fortran Languages allow for call by value, but call by reference
> >> is the typical and historically, the only approach (there was a time
> >> when you could change the value of 1 to 2!).
> >
> > Oh, strange.
> >
> >
> >>
> >> C "only" calls by value except that the value can be a pointer! So,
> >> havoc is just a * away.
> > [...]
> >
> > For me there was no "havoc" at this point, but for others maybe.
> >
> > There are also other languages that only use call-by-value...
> > ...functional languages are that way in principal.
> >
> > Nevertheless internally they may heavily use pointers and
> > even if you have values that are large arrays for example,
> > they internally just give a pointer to that data structure.
> > (That's, why functional languages are not necessarily slow
> > just because you act on large data and have no references
> > in that language. (A common misunderstanding about functional
> > languages must be slow because they have nor references.)
> > The pointer-stuff is just hidden.
> >
> > Even they ((non-purely) functional languages) may have references,
> > their concept of references is different. (See OCaml for example.)
> > There you can use references to change values in place, but the
> > reference itself is a functional value, and you will never have
> > access to the pointer stuff directly. Hence no problems with
> > mem-arithmetics and dangling pointer's or Null-pointers.
> >
> >
> >
> > [...]
> >> I like R and will continue to use it. However, I also think that
> >> strict "call by value" can get you into trouble, just trouble of a
> >> different kind.
> >
> > Can you elaborate more on this?
> > What problems do you have in mind?
> > And what kind of references do you have in mind?
> > The C-like pointers or something like OCaml's ref's?
>
> OCaml refs are an "escape hatch" from the pure
> functional programming paradigm where nothing can
> be changed once given a value, an extreme form of
> pass-by-value.
OCaml is not a purely functional language and has
not the claim to be one; hence it's not an "escape hatch"
(which seem to have a negative touch to me).
Arrays and strings in OCaml are also imperative.
And with the "mutable" attribute in records, you also can
crearte imperative record entries.
So, it's just a different design / approach than
Haskell for example. OCaml is coming from ML-languages.
Purely Functional on the one hand is beautiful, and
therefore nice; but it also is dogmatic on the other hand.
> Similarly, most languages that are
> advertised as pass-by-value include some kind of
> escape hatch that permits you to work with pointers
> (or mutable vectors) for improved runtime performance.
References in OCaml are NOT pointers.
You do have access in an imperative / in-place way, but you
have NO POINTER STUFF in that language.
# let a = ref 5;;
val a : int ref = {contents = 5}
# a := 7;;
- : unit = ()
# a;;
- : int ref = {contents = 7}
#
This is in-place modification of the contents of the ref,
without any pointer arithmetics.
"a" is a functional value which hosts an imperative one
on the inside.
>
> The speed issues arise for two main reasons: interpreting
> code is much slower than running machine code, and
> copying large data structures can be expensive.
The functional approach often saves time and space.
This is just not well known.
And the distinction of imperative vs. functional has
nothing to do with interpreted vs. directly executed.
# let mylist_1 = [ 3;5;323 ];;
val mylist_1 : int list = [3; 5; 323]
# let mylist_2 = 12 :: mylist_1;;
val mylist_2 : int list = [12; 3; 5; 323]
# mylist_1;;
- : int list = [3; 5; 323]
# mylist_2;;
- : int list = [12; 3; 5; 323]
#
Both lists share the common elements here.
No copy is done.
In this case the functional approach is very nice.
Just a counter-example to "functional is eating up space".
When thinking about the questions here, I think
the design of Ocaml addressed all this, and that this was
the design decision, why arrays are possible to be changed
Re: [Rd] Julia
On Tue, Mar 06, 2012 at 12:49:32PM -0500, Dominick Samperi wrote:
> On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap wrote:
> > S (and its derivatives and successors) promises that functions
> > will not change their arguments, so in an expression like
> > val <- func(arg)
> > you know that arg will not be changed. You can
> > do that by having func copy arg before doing anything,
> > but that uses space and time that you want to conserve.
> > If arg is not a named item in any environment then it
> > should be fine to write over the original because there
> > is no way the caller can detect that shortcut. E.g., in
> > cx <- cos(runif(n))
> > the cos function does not need to allocate new space for
> > its output, it can just write over its input because, without
> > a name attached to it, the caller has no way of looking
> > at what runif(n) returned. If you did
> > x <- runif(n)
> > cx <- cos(x)
You have two names here, x and cx, hence
your example does not fit into what you want to explain.
A better example would be:
x <- runif(n)
x <- cos(x)
> > then cos would have to allocate new space for its output
> > because overwriting its input would affect a subsequent
> > sum(x)
> > I suppose that end-users and function-writers could learn
> > to live with having to decide when to copy, but not having
> > to make that decision makes S more pleasant (and safer) to use.
> > I think that is a major reason that people are able to
> > share S code so easily.
>
> But don't forget the "Holy Grail" that Doug mentioned at the
> start of this thread: finding a flexible language that is also
> fast. Currently many R packages employ C/C++ components
> to compensate for the fact that the R interpreter can be slow,
> and the pass-by-value semantics of S provides no protection
> here.
[...]
The distinction imperative vs. functional has nothing to do
with the distinction interpreted vs. directly executed.
Thinking again on the problem that was mentioned here,
I think it might be circumvented.
Looking again at R's properties, looking again into U.Ligges "Programmieren in
R", I saw there was mentioned that in R anything (?!) is an object... so then
it's
OOP; but also it was mentioned, R is a functional language. But this does not
mean it's purely functional or has no imperative data structures.
As R relies heavily on vectors, here we have an imperative datastructure.
So, it rather looks to me that "<-" does work in-place
on the vectors, even "<-" itself is a function (which does not matter for
the problem).
If thats true (I assume here, it is; correct me, if it's wrong),
then I think, assigning with "<<-" and assign() also would do an imperative
(in-place) change of the contents.
Then the copying-of-big-objects-when-passed-as-args problem can be circumvented
by working on either a variable in the GlobalEnv (and using "<<-", or using a
certain environment for the big data and passing it's name (and the variable)
as value to the function which then uses assign() and get() to work on that
data.
Then in-place modification should be possible.
>
> In 2008 Ross Ihaka and Duncan Temple Lang published the
> paper "Back to the Future: Lisp as a base for a statistical
> computing system" where they propose Common
> Lisp as a new foundation for R. They suggest that
> this could be done while maintaining the same
> familiar R syntax.
>
> A key requirement of any strategy is to maintain
> easy access to the huge universe of existing
> C/C++/Fortran numerical and graphics libraries,
> as these libraries are not likely to be rewritten.
>
> Thus there will always be a need for a foreign
> function interface, and the problem is to provide
> a flexible and type-safe language that does not
> force developers to use another unfamiliar,
> less flexible, and error-prone language to
> optimize the hot spots.
If I here "type safe" I rather would think about OCaml
or maybe Ada, but not LISP.
Also, LISP has so many "("'s and ")"'s,
that it's making people going crazy ;-)
Ciao,
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
Hi, ok, thank you for clarifiying what you meant. You only referred to the reusage of the args, not of an already existing vector. So I overgenerealized your example. But when looking at your example, and how I would implement the cos() I doubt I would use copying the args before calculating the result. Just allocate a result-vector, and then place the cos() of the input-vector into the result vector. I didn't looked at how it is done in R, but I would guess it's like that. In pseudo-Code something like that: cos_val[idx] = cos( input_val[idx] ); But R also handles complex data with cos() so it will look a bit more laborious. What I have seen so far from implementing C-extensions for R is rather C-ish, and so you have the control on many details. Copying the input just to read it would not make sense here. I doubt that R internally is doing that. Or did you found that in the R-code? The other problem, someone mentioned, was *changing* the contents of a matrix... and that this is NO>T done in-place, when using a function for it. But the namespace-name / variable-name as "references" to the matrix might solve that problem. Ciao, Oliver On Wed, Mar 07, 2012 at 07:10:43PM +, William Dunlap wrote: > No my examples are what I meant. My point was that a function, say cos(), > can act like it does call-by-value but conserve memory when it can if it can > distinguish between the case > cx <- cos(x=runif(n)) # no allocation needed, use the input space for the > return value > and and the case >x <- runif(n) >cx <- cos(x=x) # return value cannot reuse the argument's memory, so > allocate space for return value >sum(x) # Otherwise sum(x) would return sum(cx) > The function needs to know if a memory block is referred to by a name in any > environment > in order to do that. > > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > > -Original Message- > > From: oliver [mailto:oli...@first.in-berlin.de] > > Sent: Wednesday, March 07, 2012 10:22 AM > > To: Dominick Samperi > > Cc: William Dunlap; R-devel > > Subject: Re: [Rd] Julia > > > > On Tue, Mar 06, 2012 at 12:49:32PM -0500, Dominick Samperi wrote: > > > On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap > > wrote: > > > > S (and its derivatives and successors) promises that functions will > > > > not change their arguments, so in an expression like > > > > val <- func(arg) > > > > you know that arg will not be changed. You can do that by having > > > > func copy arg before doing anything, but that uses space and time > > > > that you want to conserve. > > > > If arg is not a named item in any environment then it should be fine > > > > to write over the original because there is no way the caller can > > > > detect that shortcut. E.g., in > > > > cx <- cos(runif(n)) > > > > the cos function does not need to allocate new space for its output, > > > > it can just write over its input because, without a name attached to > > > > it, the caller has no way of looking at what runif(n) returned. If > > > > you did > > > > x <- runif(n) > > > > cx <- cos(x) > > > > You have two names here, x and cx, hence your example does not fit into what > > you want to explain. > > > > A better example would be: > > x <- runif(n) > > x <- cos(x) > > > > > > > > > > then cos would have to allocate new space for its output because > > > > overwriting its input would affect a subsequent > > > > sum(x) > > > > I suppose that end-users and function-writers could learn to live > > > > with having to decide when to copy, but not having to make that > > > > decision makes S more pleasant (and safer) to use. > > > > I think that is a major reason that people are able to share S code > > > > so easily. > > > > > > But don't forget the "Holy Grail" that Doug mentioned at the start of > > > this thread: finding a flexible language that is also fast. Currently > > > many R packages employ C/C++ components to compensate for the fact > > > that the R interpreter can be slow, and the pass-by-value semantics of > > > S provides no protection here. > > [...] > > > > The distinction imperative vs. functional has nothing to do with the > > distinction > > interpreted vs. directly executed. > > > > > > > > > > Thinking again on the problem that was mentioned here,
Re: [Rd] Julia
Ah, and you mean if it's an anonymous array
it could be reused directly from the args.
OK, now I see why you insist on the anonymous data thing.
I didn't grasped it even in my last mail.
But that somehow also relates to what I wrote about reusing an already
existing, named vector.
Just the moment of in-place-modification is different.
From
x <- runif(n)
cx <- cos(x)
instead of
> > cx <- cos(x=runif(n)) # no allocation needed, use the input space for
> > the return value
to something like
cx <- runif(n)
cos( cx, inplace=TRUE)
or
cos( runif(n), inplace=TRUE)
This way it would be possible to specify the reusage
of the input *explicitly* (without implicit rules
like anonymous vs. named values).
In Pseudo-Code something like that:
if (in_place == TRUE )
{
input_val[idx] = cos( input_val[idx] );
return input_val;
}
else
{
result_val = alloc_vec( LENGTH(input_val), ... );
result_val[idx] = cos( input_val[idx] );
return result_val;
}
Is this matching, what you were looking for?
Ciao,
Oliver
On Thu, Mar 08, 2012 at 02:56:24PM +0100, oliver wrote:
> Hi,
>
> ok, thank you for clarifiying what you meant.
> You only referred to the reusage of the args,
> not of an already existing vector.
> So I overgenerealized your example.
>
> But when looking at your example,
> and how I would implement the cos()
> I doubt I would use copying the args
> before calculating the result.
>
> Just allocate a result-vector, and then place the cos()
> of the input-vector into the result vector.
>
> I didn't looked at how it is done in R,
> but I would guess it's like that.
>
>
> In pseudo-Code something like that:
> cos_val[idx] = cos( input_val[idx] );
>
> But R also handles complex data with cos()
> so it will look a bit more laborious.
>
> What I have seen so far from implementing C-extensions
> for R is rather C-ish, and so you have the control
> on many details. Copying the input just to read it
> would not make sense here.
>
> I doubt that R internally is doing that.
> Or did you found that in the R-code?
>
> The other problem, someone mentioned, was *changing* the contents
> of a matrix... and that this is NO>T done in-place, when using
> a function for it.
> But the namespace-name / variable-name as "references" to the matrix
> might solve that problem.
>
>
> Ciao,
> Oliver
>
>
>
> On Wed, Mar 07, 2012 at 07:10:43PM +, William Dunlap wrote:
> > No my examples are what I meant. My point was that a function, say cos(),
> > can act like it does call-by-value but conserve memory when it can if it
> > can
> > distinguish between the case
> > cx <- cos(x=runif(n)) # no allocation needed, use the input space for
> > the return value
> > and and the case
> >x <- runif(n)
> >cx <- cos(x=x) # return value cannot reuse the argument's memory, so
> > allocate space for return value
> >sum(x) # Otherwise sum(x) would return sum(cx)
> > The function needs to know if a memory block is referred to by a name in
> > any environment
> > in order to do that.
> >
> > Bill Dunlap
> > Spotfire, TIBCO Software
> > wdunlap tibco.com
> >
> > > -Original Message-
> > > From: oliver [mailto:oli...@first.in-berlin.de]
> > > Sent: Wednesday, March 07, 2012 10:22 AM
> > > To: Dominick Samperi
> > > Cc: William Dunlap; R-devel
> > > Subject: Re: [Rd] Julia
> > >
> > > On Tue, Mar 06, 2012 at 12:49:32PM -0500, Dominick Samperi wrote:
> > > > On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap
> > > wrote:
> > > > > S (and its derivatives and successors) promises that functions will
> > > > > not change their arguments, so in an expression like
> > > > > val <- func(arg)
> > > > > you know that arg will not be changed. You can do that by having
> > > > > func copy arg before doing anything, but that uses space and time
> > > > > that you want to conserve.
> > > > > If arg is not a named item in any environment then it should be fine
> > > > > to write over the original because there is no way the caller can
> > > > > detect that shortcut. E.g., in
> > > > > cx <- cos(runif(n))
> > > > > the cos function does not need to allocate new space for its output,
> > > > > it can just write over its input because, without a name attached to
> > > > > it, the caller has no way of looking at what ru
Re: [Rd] Julia
I don't think that using in-place modification as a general property would make
sense.
In-place modification brings in side-effects and that would mean that
the order of evaluation can change the result.
To get reliable results, the order of evaluation should not be
the reason for different results, and thats the reason, why
the functional approach is much better for reliable programs.
So, in general I would say, this feature is a no-no.
In general I would rather discourage in-place modification.
For some certain cases it might help...
but for such certain cases either such a boolean flag
or programming a sparate module in C would make sense.
There could also be a global in-place-flag that might be used (via options
maybe) but if such a thing would be implemented, the default value should be
FALSE.
Ciao,
Oliver
On Thu, Mar 08, 2012 at 04:21:42PM +, William Dunlap wrote:
> So you propose an inplace=TRUE/FALSE entry for each
> argument to each function which may may want to avoid
> allocating memory? The major problem is that the function
> writer has no idea what the value of inplace should be,
> as it depends on how the function gets called. This makes
> writing reusable functions (hence packages) difficult.
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com
>
> > -Original Message-
> > From: oliver [mailto:oli...@first.in-berlin.de]
> > Sent: Thursday, March 08, 2012 7:40 AM
> > To: William Dunlap
> > Cc: R-devel
> > Subject: Re: [Rd] Julia
> >
> > Ah, and you mean if it's an anonymous array it could be reused directly
> > from the
> > args.
> >
> > OK, now I see why you insist on the anonymous data thing.
> > I didn't grasped it even in my last mail.
> >
> >
> >
> > But that somehow also relates to what I wrote about reusing an already
> > existing, named vector.
> >
> > Just the moment of in-place-modification is different.
> >
> > From
> > x <- runif(n)
> > cx <- cos(x)
> >
> > instead of
> > > > cx <- cos(x=runif(n)) # no allocation needed, use the input
> > > > space for the return value
> >
> > to something like
> >
> > cx <- runif(n)
> > cos( cx, inplace=TRUE)
> >
> > or
> >
> > cos( runif(n), inplace=TRUE)
> >
> >
> >
> >
> > This way it would be possible to specify the reusage of the input
> > *explicitly*
> > (without implicit rules like anonymous vs. named values).
> >
> >
> >
> > In Pseudo-Code something like that:
> >
> >if (in_place == TRUE )
> >{
> > input_val[idx] = cos( input_val[idx] );
> > return input_val;
> >}
> >else
> >{
> > result_val = alloc_vec( LENGTH(input_val), ... );
> > result_val[idx] = cos( input_val[idx] );
> > return result_val;
> >}
> >
> >
> >
> > Is this matching, what you were looking for?
> >
> >
> > Ciao,
> >Oliver
> >
> >
> > On Thu, Mar 08, 2012 at 02:56:24PM +0100, oliver wrote:
> > > Hi,
> > >
> > > ok, thank you for clarifiying what you meant.
> > > You only referred to the reusage of the args, not of an already
> > > existing vector.
> > > So I overgenerealized your example.
> > >
> > > But when looking at your example,
> > > and how I would implement the cos()
> > > I doubt I would use copying the args
> > > before calculating the result.
> > >
> > > Just allocate a result-vector, and then place the cos() of the
> > > input-vector into the result vector.
> > >
> > > I didn't looked at how it is done in R, but I would guess it's like
> > > that.
> > >
> > >
> > > In pseudo-Code something like that:
> > > cos_val[idx] = cos( input_val[idx] );
> > >
> > > But R also handles complex data with cos() so it will look a bit more
> > > laborious.
> > >
> > > What I have seen so far from implementing C-extensions for R is rather
> > > C-ish, and so you have the control on many details. Copying the input
> > > just to read it would not make sense here.
> > >
> > > I doubt that R internally is doing that.
> > > Or did you found that in the R-code?
> > >
> > > The other problem, someone mentioned, was *changing* the contents of a
> > > matrix... and that this is NO>T done in-place, when using a function
> > > for
Re: [Rd] Julia
Aha, ok. So you not especially look at that one feature (like the anonymous evaluation tricks), but in general want to ask for better internal optimization. Especially with your example of the anonymous (unnamed) values given to a function, I would ask: do you want to write programs all without using names/variables? I think this would be much harder than just to add a boolean flag with inplace=TRUE. So your reply on the flag-proposal as too much of bad usability I need to reply with: it's even worse to write code without variable names and put anything into anonymous datastructures, that are called inside function application, and inside each of the arguments there will be more of unnamed calculations. You will end up not only with a mess, but also with slower calculations, because unnamed ressources must be calculated more than once if they will be used more than once. So I think that you are just asking for more internal optimizations. Fine. But I think internal intermediate code (that can be optimized) would be better than that one "enhancement" of reusing anonymous data for the output. Ciao, Oliver On Thu, Mar 08, 2012 at 10:27:22PM +, William Dunlap wrote: > I guess my point is not getting across. The user should see > the functional programming style but under the hood the > evaluator should be able to use whatever memory and time > saving tricks it can. Julia seems to want to be a nonfunctional > language, which I think makes it harder to write the sort of > easily reusable functions that S allows. > > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > > > -Original Message- > > From: oliver [mailto:oli...@first.in-berlin.de] > > Sent: Thursday, March 08, 2012 2:23 PM > > To: William Dunlap > > Cc: R-devel > > Subject: Re: [Rd] Julia > > > > I don't think that using in-place modification as a general property would > > make > > sense. > > > > In-place modification brings in side-effects and that would mean that the > > order > > of evaluation can change the result. > > > > To get reliable results, the order of evaluation should not be the reason > > for > > different results, and thats the reason, why the functional approach is much > > better for reliable programs. > > > > So, in general I would say, this feature is a no-no. > > In general I would rather discourage in-place modification. > > > > For some certain cases it might help... > > but for such certain cases either such a boolean flag or programming a > > sparate > > module in C would make sense. > > > > There could also be a global in-place-flag that might be used (via options > > maybe) but if such a thing would be implemented, the default value should be > > FALSE. > > > > > > > > Ciao, > >Oliver > > > > > > On Thu, Mar 08, 2012 at 04:21:42PM +, William Dunlap wrote: > > > So you propose an inplace=TRUE/FALSE entry for each argument to each > > > function which may may want to avoid allocating memory? The major > > > problem is that the function writer has no idea what the value of > > > inplace should be, as it depends on how the function gets called. > > > This makes writing reusable functions (hence packages) difficult. > > > > > > Bill Dunlap > > > Spotfire, TIBCO Software > > > wdunlap tibco.com > > > > > > > -Original Message- > > > > From: oliver [mailto:oli...@first.in-berlin.de] > > > > Sent: Thursday, March 08, 2012 7:40 AM > > > > To: William Dunlap > > > > Cc: R-devel > > > > Subject: Re: [Rd] Julia > > > > > > > > Ah, and you mean if it's an anonymous array it could be reused > > > > directly from the args. > > > > > > > > OK, now I see why you insist on the anonymous data thing. > > > > I didn't grasped it even in my last mail. > > > > > > > > > > > > > > > > But that somehow also relates to what I wrote about reusing an > > > > already existing, named vector. > > > > > > > > Just the moment of in-place-modification is different. > > > > > > > > From > > > > x <- runif(n) > > > > cx <- cos(x) > > > > > > > > instead of > > > > > > cx <- cos(x=runif(n)) # no allocation needed, use the input > > > > > > space for the return value > > > > > > > > to something like > > > > > > >
[Rd] R's copying of arguments (Re: Julia)
Hello, regarding the copying issue, I would like to point to the "Writing R-Extensions" documentation. There it is mentio9ned, that functions of extensions that use the .C interface normally do get their arguments pre-copied... In section 5.2: "There can be up to 65 further arguments giving R objects to be passed to compiled code. Normally these are copied before being passed in, and copied again to an R list object when the compiled code returns." But for the .Call and .Extension interfaces this is NOT the case. In section 5.9: "The .Call and .External interfaces allow much more control, but they also impose much greater responsibilities so need to be used with care. Neither .Call nor .External copy their arguments. You should treat arguments you receive through these interfaces as read-only." Why is read-only preferred? Please, see the discussion in section 5.9.10. It's mentioned there, that a copy of an object in the R-language not necessarily doies a real copy of that object, but instead of this, just a "rerference" to the real data is created (two names referring to one bulk of data). That's typical functional programming: not a variable, but a name (and possibly more than one name) bound to an object. Of course, if yo change the orgiginal named value, when there would be no copy of it, before changing it, then both names would refer to the changed data. of course that is not, what is wanted. But what you also can see in section 5.9.10 is, that there already is a mechanism (reference counting) that allows to distinguish between unnamed and named object. So, this is directly adressing the points you have mentioned in your examples. So, at least in principial, R allows to do in-place modifications of object with the .Call interface. You seem to refer to the .C interface, and I had explored the .Call interface. That's the reason why you may insist on "it's copyied always" and I wondered, what you were talking about, because the .Call interface allowed me rather C-like raw style of programming (and the user of it to decide, if copying will be done or not). The mechanism to descide, if copying should be done or not, also is mentioined in section 5.9.10: NAMED and SET_NAMED macros. with NAMED you can get the number of references. But later in that section it is mentioned, that - at least for now - NAMED always returns the value 2. "Currently all arguments to a .Call call will have NAMED set to 2, and so users must assume that they need to be duplicated before alteration." (section 5.9.10, last sentence) So, the in-place modification can be done already with the .Call intefcae for example. But the decision if it is safe or not is not supported at the moment. So the situation is somewhere between: "it is possible" and "R does not support a safe decision if, what is possible, also can be recommended". At the moment R rather deprecates in-place modification by default (the save way, and I agree with this default). But it's not true, that R in general copies arguments. But this seems to be true for the .C interface. Maybe a lot of performance-/memory-problems can be solved by rewriting already existing packages, by providing them via .Call instead of .C. Ciao, Oliver On Tue, Mar 06, 2012 at 04:44:49PM +, William Dunlap wrote: > S (and its derivatives and successors) promises that functions > will not change their arguments, so in an expression like >val <- func(arg) > you know that arg will not be changed. You can > do that by having func copy arg before doing anything, > but that uses space and time that you want to conserve. > If arg is not a named item in any environment then it > should be fine to write over the original because there > is no way the caller can detect that shortcut. E.g., in > cx <- cos(runif(n)) > the cos function does not need to allocate new space for > its output, it can just write over its input because, without > a name attached to it, the caller has no way of looking > at what runif(n) returned. If you did > x <- runif(n) > cx <- cos(x) > then cos would have to allocate new space for its output > because overwriting its input would affect a subsequent > sum(x) > I suppose that end-users and function-writers could learn > to live with having to decide when to copy, but not having > to make that decision makes S more pleasant (and safer) to use. > I think that is a major reason that people are able to > share S code so easily. > > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > > -Original Message- > > From: oliver [mailto:oli...@first.in-berlin.de] > > Sent: Tuesday, March 06, 2012 1:12 AM > > To: William Dunlap > > Cc: Hervé
[Rd] malloc/calloc/strdup and R's aequivalents
Hello, when looking at "Writing R Extensions" with mem-allocation in mind, I wondered, which functions to use to substitute malloc(), calloc(), realloc() and strdup() and free(). It looked like Calloc() or R_Calloc() might be useful for some of my tasks, but when trying to use R_Calloc() for example, I got some error messages which I don't see where they are coming from. Maybe I just have forgotten to includ ethe right header file? So, how to use Calloc() / R_Calloc()? What is the prototype of this function/macro? And: what if I just want to easily substitute strdup()/free()? mkChar seems not to be the right thing, because, what I found in the above mentioned documentation, says,m that a C-string is fed in, but CHARSXP is what I get as result. What I try to do, is, to pick some code and port it to R. If I need to rewrite a lot of stuff, just because I need to adapt to R, this would be more effort than if it would be possible just to have some functions, that could make porting easier. For example, if I want to resuse a function, that opens a file and needs a char* stringname then it would add more effort if I need to go via CHARSXP or so. I would need to rewrite many pieces of the code. (Should I implement my own kind of R_str_alloc() ?) My main problem at the moemnt is, that I can use R_alloc() but when I try to use Calloc() or R_Calloc() I can't compile. So, what header-files are necessary, and what are the prototypes of these functions? If nothing of that stuff works, I would need to use the original calloc() / free() functions, which are deprecated in the above mentioned manual. Ciao, Oliver P.S.: Also I wonder... R-alloc() does not need a free()-like call? Is it freed automaticlaly? And at which time? In the docs is mentioned, at the end of the .C/.Call/.External call. Does this mean, this is freed/reclaimed automatically, when returning from the C-world to the R-world? At (after) return of the extension's code? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] malloc/calloc/strdup and R's aequivalents
On Sat, Mar 17, 2012 at 10:08:05PM -0500, Dirk Eddelbuettel wrote: > > On 18 March 2012 at 03:30, oliver wrote: > | Hello, > | > | when looking at "Writing R Extensions" > | with mem-allocation in mind, I wondered, > | which functions to use to substitute > | malloc(), calloc(), realloc() and strdup() and free(). > | > | It looked like Calloc() or R_Calloc() might be useful for > | some of my tasks, but when trying to use R_Calloc() for example, > | I got some error messages which I don't see where they are coming from. > | > | Maybe I just have forgotten to includ ethe right header file? > > Maybe, but we can't tell as you didn't post a reproducible example. Here is > one, and I turned verbose on to give you the (default) headers: [...] It was not a missing header-file. > > R> library(inline) > R> > R> f <- cfunction(signature(), verbose=TRUE, body=' > +double *p = Calloc(5, double); [...] That line cleared the issue. Thank you for providing an example. When reading in the documentation I was not sure, how to interpret "type" in setion 6.1.2. It was meant as the name of the type, and that's, why my sizeof() stuff created the problem. I tried around and then saw, that the name of the type is accepted, not only with typical base-types of C, but it also eats the names of my structs/typedefed structs. OK, so this is the solution... Calloc()'s snd arg is a name of a type. So I assume it will internally use sizeof. As this is rather untypical to the C-ish thinking, and also not aequivalent to the calloc() which is substituted by calloc(), I think, it would be good, if this could be explained clearer / more precise in the Writing Extensions document. For example the R_alloc() prototype is like the one from calloc(). (*) But Calloc() is different here. My first impression was, that it's rather an accident / typo, what was described in the docs, because it was a bit unusual. The usage with names of types is nice; but explaining, that this is not a typo, would be good too. Ciao, Oliver P.S.: (*) Not quite right: calloc() returns void*, but R_alloc() is mentioned to return char*. Here I'm also not sure if this is a typo, and one reason, why I thought the "type" in the following section might also be one. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] malloc/calloc/strdup and R's aequivalents
On Sat, Mar 17, 2012 at 11:47:24PM -0400, Simon Urbanek wrote: [...] > You can always define Strdup() since strdup() is just a shorthand for > malloc()+strcpy() -- in fact in R it's easier since Calloc will never return > NULL so trivially > #define Strdup(X) strcpy(Calloc(strlen(X)+1, char), X) [...] Yes, something like that I had in mind (and already implemented, but nur used so far). I thought maybe something might be also somehoew available as a R-internal adaption. > > But when using Calloc be aware that you have to clean up -- even if there is > an error (which is why it is generally not a good idea to use Calloc for > anything but memory you want to keep beyond your call). Yes. This seems not to be the case for R_alloc() ? > There are two reasons for removing malloc/calloc: a) R uses custom allocators > on systems with poor OS allocators (like Windows) so R's allocation is more > efficient [and combining different allocators even worsens the performance] > and > b) you should think twice about the life span of your objects under error > conditions. It is quite challenging to keep that straight, so in most cases it > is better to use managed memory instead (but there is a performance > trade-off). Yes, good reasons. > There are still valid reasons for not using R's allocators, but those are > special cases that the author must be conscious about (after weighing the > options). Calloc() is provided by R, so it apears as being an R-allocator, but rather seems to be a wrapper around calloc(). With R allocators you mean functions like allocVector()? And R_alloc()? The behaviour of the later one is not clear to me. (A reason to prefer Calloc() here, then the behaviour is under my control, even of it's more "risky". That's the C-ish-way.) > > > > mkChar seems not to be the right thing, because, what I found in the > > above mentioned documentation, says,m that a C-string is fed in, but > > CHARSXP is what I get as result. > > > > What I try to do, is, to pick some code and port it to R. > > If I need to rewrite a lot of stuff, just because I need > > to adapt to R, this would be more effort than if it would be possible > > just to have some functions, that could make porting easier. > > > > For example, if I want to resuse a function, that opens a file > > and needs a char* stringname > > then it would add more effort if I need to go via CHARSXP or so. > > > > I'm not sure where you are going with this, since all strings will already > come as CHARSXPs from R so typically you don't need to allocate anything. The > only reason to allocate is to create persistent objects (for which you'd use > Calloc) - your example doesn't fit here... If I want to copy the filename into a C-struct and then pass (a pointer to) that struct around, then using something like strdup() is a good idea. Therwise the filename-pointer might have vanished and the pointer points into nirvana. That was, where it came from. I used some already existing code, where this all made sense. And extracting char* from the CARSXP once, instead of using something like CHAR( STRING_ELT(filename_sexp, 0) ) at every place, where I may want to have access to that filename makes the code clearer. As this I reused existing code, I tried to change it as less as possible (to make it easy). But as I now see, for the special case here I can forget the strdup() and maybe make my struct smaller (throwing out the filename), because here I call the reader-function with filename as argument, and do not pass around the structure-ptr too much. And I store the filename in the list I give back to the user. (I can do this even in the R-code which calls my C-code.) So in this certain case the problem vanishes. Nevertheless, in other cases it might be a problem. But then maybe never touching the code and just live with the already existing strdup()/malloc/calloc()/free() would also work. I can see the advantages of using R-provided functions. But if they do not substitute all these deprecated functions, then either porting the stand-alone-code to R is made much effort, or the deprecated functions might just stay inside. Do you see what I mean? > > > If nothing of that stuff works, I would need to use the original > > calloc() / free() functions, which are deprecated in the above > > mentioned manual. > > > > > > Ciao, > > Oliver > > > > P.S.: Also I wonder... R-alloc() does not need a free()-like call? > > Is it freed automaticlaly? > > And at which time? > > In the docs is mentioned, at the end of the .C/.Call/.External call. > > Does this mean, this is freed/reclaimed automatically, when returning > > from t
Re: [Rd] R's copying of arguments (Re: Julia)
On Tue, Mar 20, 2012 at 12:08:12PM -0700, Hervé Pagès wrote: [...] > >So the situation is somewhere between: "it is possible" and > >"R does not support a safe decision if, what is possible, also > >can be recommended". > >At the moment R rather deprecates in-place modification by default > >(the save way, and I agree with this default). > > > >But it's not true, that R in general copies arguments. > > > >But this seems to be true for the .C interface. > > > >Maybe a lot of performance-/memory-problems can be solved > >by rewriting already existing packages, by providing them > >via .Call instead of .C. > > My understanding is that most packages use the .C interface > because it's simpler to deal with and because they don't need > to pass complicated objects at the C level, just atomic vectors. > My guess is that it's probably rarely the case that the cost > of copying the arguments passed to .C is significant, but, > if that was the case, then they could always call .C() with > DUP=FALSE. However, using DUP=FALSE is dangerous (see Warning > section in the man page). [...] Yes. I have seen that (DUP=FALSE) in the docs, but while I was writing the answer like a maniac, I forgot it. ;-) Thanks for mentionig it. In the manual also was mentioned, that .Call allows more control. I did not looked at .C and used .Call from the beginning on. It did not looked very complicated. But maybe .C would be much easier. Don't know. > > No need to switch to .Call OK, at least not for the point of DUP-arg. But it seems to me, that when later the names-result will be correctly set to 0, 1 and 2, then such optimisations, which were asked for, could be done "automagically". And to do it safely too. The .C interface with the DUP-arg seems not to allow this. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] drawing the graph with many nodes
Hi, your code does not run in a fresh R environment: Error in getClass(Class, where = topenv(parent.frame())) : "graphAM" is not a defined class If you don't provide working code, it's (too) much effort to help. There are some graph packages arround. Which you need depends on what you want to do. I can't decide that easily, without seeing your example running. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Column(row)wise minimum and maximum
On Thu, Apr 19, 2012 at 06:12:30PM +, Ravi Varadhan wrote: > Hi, > > Currently, the "base" has colSums, colMeans. It seems that it would be > useful to extend this to also include colMin, colMax (of course, rowMin and > rowMax, as well) in order to facilitate faster computations for large vectors > (compared to using apply). Has this been considered before? Please forgive > me > if this has already been discussed before. [...] Not sure if the performance of apply is so much of a problem, but also from a view of consistency of the provided functions, I think offering such functions would make it more clear and consitent to use R here, because all those functions are then available for row and col and the functionality is appended in the name (Mean, Sum etc.). I think the basic things that should be available woud be: - mean - median - min - max - var - sd If both then are available for rows and columns, this would be fine. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Column(row)wise minimum and maximum
On Thu, Apr 19, 2012 at 08:31:56PM +0200, oliver wrote: > On Thu, Apr 19, 2012 at 06:12:30PM +, Ravi Varadhan wrote: > > Hi, > > > > Currently, the "base" has colSums, colMeans. It seems that it would be > > useful to extend this to also include colMin, colMax (of course, rowMin and > > rowMax, as well) in order to facilitate faster computations for large > > vectors > > (compared to using apply). Has this been considered before? Please > > forgive me > > if this has already been discussed before. > [...] > > Not sure if the performance of apply is so much of a problem, > but also from a view of consistency of the provided > functions, I think offering such functions would make > it more clear and consitent to use R here, because > all those functions are then available for row and col > and the functionality is appended in the name (Mean, Sum etc.). > > I think the basic things that should be available woud be: > > - mean > - median > - min > - max > - var > - sd - sum :-) - diff Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Using other peoples packages from within C-based R-extension
Hello, what if I want to write a package mixed R/C-extension and want to use code that is provided by other peoples packages? How for example can I use one of the provided wavelet packages from within my C-based R-extension? Somehow I would need to load the other packages and have access to the functions they provide. I mean I don't want to use the other packages via R-level, but directly on the C-layer. Something like shared libs (dlopen and such stuff) but via R-API. Is there a general aproach to this, and how to do it? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using other peoples packages from within C-based R-extension
Hello, OK, thanks for the information... On Tue, Apr 24, 2012 at 12:02:33PM -0500, Dirk Eddelbuettel wrote: > > On 24 April 2012 at 12:39, Duncan Murdoch wrote: > | On 24/04/2012 12:31 PM, oliver wrote: > | > Hello, > | > > | > what if I want to write a package mixed R/C-extension > | > and want to use code that is provided by other peoples packages? > | > > | > How for example can I use one of the provided wavelet packages > | > from within my C-based R-extension? > | > > | > Somehow I would need to load the other packages and have access to the > | > functions they provide. > | > I mean I don't want to use the other packages via R-level, but directly > | > on the C-layer. Something like shared libs (dlopen and such stuff) > | > but via R-API. > | > > | > Is there a general aproach to this, and how to do it? > | > | See "Registering native routines" in the Writing R Extensions manual. > > And there are over 120 packages providing access: > >CITAN Cubist GOSim KernSmooth MASS MSBVAR Matrix NetComp PMA PopGenome >QuACN RCurl RODBC RTextTools Rcpp Rigroup Rlabkey Rmosek Rmpfr Rook Rserve >Runuran SASxport SMCP SoDA TraMineR XML actuar adaptivetau akima aster >aster2 bcv bda blme boolfun bstats canvas caret catnet cgh chron class >climdex.pcic clpAPI clue cluster copula cplexAPI cplm datamap devEMF >edesign expm fastICA fastcluster ff flsa foreign fracdiff fuzzyRankTests >gb glpkAPI gmp gputools grpreg gsmoothr heavy hypred ifs ifultools int64 >interactivity kza lattice lfe lme4 locfit lpSolveAPI markdown mgcv minqa >mugnet ncvreg nlme nnet pedigreemm phangorn phmm potts ppstat qtbase >qtpaint quadprog rPorta randtoolbox rcdd rdyncall rgeos rggobi rmongodb >rngWELL robustbase rpart rphast rrp rtfbs sde sensitivityPStrat sp spatial >spdep spsurvey spt tree tripack uncompress vines xlsReadWrite xts yaml zoo [...] But no wavelets stuff... (?) (It was more than an example, I'm look for wavelet decompositioning.) > > Matrix and lme4 is the prototypical example by R Core, MASS also provides > something. I'd probably start with zoo and xts ... [...] You mean with "start with" that I could look how to allow exporting for my own package? At the moment I'm rather looking for how to import symbols and access fnuctionality of othera people's packages ... Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading multiple CSV files into a single data frame
On Thu, May 03, 2012 at 11:40:42PM +0200, victor jimenez wrote: > First of all, thank you for the answers. I did not know about zoo. However, > it seems that none approach can do what I exactly want (please, correct me > if I am wrong). > > Probably, it was not clear in my original question. The CSV files only > contain the performance values. The other two columns (ASSOC and SIZE) are > obtained from the existing values in the directory tree. So, in my opinion, > none of the proposed solutions would work, unless every single "data.csv" > file contained all the three columns (ASSOC, SIZE and PERF). [...] Maybe things will be clearer if you would provide an example with the tree and some example data, which you provide as a*.zip file. As I undertand your question, you have a some variables' values stored in the csv-files, and other values of your variables are given as directory structure. So you need to convert the structure of your directory into values fo your dataframe. You need to have a dataframe that contains all possible values that are of interest to you. Some of them are loaded via the csv-load and others are just picked from the directory structure. You just have to fill in the data from the csv into the dataframe, and the values/variables that are implictly given via the directory structure, you just set when importing. Maybe just read in the csv-files and add the missing values. So if the variable on the cahcing mechanism is encode as part of the path to the file, e.g. "direct-mapped", then just set the chace value to "direct-mapped". Ciao, Oliver P.S.: In my understandiung this would be rather r-users instead of r-devel, because I think r-devel seems to be more focussed on internals and package stuff, while your problem is rather a user problem (any R user needs some kind of "programming" to get things done). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] large dataset - confused
On Mon, Jul 23, 2012 at 06:42:17PM +0100, Prof Brian Ripley wrote: [...] > BTW, 'large dataset' is meaningless: when I asked a class of > Statistics PhD students the answers differed by 7 orders of > magnitude. [...] lol But isn't 7 a "small" number? ;-) Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] large dataset - confused
On Mon, Jul 23, 2012 at 10:32:42AM -0700, walcotteric wrote: > I'm trying to load a dataset into R, but I'm completely lost. This is > probably due mostly to the fact that I'm a complete R newb, but it's got me > stuck in a research project. [...] Hmhh, becoming stuck in a "research project", because you are a "complete R newb"? Strange what kind of working style is this? What about first learning the tools you use? > I've tried just opening the text file in WordPad and copying the data > directly into R, but it's too big and causes the program to crash. [...] OMFG > > Any suggestions or assistance? I'm kinda desperate and lost. Looks like this is completely caused by yourself. Check your working style... and follow the hints to the docs that other people on this list suggested to you. There are a lot of good documentatiuons online. Even books for R are available. Look at the library of your "research institute"... Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Who does develop the R core and libs, and how / where is it hosted?
Hello, I saw Binaries, stable release-souzrces and daily snapshots of R, but not something like a repository, visible for the public (like on githb for example). How is the R development handled, what repositories / source code versioning tools are used, who are the developers? And is there something like a plan with future goals, which are planned for the next releases? Are there areas, where help is needed? And in which way could support be done? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Who does develop the R core and libs, and how / where is it hosted?
On Mon, Jan 14, 2013 at 03:50:04PM -0500, Simon Urbanek wrote: > On Jan 14, 2013, at 3:29 PM, oliver wrote: > > > Hello, > > > > I saw Binaries, stable release-souzrces and daily snapshots of R, but > > not something like a repository, visible for the public (like on githb for > > example). > > > > Ehm, I would expect a bit better from someone who is on the list for several > years ;) - the reading the docs - in particular you'll find answers to most of > your questions in the FAQ ... [...] Well, most often, I just save the mailinglist postings into the folder where it belongs to... (Less than even lurking, only sometimes reading some postings.) ...and... when I'm not involved in a task, things start to disappear in from mind. Much traffic in my inbox ;-) Also I thought, sending a direct question might trigger certain responses. There are much FAQs around in the web. A FAQ is less direct, and just one of the many text documents around... Something like "Future plans in development of R" I would not await to be inside a FAQ. > > > > How is the R development handled, what repositories / source code > > versioning tools > > are used, who are the developers? > > > > And is there something like a plan with future goals, > > which are planned for the next releases? > > > > See developer.r-project.org, other than that features are typically announced > in NEWS as they are being implemented. Future goals I would expect not being part of NEWS. NEWS is like "what we already have done", not "what our future plans are". > > > > Are there areas, where help is needed? > > If you have someone with a good R knowledge, check out the wish list. OK, wish list seems to be the right thing. > > > > And in which way could support be done? > > > > Write good packages, provide patches to R, donate to R foundation? [...] "Good packages" might be good (in quality), but not necessarily give the R project a boost, if only a handful of users would need such a package. Providing patches maybe would make sense to me. Donate to R foundation? Hmhh, I would rather donate with via source code. BTW: I looked up the string "wish list" in some of the mentioned docs (mentioned in this thread) but did not found it. Can you please point me to it directly? Googling for "R wish list" brings me links to a producer of toys. Or did you mean I should ask R users for their wishes??! (Some R users - on this list - asked for Julia language as a speedup alternative for R a while ago...) Thanks for the response. All in all it seems like no special things need to be done. The FSF for example has a page where they ask for support in certain areas, so, this looks rather urgent. R seems not to have such urgent needs for support => Question answered. Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] enabling reproducible research & R package management & install.package.version & BiocLite
On Mon, Mar 04, 2013 at 05:04:25PM -0600, Yihui Xie wrote: [...] > With R 3.0.0 coming, it will be easy to achieve what they have > outlined because R 3.0 allows custom vignette builders. Basically, > your research paper can be built with 'R CMD build' and checked with > 'R CMD check' if you provide an appropriate builder. An R package has > the great potential of becoming the ideal tool for reproducible > research due to its wonderful infrastructure: functions, datasets, > examples, unit tests, vignettes, dependency structure, and so on. With > the help of version control, you can easily spot the changes after you > upgrade the packages. [...] A new major release number might be the right point to switch from svn to git. Branch-and-merge made easy :-) Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Submitting packages with weak circular dependencies to CRAN.
Hello, On Fri, Mar 08, 2013 at 07:42:04PM -0500, Pavel N. Krivitsky wrote: > Hello, R-devel, > > I am planning to submit two packages, A and B, to CRAN. Package B uses > an API exported by package A, while package A uses package B to test the > API in question. Thus, package B Depends on, and Enhances, A, and A > Suggests B. [...] Why not putting common stuff of A and B into C and then let A and B depend on C? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Parse-Error creates strange function calls (completely different printouts) (PR#13436)
Full_Name: Oliver Bandel
Version: R version 2.7.1 (2008-06-23)
OS: Linux (Debian Lenny)
Submission from: (NULL) (88.73.82.147)
Hello,
I have written a small R-script.
When I inserted one line of code, the behaviour was completely different!
Instead of just printing one line more to the output,
the complete call of the function in which this line was added,
is different, and instead of one such call, the function seems to be
called more than once!
I just added a line, which prints some data,
but then the printouts were completely different than
expected; and when commenting the new stuff out,
the OK-behaviour came back.
Here a diff of the code:
=
oli...@siouxsie:~/R-BUG$ diff ok.R buggy.R
64c64
< res.txt <- paste(# "\n\n Anzahl der Messungen:", sample_times, "\n",
---
> res.txt <- paste("\n\n Anzahl der Messungen:", sample_times, "\n",
oli...@siouxsie:~/R-BUG$
==
You see, I only wanted to print out a variable.
But the output is much bigger now:
**
oli...@siouxsie:~/R-BUG$ wc -l LOG.*
125 LOG.buggy
50 LOG.ok
175 insgesamt
oli...@siouxsie:~/R-BUG$
**
The variable sample_times is just an array with some numbers:
##
> ls()
[1] "anemo.freq" "anemo.impulse_times" "anemo.T"
[4] "impulse_num" "impuls.messreihe""make_one_sample_set"
[7] "sample.dauer""sample.freq" "sample_num"
[10] "sample.T""sample_times"
> sample_times
[1] 0 1 2 3 4 5 6 7 8 9
> mode(sample_times)
[1] "numeric"
> class(sample_times)
[1] "numeric"
>
######
So, the change in the code could not bring such a strange result!
I could provide the original code for you,
if you need it for testing.
Please send me email, if you need it.
Best,
Oliver Bandel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: put NewEnvironment and R_NewhashedEnv into API
Hi, as Seth Falcon in 2006, I also need to create new environments from package C code. Unfortunately, both NewEnvironment and R_NewHashedEnv are not yet part of the public API, if I understand correctly. Is it planned to add at least one of these functions to the public API in the near future? May I submit a patch? Otherwise I would need to re-implement much of the functionality of R environments in my own code. Many thanks and best regards Oliver -- Dipl. Inform. Oliver Flasch, Institute of Computer Science, Faculty of Computer Science and Engineering Science, Cologne University of Applied Sciences, Steinmüllerallee 1, 51643 Gummersbach phone: +49 171 6447868 eMail: oliver.fla...@fh-koeln.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] system(wait = FALSE)
I'm having a very odd problem with system(wait = FALSE). I'm not
entirely sure whether it's a bug in R or a problem on our end. It's
related to a post a month or so ago in R-help which got no responses,
but I have a little more to add.
This command works as expected (I use c:\tmp since c:\ isn't normally
writable under later versions of Windows). The file is created at
c:\tmp\tmp.txt.
system("cmd /c dir > c:\\tmp\\tmp.txt", wait = TRUE)
This command does not work as expected. There is no file created at
c:\tmp\tmp.txt.
system("cmd /c dir > c:\\tmp\\tmp.txt", wait = FALSE)
The computer is a 64-bit Windows Server 2008R2 machine. This affects
R 2.12.1, both the 32-bit and 64-bit RGui executables but not the
RTerm executables. This does not affect 32-bit Windows XP, 32-bit
Windows Server 2003, or 64-bit Windows Server 2008. This does not
affect R 2.12.0, and if I'm reading the svn logs correctly, there were
some changes made to the system function from 2.12.0 to 2.12.1.
Things seem to work normally when R is started from the start menu
recent programs list, but things do not work properly when R is
started from a shortcut, from the start menu all programs menu, or
through explorer.
I'm stumped. Any ideas I can try?
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] system(wait = FALSE)
Sorry, I didn't know about r-wind...@r-project.org. Is that a public
mailing list like r-help? It's not listed under
http://www.r-project.org/mail.html.
I was able to reproduce the issue under two other 32-bit Windows 7
machines, so it's not specific to the one computer. It could be
something common to my Windows user account configurations, although
those accounts are not all configured similarly. The part that's the
strangest to me is that things do work when R is started through the
start menu recent programs and when called from a command shell, but
not through shortcuts or the start menu all programs list. Sys.getenv
does not indicate any particular difference. Are there any other
things I might check in R?
The actual command I want to run has quoting concerns (inherent to
Windows and cmd) that force me to use system. If you don't like cmd
/c dir, this command also serves the purpose and also shows the weird
behavior. It presumes that Rscript is on the path:
system("Rscript -e \"writeLines(letters,
\\\"C:tmptmp.txt\\\")\"", wait = FALSE)
I've been told (and can see) that shell just calls system, and since
the equivalent command in shell shows the same behavior due to this
weirdness I'm finding with system, I decided to focus on what appeared
to be the underlying problem (although perhaps not the actual problem
if it is just something with me).
Oliver
On Wed, Feb 23, 2011 at 11:07 PM, Prof Brian Ripley
wrote:
> On Wed, 23 Feb 2011, Oliver Soong wrote:
>
>> I'm having a very odd problem with system(wait = FALSE). I'm not
>> entirely sure whether it's a bug in R or a problem on our end. It's
>> related to a post a month or so ago in R-help which got no responses,
>> but I have a little more to add.
>
> Well, the place you are asked to report issues on the Windows port is
> r-wind...@r-project.org. But no one was able to reproduce this, and it
> does sound as if the problem is on your specific machine. If so, only you
> can debug it and find out if it is really in R.
>
>> This command works as expected (I use c:\tmp since c:\ isn't normally
>> writable under later versions of Windows).
>
> That's a bold claim (and untrue of my Windows 7 systems), but if c:\ is not
> writeable, you cannot create c:\tmp!
>
>> The file is created at
>> c:\tmp\tmp.txt.
>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = TRUE)
>> This command does not work as expected. There is no file created at
>> c:\tmp\tmp.txt.
>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = FALSE)
>
> Windows' own programs are peculiar things, and often do not obey Windows'
> own rules for everyone else. So I give little weight to such an example.
> And in any case, we recommend shell() for such usages.
>
>> The computer is a 64-bit Windows Server 2008R2 machine. This affects
>> R 2.12.1, both the 32-bit and 64-bit RGui executables but not the
>> RTerm executables. This does not affect 32-bit Windows XP, 32-bit
>> Windows Server 2003, or 64-bit Windows Server 2008. This does not
>> affect R 2.12.0, and if I'm reading the svn logs correctly, there were
>> some changes made to the system function from 2.12.0 to 2.12.1.
>> Things seem to work normally when R is started from the start menu
>> recent programs list, but things do not work properly when R is
>> started from a shortcut, from the start menu all programs menu, or
>> through explorer.
>>
>> I'm stumped. Any ideas I can try?
>>
>> Oliver
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] system(wait = FALSE)
The targets are identical. In fact, I located the exact shortcut
listed as the start menu recent programs entry, and it's the same one
used in the all programs entry (there's some Windows magic going on
here that I don't necessarily understand). Running that through
explorer or the all programs menu gives the weird behavior, and
running it through the recent programs list gives me the expected
behavior.
Oliver
On Thu, Feb 24, 2011 at 3:54 PM, Gabor Grothendieck
wrote:
> On Thu, Feb 24, 2011 at 2:46 PM, Oliver Soong wrote:
>> Sorry, I didn't know about r-wind...@r-project.org. Is that a public
>> mailing list like r-help? It's not listed under
>> http://www.r-project.org/mail.html.
>>
>> I was able to reproduce the issue under two other 32-bit Windows 7
>> machines, so it's not specific to the one computer. It could be
>> something common to my Windows user account configurations, although
>> those accounts are not all configured similarly. The part that's the
>> strangest to me is that things do work when R is started through the
>> start menu recent programs and when called from a command shell, but
>> not through shortcuts or the start menu all programs list. Sys.getenv
>> does not indicate any particular difference. Are there any other
>> things I might check in R?
>
> Right click the particular start menu recent program entry that starts
> it and choose properties; also right click the shortcut and choose
> properties and right click the start menu programs list entry and
> choose properties. See what the differences are in the targets.
>
>
>
>
>
>>
>> The actual command I want to run has quoting concerns (inherent to
>> Windows and cmd) that force me to use system. If you don't like cmd
>> /c dir, this command also serves the purpose and also shows the weird
>> behavior. It presumes that Rscript is on the path:
>> system("Rscript -e \"writeLines(letters,
>> \\\"C:tmptmp.txt\\\")\"", wait = FALSE)
>>
>> I've been told (and can see) that shell just calls system, and since
>> the equivalent command in shell shows the same behavior due to this
>> weirdness I'm finding with system, I decided to focus on what appeared
>> to be the underlying problem (although perhaps not the actual problem
>> if it is just something with me).
>>
>> Oliver
>>
>>
>> On Wed, Feb 23, 2011 at 11:07 PM, Prof Brian Ripley
>> wrote:
>>> On Wed, 23 Feb 2011, Oliver Soong wrote:
>>>
>>>> I'm having a very odd problem with system(wait = FALSE). I'm not
>>>> entirely sure whether it's a bug in R or a problem on our end. It's
>>>> related to a post a month or so ago in R-help which got no responses,
>>>> but I have a little more to add.
>>>
>>> Well, the place you are asked to report issues on the Windows port is
>>> r-wind...@r-project.org. But no one was able to reproduce this, and it
>>> does sound as if the problem is on your specific machine. If so, only you
>>> can debug it and find out if it is really in R.
>>>
>>>> This command works as expected (I use c:\tmp since c:\ isn't normally
>>>> writable under later versions of Windows).
>>>
>>> That's a bold claim (and untrue of my Windows 7 systems), but if c:\ is not
>>> writeable, you cannot create c:\tmp!
>>>
>>>> The file is created at
>>>> c:\tmp\tmp.txt.
>>>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = TRUE)
>>>> This command does not work as expected. There is no file created at
>>>> c:\tmp\tmp.txt.
>>>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = FALSE)
>>>
>>> Windows' own programs are peculiar things, and often do not obey Windows'
>>> own rules for everyone else. So I give little weight to such an example.
>>> And in any case, we recommend shell() for such usages.
>>>
>>>> The computer is a 64-bit Windows Server 2008R2 machine. This affects
>>>> R 2.12.1, both the 32-bit and 64-bit RGui executables but not the
>>>> RTerm executables. This does not affect 32-bit Windows XP, 32-bit
>>>> Windows Server 2003, or 64-bit Windows Server 2008. This does not
>>>> affect R 2.12.0, and if I'm reading the svn logs correctly, there were
>>>> some changes made to the system function from 2.12.0 to 2.12.1.
>>>> Things seem to work normally when R is started from the start menu
>>>>
[Rd] How to seed the R random number generator in C (standalone) with an instance of .Random.seed
hello all,
I use the R standalone math library in my own C program, and the default R
random number generator can be seeded with
set_seed(const unsigned int, const unsigned int).
How could I seed the RNG with an instance of .Random.seed ?
I would need this or a similar workaround for debugging purposes.
More precisely, I use the default R random number generator to sample from
various distributions in my own C code
SEED<- .Random.seed
save(SEED, args, file= "last.call.R")
out<- .Call("my.fun", args)
and can reproduce segmentation faults etc via
load("last.call.R")
.Random.seed<- SEED
out<- .Call("my.fun", args)
In order to use valgrind, I wrote a little C program "debug.my.fun" that
reads in 'args' and 'SEED',
and then calls "my.fun" (without the SEXP overhead of course).
But the seeds are not set accordingly and segmentation faults are not
reproducible.
More precisely, I need to replace the set_seed line in the following snippet
with something else.
#include
int main(int argc,char* argv[])
{
const unsigned int SEED1= 12345, SEED2= 67890;
set_seed(SEED1, SEED2);
...
}
Thanks in advance,
Oliver
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays
+1. Very grateful; more consistency is always great :)
On Wednesday, 7 September 2016, robin hankin wrote:
> Martin
>
> I'd like to make a comment; I think that R's behaviour on 'edge' cases like
> this is an important thing and it's great that you are working on it.
>
> I make heavy use of zero-extent arrays, chiefly because the dimnames are an
> efficient and logical way to keep track of certain types of information.
>
> If I have, for example,
>
> a <- array(0,c(2,0,2))
> dimnames(a) <- list(name=c('Mike','Kevin'),NULL,item=c("hat","scarf"))
>
>
> Then in R-3.3.1, 70800 I get
>
> > a>0
> logical(0)
> >
>
> But in 71219 I get
>
> > a>0
> , , item = hat
>
>
> name
> Mike
> Kevin
>
> , , item = scarf
>
>
> name
> Mike
> Kevin
>
> (which is an empty logical array that holds the names of the people and
> their clothes). I find the behaviour of 71219 very much preferable because
> there is no reason to discard the information in the dimnames.
>
>
> Best wishes
>
> Robin
>
>
>
>
> On Wed, Sep 7, 2016 at 9:49 PM, Martin Maechler <
> maech...@stat.math.ethz.ch >
> wrote:
>
> > > Martin Maechler >
> > > on Tue, 6 Sep 2016 22:26:31 +0200 writes:
> >
> > > Yesterday, changes to R's development version were committed,
> > relating
> > > to arithmetic, logic ('&' and '|') and
> > > comparison/relational ('<', '==') binary operators
> > > which in NEWS are described as
> >
> > > SIGNIFICANT USER-VISIBLE CHANGES:
> >
> > > [.]
> >
> > > • Arithmetic, logic (‘&’, ‘|’) and comparison (aka
> > > ‘relational’, e.g., ‘<’, ‘==’) operations with arrays now
> > > behave consistently, notably for arrays of length zero.
> >
> > > Arithmetic between length-1 arrays and longer non-arrays had
> > > silently dropped the array attributes and recycled. This
> > > now gives a warning and will signal an error in the future,
> > > as it has always for logic and comparison operations in
> > > these cases (e.g., compare ‘matrix(1,1) + 2:3’ and
> > > ‘matrix(1,1) < 2:3’).
> >
> > > As the above "visually suggests" one could think of the changes
> > > falling mainly two groups,
> > > 1) <0-extent array> (op)
> > > 2) <1-extent array> (arith)
> >
> > > These changes are partly non-back compatible and may break
> > > existing code. We believe that the internal consistency gained
> > > from the changes is worth the few places with problems.
> >
> > > We expect some package maintainers (10-20, or even more?) need
> > > to adapt their code.
> >
> > > Case '2)' above mainly results in a new warning, e.g.,
> >
> > >> matrix(1,1) + 1:2
> > > [1] 2 3
> > > Warning message:
> > > In matrix(1, 1) + 1:2 :
> > > dropping dim() of array of length one. Will become ERROR
> > >>
> >
> > > whereas '1)' gives errors in cases the result silently was a
> > > vector of length zero, or also keeps array (dim & dimnames) in
> > > cases these were silently dropped.
> >
> > > The following is a "heavily" commented R script showing (all ?)
> > > the important cases with changes :
> >
> > >
> >
> >
> > > (m <- cbind(a=1[0], b=2[0]))
> > > Lm <- m; storage.mode(Lm) <- "logical"
> > > Im <- m; storage.mode(Im) <- "integer"
> >
> > > ## 1. -
> > > try( m & NULL ) # in R <= 3.3.x :
> > > ## Error in m & NULL :
> > > ## operations are possible only for numeric, logical or complex
> > types
> > > ##
> > > ## gives 'Lm' in R >= 3.4.0
> >
> > > ## 2. -
> > > m + 2:3 ## gave numeric(0), now remains matrix identical to m
> > > Im + 2:3 ## gave integer(0), now remains matrix identical to Im
> > (integer)
> >
> > > m > 1 ## gave logical(0), now remains matrix identical to Lm
> > (logical)
> > > m > 0.1[0] ## ditto
> > > m > NULL ## ditto
> >
> > > ## 3. -
> > > mm <- m[,c(1:2,2:1,2)]
> > > try( m == mm ) ## now gives error "non-conformable arrays",
> > > ## but gave logical(0) in R <= 3.3.x
> >
> > > ## 4. -
> > > str( Im + NULL) ## gave "num", now gives "int"
> >
> > > ## 5. -
> > > ## special case for arithmetic w/ length-1 array
> > > (m1 <- matrix(1,1,1, dimnames=list("Ro","col")))
> > > (m2 <- matrix(1,2,1, dimnames=list(c("A","B"),"col")))
> >
> > > m1 + 1:2 # -> 2:3 but now with warning to "become ERROR"
> > > tools::assertError(m1 & 1:2)# ERR: dims [product 1] do not match
> the
> > length of object [2]
> > > tools::assertError(m1 < 1:2)# ERR: (ditto)
> > > ##
> > > ## non-0-length arrays combined with {NULL or double() or ...}
> *fail*
> >
> > > ### Length-1 arrays: Arithmetic with |vectors| > 1 treated array
> > as scalar
> >
Re: [Rd] Running package tests and not stop on first fail
On Friday, 4 November 2016, Martin Maechler wrote: > > Dirk Eddelbuettel > > > on Fri, 4 Nov 2016 10:36:52 -0500 writes: > > > On 4 November 2016 at 16:24, Martin Maechler wrote: | My > > proposed name '--no-stop-on-error' was a quick shot; if | > > somebody has a more concise or better "English style" > > wording | (which is somewhat compatible with all the other > > options you see | from 'R CMD check --help'), | please > > speak up. > > > Why not keep it simple? The similar feature this most > > resembles is 'make -k' and its help page has > > >-k, --keep-going > > >Continue as much as possible after an > > error. While the target that failed, and those that > > depend on it, cannot be remade, the other dependencies of > > these targets can be processed all the same. > > Yes, that would be quite a bit simpler and nice in my view. > One may think it to be too vague, Mmn, I would agree on vagueness (and it breaks the pattern set by other flags of human-readability). Deep familiarity with make is probably not something we should ask of everyone who needs to test a package, too. I quite like stop-on-error=true (exactly the same as the previous suggestion but shaves off some characters by inverting the Boolean) notably from Brian Pedersen's mentioning that the examples are > already continued in any case if they lead to an error. > > Other opinions? > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion for "Writing R Extensions"
Hello, Zitat von "Joshua Ulrich" (Wed, 22 Aug 2012 12:35:51 -0500) [...] Would it make sense to add links and/or mention the relevant appendices (A and D) of "R Installation and Administration"? [...] I do not understad, what your question is all about. Maybe you should be more verbose. Do you want to make the document better, or do you have questions on how to understand what it talks about? Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] valgrind crashing
Zitat von David (Wed, 12 Sep 2012 01:38:50 -0400) I am trying to do a classic R -d valgrind --vanilla < mypkg-Ex.R as described in http://cs.swan.ac.uk/~csoliver/ok-sat-library/internet_html/doc/doc/R/2.9.1/doc/manual/R-exts.html#Using-valgrind The problem is valgrind crashes imediately. [...] LOL. ...maybe you can use valgrind to debug valgrind... :-> Ciao, Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] installation of R (2.14.1 and 2.15.1) fails due to [reg-packages.Rout] Error
0
> ##
> ## Part 2: -- build, install, load and "inspect" the package:
> dir.exists <- function(x)
+ is.character(x) && file.exists(x) && file.info(path.expand(x))$isdir
> build.pkg <- function(dir) {
+ stopifnot(dir.exists(dir))
+ patt <- paste(basename(dir), ".*tar\\.gz$", sep="_")
+ unlink(dir('.', pattern = patt))
+ Rcmd <- paste(file.path(R.home("bin"), "R"), "CMD")
+ r <- tail(system(paste(Rcmd, "build --keep-empty-dirs", dir),
+ intern = TRUE), 3)
+ ## return name of tar file built
+ dir('.', pattern = patt)
+ }
> build.pkg("myTst")
[1] "myTst_1.0.tar.gz"
> ## clean up any previous attempt (which might have left a 00LOCK)
> unlink("myLib", recursive = TRUE)
> dir.create("myLib")
> install.packages("myTst", lib = "myLib", repos=NULL, type = "source") # with
> warnings
* installing *source* package 'myTst' ...
** R
** preparing package for lazy loading
** help
Warning:
/home/csoliver/OKplatform/ExternalSources/builds/R/R-2.14.1/tests/myTst/man/myTst-package.Rd:34:
All text must be in a section
Warning:
/home/csoliver/OKplatform/ExternalSources/builds/R/R-2.14.1/tests/myTst/man/myTst-package.Rd:35:
All text must be in a section
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
* DONE (myTst)
> print(installed.packages(lib.loc= "myLib", priority= "NA"))## (PR#13332)
Package LibPath Version Priority Depends Imports LinkingTo Suggests
myTst "myTst" "myLib" "1.0" NA "methods" NA NANA
Enhances OS_type License Built
myTst NA NA "What license is it under?" "2.14.1"
> stopifnot(require("myTst",lib = "myLib"))
Loading required package: myTst
> sm <- findMethods(show, where= as.environment("package:myTst"))
> stopifnot(names(sm@names) == "foo")
> unlink("myTst_*")
>
> ## More building & installing packages
> ## NB: tests were added here for 2.11.0.
> ## NB^2: do not do this in the R sources!
> ## and this testdir is not installed.
> pkgSrcPath <- file.path(Sys.getenv("SRCDIR"), "Pkgs")
> if(file_test("-d", pkgSrcPath)) {
+ ## could use file.copy(recursive = TRUE)
+ system(paste('cp -r', shQuote(pkgSrcPath), shQuote(tempdir(
+ pkgPath <- file.path(tempdir(), "Pkgs")
+ #op <- options(warn = 2)# There should be *NO* warnings here!
+ ## pkgB tests an empty R directory
+ dir.create(file.path(pkgPath, "pkgB", "R"), recursive = TRUE,
+showWarnings = FALSE)
+ p.lis <- c("pkgA", "pkgB", "exNSS4")
+ for(p. in p.lis) {
+ cat("building package", p., "...\n")
+ r <- build.pkg(file.path(pkgPath, p.))
+ cat("installing package", p., "using file", r, "...\n")
+ ## we could install the tar file ... (see build.pkg()'s definition)
+ install.packages(r, lib = "myLib", repos=NULL, type = "source")
+ stopifnot(require(p.,lib = "myLib", character.only=TRUE))
+ detach(pos = match(p., sub("^package:","", search(
+ }
+ ## TODO: not just print, but check the "list":
+ res <- installed.packages(lib.loc = "myLib", priority = "NA")
+ print(res)
+ #options(op)
+ unlink("myLib", recursive = TRUE)
+ unlink(file.path(pkgPath), recursive = TRUE)
+ }
building package pkgA ...
installing package pkgA using file pkgA_1.1.tar.gz ...
Error in untar2(tarfile, files, list, exdir) : unsupported entry type 'x'
Loading required package: pkgA
Error: require(p., lib = "myLib", character.only = TRUE) is not TRUE
In addition: Warning messages:
1: In install.packages(r, lib = "myLib", repos = NULL, type = "source") :
installation of package 'pkgA_1.1.tar.gz' had non-zero exit status
2: In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return
= TRUE, :
there is no package called 'pkgA'
Execution halted
---
Unfortunatly the above says nothing to me, and I didn't find information
on the Internet.
I hope somebody can help. In the past the build-process worked (at least
for R-version 2.14.1) with Suse 11.2 and gcc version 4.5.3.
Thanks for your attention.
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Who does develop the R core and libs, and how / where is it hosted?
Am 15.01.2013 um 01:11 schrieb Brian Lee Yung Rowe : > > On Jan 14, 2013, at 6:32 PM, oliver wrote: > >> BTW: I looked up the string "wish list" in some of the mentioned docs >> (mentioned in this thread) >> but did not found it. >> Can you please point me to it directly? >> Googling for "R wish list" brings me links to a producer of toys. >> >> Or did you mean I should ask R users for their wishes??! >> >> (Some R users - on this list - asked for Julia language as a speedup >> alternative for R a while agoâ¦) > > Is this what you're looking for: http://developer.r-project.org/ (see TODO > lists) Ah, yes,there are TODO lists, thanks. This is at least some kind of thing yi was looking for. But these are personell TODO lists. Are their any goals for R as whole project? > > >> All in all it seems like no special things need to be done. >> The FSF for example has a page where they ask for support in certain areas, >> so, this looks rather urgent. >> R seems not to have such urgent needs for support > > How about cleaning up some of the documentation/wiki pages? I'm not a friend of seperating design, coding, documentation, ... IMHO this should be something that is not seperated. And I also think, that the way, R packages will be written (code as well as documentation together) uses the same kind of philosophy. I was very happy about this close relation between code and documentation,mthat is necessary to wrte a package. I thought the same holds true for R project as a whole. So I maybe was wrong with this assumption. Ciao, Olver [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pairs, par
Hi,
I posted over at R-help, and didn't get a response, but perhaps that
was the wrong forum for this question. I'm having some confusion over
the coordinate system after using pairs. I'm not interested in the
content of the actual pairs plot, although the number of pairs seems
to matter a bit. I'm purely interested in knowing where subsequent
points will be plotted on the device. However, after using pairs, the
par information (omd, fig, plt, and usr) don't reflect what points
does. For example:
pairs(iris[1:5])
par(xpd = NA)
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
par(c("omd", "fig", "plt", "usr"))
The resulting plot shows that the corners of the are approximately
0.05 user coordinate units from the boundaries of the plot region.
According to par, though, there is a margin around the plotting region
that is clearly not symmetric and does not correspond to around 0.05
units.
If we use pairs(iris[1:2]) and repeat the rest, the corners are now
0.02 user coordinate units. par provides the same information as
before.
So:
1. How do I figure out where coordinates I give to points will display
on the figure?
2. More generally (for my own understanding), why does the par
information not do what I expect? Do I have some fundamental
misunderstanding of the arrangement of plotting, figure, display, and
margin regions within the device? Is there a bug in pairs and/or par?
I'm using R 2.5.1, and this behavior occurs on a fresh R console.
Thanks!
Oliver
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pairs, par
I dug around in pairs, and I think it has something to do with the
on.exit(par(opar)) bit:
f <- function() {
opar <- par(mfrow = c(2, 2), mar = rep(0.5, 4), oma = rep(4, 4))
on.exit(par(opar))
for(i in 1:4) plot(0:1, 0:1)
par(c("mfg", "omd", "fig", "plt", "usr"))
print(opar)
}
f()
par(xpd = NA)
par(c("omd", "fig", "plt", "usr"))
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
My guess is that there are 2 sets of graphical parameters, the ones
stored in par and the ones used by the plotting functions. Before
par(opar) gets called, the two are synchronized. When par(opar) gets
called, we somehow set new values for par without changing the ones
used by the plotting functions, and the data used by points becomes
out of sync with the par information.
This is reflected in this much simpler example:
x11()
par(c("omd", "fig", "plt", "usr"))
points(0, 0)
Again, par is defined, but this time the data used by the plotting
functions has not been set, and an error occurs.
Thanks for the workaround suggestion. I guess I can always define a
new plotting region to force par and the plotting data to
re-synchronize. It might be nice if those two didn't go out of sync,
as I had assumed par would always be reliable.
Oliver
On 10/29/07, Tony Plate <[EMAIL PROTECTED]> wrote:
> I would look into the code for pairs(). Among other things, it sets and
> restores par(mfrow=...). I suspect this is the relevant issue, not the
> use of pairs(). I would try to figure out what state a graphics device
> is in after resetting par("mfrow"). When I try the following (R 2.6.0
> patched, under Windows), I see a line on the plot, but not in a place
> that corresponds to the axis that were drawn by the 'plot()' command:
>
> > par(mfrow=c(2,2))
> > plot(1:2)
> > par(mfrow=c(1,1))
> > lines(1:2,1:2)
> >
>
> (and if you want to be able to set up a new coordinate system on the
> plotting device to draw on top of the plot left by pairs(), look at
> par("new") & something like plot(0:1, type='n', axes=F, xlab=""))
>
> hope this helps,
>
> Tony Plate
>
> Oliver Soong wrote:
> > Hi,
> >
> > I posted over at R-help, and didn't get a response, but perhaps that
> > was the wrong forum for this question. I'm having some confusion over
> > the coordinate system after using pairs. I'm not interested in the
> > content of the actual pairs plot, although the number of pairs seems
> > to matter a bit. I'm purely interested in knowing where subsequent
> > points will be plotted on the device. However, after using pairs, the
> > par information (omd, fig, plt, and usr) don't reflect what points
> > does. For example:
> >
> > pairs(iris[1:5])
> > par(xpd = NA)
> > points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
> > points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
> > points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
> > points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
> > par(c("omd", "fig", "plt", "usr"))
> >
> > The resulting plot shows that the corners of the are approximately
> > 0.05 user coordinate units from the boundaries of the plot region.
> > According to par, though, there is a margin around the plotting region
> > that is clearly not symmetric and does not correspond to around 0.05
> > units.
> >
> > If we use pairs(iris[1:2]) and repeat the rest, the corners are now
> > 0.02 user coordinate units. par provides the same information as
> > before.
> >
> > So:
> > 1. How do I figure out where coordinates I give to points will display
> > on the figure?
> > 2. More generally (for my own understanding), why does the par
> > information not do what I expect? Do I have some fundamental
> > misunderstanding of the arrangement of plotting, figure, display, and
> > margin regions within the device? Is there a bug in pairs and/or par?
> >
> > I'm using R 2.5.1, and this behavior occurs on a fresh R console.
> >
> > Thanks!
> >
> > Oliver
> >
> >
> >
>
>
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows installer, HTML help, R 2.10.0
I'm not 100% sure this hasn't been covered already (I searched a bit, but I had a little trouble filtering down to a useful number of useful results). Anyway, when I install R on Windows, the installer asks to set the default help type. For some reason, I can set it as HTML in the installer, but the results open as if help_type = "text" by default. I presume this is related to the new changes to the help. Calling help(help, help_type = "html") works as expected, so the HTML help works and I could manually fix this by setting options(help_type = "html") in a session or in my .Rprofile. I'm not sure if I'm the only one seeing this, but for what it's worth, I also set SDI and Internet = Standard. I haven't experimented with different installation settings to see which ones work. Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Master's project to coerce linux nvidia drivers to run generalised linear models
Hi, I am working with a friend on a master's project. Our laboratory does a lot of statistical analysis using the R stats package and we also have a lot of under-utilised nvidia cards sitting in the back of our networked linux machines. Our idea is to coerce the linux nvidia driver to run some of our statistical analysis for us. Our first thought was to specifically code up a version of glm() to run on the nvidia cards... Thinking that this might be of use to the broader community we thought we might ask for feedback before starting? Any ideas... Thanks, Olly __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] MacOS X - R crashes & import problem (PR#9005)
Full_Name: Oliver Balmer Version: 2.3.1 OS: Mac OS 10.4.6 Submission from: (NULL) (157.161.74.75) when working in the editor R crashes regularly. no other program ever crashes. one quite reliable way to crash it is by marking some code and then pressing the "find" command. I have had this problem with other R versions before. I have the feeling the editor is the problem. Another problem with the editor is that I always need to hit the carriage return twice after inserting the cursor at a certain point, after the first time, nothing happens. Not a big problem but probably not as it should be, and maybe a hint for a deeper problem. Another bug: if the imported data frame contains a µ (greek mu, as in microliter), R can't read the file. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nlminb with constraints failing on some platforms
Hello, > sessionInfo() R version 3.5.2 (2018-12-20) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Debian GNU/Linux 9 (stretch) Matrix products: default BLAS/LAPACK: /opt/intel/compilers_and_libraries_2019.1.144/linux/mkl/lib/intel64_lin/libmkl_rt.so 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=en_CA.UTF-8LC_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 loaded via a namespace (and not attached): [1] compiler_3.5.2 > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) > str(opt) List of 6 $ par: num [1:10] 1 1 1 1 1 ... $ objective : num -41.4 $ convergence: int 0 $ iterations : int 67 $ evaluations: Named int [1:2] 98 850 ..- attr(*, "names")= chr [1:2] "function" "gradient" $ message: chr "relative convergence (4)" > xhat <- rep(1, 10) > all.equal(opt$par, xhat, tol=0) # good: 5.53 e-7 [1] "Mean relative difference: 5.349781e-07" > all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12 [1] "Mean relative difference: 3.81e-12" > abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE [1] TRUE On 2019-02-01 4:23 p.m., Rui Barradas wrote: > Hello, > > R 3.5.2 on ubuntu 18.04. sessionInfo() at the end. > Works with me, same results, cannot reproduce the error. > > > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) > str(opt) > > xhat <- rep(1, 10) > all.equal(opt$par, xhat, tol=0) # good: 5.53 e-7 > #[1] "Mean relative difference: 5.534757e-07" > all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12 > #[1] "Mean relative difference: 1.816536e-12" > abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE > #[1] TRUE > > > Hope this helps, > > Rui Barradas > > > sessionInfo() > R version 3.5.2 (2018-12-20) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 18.04.1 LTS > > Matrix products: default > BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 > LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 > > locale: > [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C > [3] LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8 > [5] LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=pt_PT.UTF-8 > [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] Rcpp_1.0.0 rstudioapi_0.8 bindr_0.1.1 magrittr_1.5 > [5] tidyselect_0.2.5 munsell_0.5.0 colorspace_1.3-2 lattice_0.20-38 > [9] R6_2.3.0 rlang_0.3.0.1 stringr_1.3.1 plyr_1.8.4 > [13] dplyr_0.7.8 tools_3.5.2 grid_3.5.2 yaml_2.2.0 > [17] assertthat_0.2.0 tibble_1.4.2 crayon_1.3.4 bindrcpp_0.2.2 > [21] purrr_0.2.5 reshape2_1.4.3 glue_1.3.0 stringi_1.2.4 > [25] compiler_3.5.2 pillar_1.3.1 scales_1.0.0 lubridate_1.7.4 > [29] pkgconfig_2.0.2 zoo_1.8-4 > > > > > Às 09:00 de 01/02/2019, Martin Maechler escreveu: >>> Kasper Kristensen via R-devel >>> on Mon, 28 Jan 2019 08:56:39 + writes: >> >> > I've noticed unstable behavior of nlminb on some Linux >> > systems. The problem can be reproduced by compiling >> > R-3.5.2 using gcc-8.2 and running the following snippet: >> >> > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) >> > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) >> > xhat <- rep(1, 10) >> > abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE >> >> > The example works perfectly when removing the bounds. However, >> when bounds are added the snippet returns 'FALSE'. >> >> > An older R version (3.4.4), compiled using the same gcc-8.2, >> did not have the problem. Between the two versions R has changed the >> flags to compile Fortran sources: >> >> > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store >> > --- >> >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse >> >> > Reverting to the old SAFE_FFLAGS 'solves' the problem. >> >> >> sessionInfo() >> > R version 3.5.2 (2018-12-20) >> > Platform: x86_64-pc-linux-gnu (64-bit) >> > Running under: Scientific Linux release 6.4 (Carbon) >> >> > Matrix products: default >> > BLAS/LAPACK: >> /zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so >> >> >> > locale: >> > [1] C >> >> > attached base packages: >> > [1] stats graphics grDevices utils datasets methods >> base >> >> > loaded via a namespace
Re: [Rd] [External] Possible ALTREP bug
*_ELT accessor functions are described in "vector accessor functions" in
Writing R extensions.
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Vector-accessor-functions
On Wed, Jun 16, 2021 at 4:22 PM Toby Hocking wrote:
> By the way, where is the documentation for INTEGER_ELT, REAL_ELT, etc? I
> looked in Writing R Extensions and R Internals but I did not see any
> mention.
> REAL_ELT is briefly mentioned on
> https://svn.r-project.org/R/branches/ALTREP/ALTREP.html
> Would it be possible to please add some mention of them to Writing R
> Extensions?
> - how many of these _ELT functions are there? INTEGER, REAL, ... ?
> - in what version of R were they introduced?
> - I guess input types are always SEXP and int?
> - What are the output types for each?
>
> On Fri, May 28, 2021 at 5:16 PM wrote:
>
> > Since the INTEGER_ELT, REAL_ELT, etc, functions are fairly new it may
> > be possible to check that places where they are used allow for them to
> > allocate. I have fixed the one that got caught by Gabor's example, and
> > a rchk run might be able to pick up others if rchk knows these could
> > allocate. (I may also be forgetting other places where the _ELt
> > methods are used.) Fixing all call sites for REAL, INTEGER, etc, was
> > never realistic so there GC has to be suspended during the method
> > call, and that is done in the dispatch mechanism.
> >
> > The bigger problem is jumps from inside things that existing code
> > assumes will not do that. Catching those jumps is possible but
> > expensive; doing anything sensible if one is caught is really not
> > possible.
> >
> > Best,
> >
> > luke
> >
> > On Fri, 28 May 2021, Gabriel Becker wrote:
> >
> > > Hi Jim et al,
> > > Just to hopefully add a bit to what Luke already answered, from what I
> am
> > > recalling looking back at that bioconductor thread Elt methods are used
> > in
> > > places where there are hard implicit assumptions that no garbage
> > collection
> > > will occur (ie they are called on things that aren't PROTECTed), and
> > beyond
> > > that, in places where there are hard assumptions that no error
> (longjmp)
> > > will occur. I could be wrong, but I don't know that suspending garbage
> > > collection would protect from the second one. Ie it is possible that an
> > > error *ever* being raised from R code that implements an elt method
> could
> > > cause all hell to break loose.
> > >
> > > Luke or Tomas Kalibera would know more.
> > >
> > > I was disappointed that implementing ALTREPs in R code was not in the
> > cards
> > > (it was in my original proposal back in 2016 to the DSC) but I trust
> Luke
> > > that there are important reasons we can't safely allow that.
> > >
> > > Best,
> > > ~G
> > >
> > > On Fri, May 28, 2021 at 8:31 AM Jim Hester
> > wrote:
> > > From reading the discussion on the Bioconductor issue tracker it
> > > seems like
> > > the reason the GC is not suspended for the non-string ALTREP Elt
> > > methods is
> > > primarily due to performance concerns.
> > >
> > > If this is the case perhaps an additional flag could be added to
> > > the
> > > `R_set_altrep_*()` functions so ALTREP authors could indicate if
> > > GC should
> > > be halted when that particular method is called for that
> > > particular ALTREP
> > > class.
> > >
> > > This would avoid the performance hit (other than a boolean
> > > check) for the
> > > standard case when no allocations are expected, but allow
> > > authors to
> > > indicate that R should pause GC if needed for methods in their
> > > class.
> > >
> > > On Fri, May 28, 2021 at 9:42 AM wrote:
> > >
> > > > integer and real Elt methods are not expected to allocate. You
> > > would
> > > > have to suspend GC to be able to do that. This currently can't
> > > be done
> > > > from package code.
> > > >
> > > > Best,
> > > >
> > > > luke
> > > >
> > > > On Fri, 28 May 2021, Gábor Csárdi wrote:
> > > >
> > > > > I have found some weird SEXP corruption behavior with
> > > ALTREP, which
> > > > > could be a bug. (Or I could be doing something wrong.)
> > > > >
> > > > > I have an integer ALTREP vector that calls back to R from
> > > the Elt
> > > > > method. When this vector is indexed in a lapply(), its first
> > > element
> > > > > gets corrupted. Sometimes it's just a type change to
> > > logical, but
> > > > > sometimes the corruption causes a crash.
> > > > >
> > > > > I saw this on macOS from R 3.5.3 to 4.2.0. I created a small
> > > package
> > > > > that demonstrates this:
> > > https://github.com/gaborcsardi/redfish
> > > > >
> > > > > The R callback in this package calls
> > > `loadNamespace("Matrix")`, but
> > > > > the same crash happens for other packages as well,
