Re: [Rd] should base R have a piping operator ?

[Jeff Ryan]

Is there some concrete example of your “many workflows don’t even make much
sense without pipes nowadays” comment?

I don’t think I’m opposed to pipes in the absolute, but as I am now deep
into my second decade of using R I’ve done just fine without them. As I
would guess have the vast majority of users and code that is used
throughout the world.

Jeff

On Sat, Oct 5, 2019 at 09:34 Ant F  wrote:

> Dear R-devel,
>
> The most popular piping operator sits in the package `magrittr` and is used
> by a huge amount of users, and imported /reexported by more and more
> packages too.
>
> Many workflows don't even make much sense without pipes nowadays, so the
> examples in the doc will use pipes, as do the README, vignettes etc. I
> believe base R could have a piping operator so packages can use a pipe in
> their code or doc and stay dependency free.
>
> I don't suggest an operator based on complex heuristics, instead I suggest
> a very simple and fast one (>10 times than magrittr in my tests) :
>
> `%.%` <- function (e1, e2) {
>   eval(substitute(e2), envir = list(. = e1), enclos = parent.frame())
> }
>
> iris %.% head(.) %.% dim(.)
> #> [1] 6 5
>
> The difference with magrittr is that the dots must all be explicit (which
> sits with the choice of the name), and that special magrittr features such
> as assignment in place and building functions with `. %>% head() %>% dim()`
> are not supported.
>
> Edge cases are not surprising:
>
> ```
> x <- "a"
> x %.% quote(.)
> #> .
> x %.% substitute(.)
> #> [1] "a"
>
> f1 <- function(y) function() eval(quote(y))
> f2 <- x %.% f1(.)
> f2()
> #> [1] "a"
> ```
>
> Looking forward for your thoughts on this,
>
> Antoine
>
> [[alternative HTML version deleted]]
>
> __
> 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] How do you make a formal "feature" request?

[Jeff Ryan]

The *user* decides.  That would be YOU.

Unlike SAS no one has a responsibility to YOU to implement some random request.

Packages are how things are implemented.

And to continue a previous thread ... maybe you should RTFM.

Jeff

On Sat, Aug 21, 2010 at 10:41 AM, Donald Winston  wrote:
> Who decides what features are in R and how they are implemented? If there is 
> someone here who has that authority I have this request:
>
> A report() function analogous to the plot() function that makes it easy to 
> generate a report from a table of data. This should not be in some auxiliary 
> package, but part of the core R just like plot(). As a long time SAS user I 
> cannot believe R does not have this. Please don't give me any crap about 
> Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll 
> your own" plot do you? Reports are no different. If you don't agree do not 
> bother me. If you agree then please bring this request to the appropriate 
> authorities for consideration or tell me how to do it.
>
> Thanks.
>        [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeff.a.r...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Stats not loaded? Method for as.ts() results in error

[Jeff Ryan]

Janko,

You don't mention if you are using S3 or S4.  A small example would
make it easier to identify where your problem is.

Jeff

On Fri, Sep 3, 2010 at 4:44 AM, Janko Thyson
 wrote:
> Dear list,
>
>
>
> I've got the following problem:
>
>
>
> In a package I'm trying to build, there exists a method for the function
> "as.ts()". When checking the package, R always throws the error that it
> cannot find a function called "as.ts". To me it seems that the package
> "stats" (home of "as.ts()") is not loaded during the checking process even
> though it's a base package. For testing, I've written a method for "plot()"
> to see if it's a general problem with base-functions, but this one passes
> just fine.
>
>
>
> Did anyone of encounter a similar problem or could help me out with a hint?
>
>
>
> Thank you very much,
>
> Janko
>
>
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



-- 
Jeffrey Ryan
jeff.a.r...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Strange behaviour of read and writeBin

[Jeff Ryan]

from ?seek

‘seek’ returns the current position (before any move), as a
 (numeric) byte offset from the origin, if relevant, or ‘0’ if not.

Your string is nul terminated (9 bytes long).  That would be the
current offset. If you only read one byte, you'd have to be more than
0 bytes offset.

Jeff

On Fri, Feb 4, 2011 at 4:35 AM, Christian Ruckert
 wrote:
> To me it seems like writeBin() writes one char/byte more than expected.
>
>> con <- file("testbin", "wb")
>> writeBin("ttccggaa", con)
>> close(con)
>
>> con <- file("testbin", "rb")
>> readBin(con, what="character")
> [1] "ttccggaa"
>> seek(con, what=NA)
> [1] 9
>> close(con)
>
>> con <- file("testbin", "rb")
>> readBin(con, what="raw", n=20)
> [1] 74 74 63 63 67 67 61 61 00
>> seek(con, what=NA)
> [1] 9
>> close(con)
>
> As the numbering starts with 0 the position should be 8 and not 9 after
> reading. There were two older threads which look very similar to my problem:
>
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/11/1119.html
> http://r.789695.n4.nabble.com/Re-Problem-reading-binaries-created-with-fortran-More-infos-td974396.html
>
> Thanks in advance,
> Christian
>
>
>
>> sessionInfo()
> R version 2.12.0 (2010-10-15)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
> [1] C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> other attached packages:
> [1] Biostrings_2.18.2 IRanges_1.8.8
>
> loaded via a namespace (and not attached):
> [1] Biobase_2.10.0
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] terribly annoying bug with POSIXlt : one o'clock is midnight?

[Jeff Ryan]

Much of TZ-hell (I almost dare say all) has been sorted through in xts.

  http://cran.r-project.org/web/packages/xts/index.html

Peruse the sources for inspiration or just take some comfort in that
you are not the only one ;-)

Jeff

On Fri, Feb 4, 2011 at 9:24 AM, Joris Meys  wrote:
> Been too fast : I am in Central European Time (GMT +1), which explains
> the time conversion. Still, I find it highly annoying that as.POSIXlt
> assumes that the time is given in GMT and has to be converted to
> whatever timezone you're in if you don't specify anything.
>
> Probably this behaviour is not going to be changed, but it's causing
> very hard-to-track-down bugs nonetheless.
>
> Cheers
> Joris
>
> On Fri, Feb 4, 2011 at 4:21 PM, Joris Meys  wrote:
>> Apparently, as.POSIXlt takes one o'clock as the start of the day :
>>
>>> as.POSIXlt(0,origin="1970-01-01")
>> [1] "1970-01-01 01:00:00 CET"
>>> as.POSIXlt(0,origin="1970-01-01 00:00:00")
>> [1] "1970-01-01 01:00:00 CET"
>>> as.POSIXlt(0,origin="1970-01-01 23:59:59")
>> [1] "1970-01-02 00:59:59 CET"
>>
>> Cheers
>>
>>
>>
>> --
>> Joris Meys
>> Statistical consultant
>>
>> Ghent University
>> Faculty of Bioscience Engineering
>> Department of Applied mathematics, biometrics and process control
>>
>> tel : +32 9 264 59 87
>> joris.m...@ugent.be
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Applied mathematics, biometrics and process control
>
> tel : +32 9 264 59 87
> joris.m...@ugent.be
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] matching symbols to objects

[Jeff Ryan]

Patrick,

Take a look at all.vars to start with  That will return the vars as
characters, from there you can use get to test/proceed.

> all.vars(parse.tree)
[1] "x"


Best,
Jeff

On Fri, Feb 4, 2011 at 1:37 PM, Patrick Leyshock  wrote:
> Hello,
>
> I'm trying to access an object, given only its name as a symbol.  I cannot
> figure out how to proceed.  Suppose I call substitute( ) on the expression
> 'x + 2':
>
>> parse.tree <- substitute(x + 2);
>
> The constituents of parse.tree are of type symbol and numeric:
>
>> str(parse.tree[[1]])
> symbol +
>
>> str(parse.tree[[2]])
> symbol x
>
>> str(parse.tree[[3]])
> num 2
>
> Suppose that x is S4 object, and that I need to access a slot of that
> object.  How can I do so, using only 'parse.tree' (or parse.tree coerced
> into a list)?
>
> Thanks, Patrick
>
>        [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
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)

[Jeff Ryan]

Oliver,

For an example of moving averages, take a look at the C source of the xts and 
TTR packages. The sources are browsable on R-forge. 

In short, REAL etc are functions to extract the data of an SEXP. They need to 
match the types coming in. So your C needs to check the type and branch 
accordingly. 

It is all in the guide as well as in working example code in R sources as well 
as many hundreds of package sources. You have access to it all, so spend the 
time just reading the sources is my recommendation.  

Best,
Jeff

Jeffrey Ryan|Founder|jeffrey.r...@lemnica.com

www.lemnica.com

On Jun 3, 2011, at 3: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
>>> 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Performance of .C and .Call functions vs. native R code

[Jeff Ryan]

The .Call overhead isn't the issue. If you'd like some insight into what you 
are doing wrong (and right), you need to provide code for the list to reproduce 
your timings with.

This is outlined in the posting guide as well.

Best,
Jeff



On Jul 13, 2011, at 8:28 AM, asmahani  wrote:

> Hello,
> 
> I am in the process of writing an R extension for parallelized MCMC, with
> heavy use of compiled code (C++). I have been getting my feet wet by
> implementing a simple matrix-vector multiplication function in C++ (which
> calls a BLAS level 2 function dgemv), and comparing it to the '%*%' operator
> in R (which apparently calls a BLAS level 3 function dgemm).
> 
> Interestingly, I cannot replicate the performance of the R native operator,
> using either '.C' or '.Call'. The relative times are 17 (R), 30 (.C), and 26
> (.Call). In other words, R native operator is 1.5x faster than my compiled
> code. Can you explain to me why this is? Through testing I strongly suspect
> that the BLAS function itself isn't what takes the bulk part of the time,
> but perhaps data transfer and other overhead associated with the calls (.C
> and .Call) are the main issues. Are there any ways to reach the performance
> level of native R code in this case?
> 
> Thank you,
> Alireza Mahani
> 
> --
> View this message in context: 
> http://r.789695.n4.nabble.com/Performance-of-C-and-Call-functions-vs-native-R-code-tp3665017p3665017.html
> Sent from the R devel mailing list archive at Nabble.com.
> 
> __
> 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

[Rd] tzone DB lawsuit Implications for R-project?

[Jeff Ryan]

Does anyone from core have a comment on the implications for the R-project on 
this:

http://www.theregister.co.uk/2011/10/07/unix_time_zone_database_destroyed/

Given the inclusion of the TZ database with R as well as the functionality used 
by R, is this something that the FSF is looking at yet?

Best,Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] fast version of split.data.frame or conversion from data.frame to list of its rows

[Jeff Ryan]

A bit late and possibly tangential. 

The mmap package has something called struct() which is really a row-wise array 
of heterogenous columns.

As Simon and others have pointed out, R has no way to handle this natively, but 
mmap does provide a very measurable performance gain by orienting rows together 
in memory (mapped memory to be specific).  Since it is all "outside of R" so to 
speak, it (mmap) even supports many non-native types, from bit vectors to 64 
bit ints with conversion caveats applicable. 

example(struct) shows some performance gains with this approach. 

There are even some crude methods to convert as is data.frames to mmap struct 
object directly (hint: as.mmap)

Again, likely not enough to shoehorn into your effort, but worth a look to see 
if it might be useful, and/or see the C design underlying it. 

Best,
Jeff

Jeffrey Ryan|Founder|jeffrey.r...@lemnica.com

www.lemnica.com

On May 1, 2012, at 1:44 PM, Antonio Piccolboni  wrote:

> On Tue, May 1, 2012 at 11:29 AM, Simon Urbanek
> wrote:
> 
>> 
>> On May 1, 2012, at 1:26 PM, Antonio Piccolboni 
>> wrote:
>> 
>>> It seems like people need to hear more context, happy to provide it. I am
>>> implementing a serialization format (typedbytes, HADOOP-1722 if people
>> want
>>> the gory details) to make R and Hadoop interoperate better (RHadoop
>>> project, package rmr). It is a row first format and it's already
>>> implemented as a C extension for R for lists and atomic vectors, where
>> each
>>> element  of a vector is a row. I need to extend it to accept data frames
>>> and I was wondering if I can use the existing C code by converting a data
>>> frame to a list of its rows. It sounds like the answer is that it is not
>> a
>>> good idea,
>> 
>> Just think about it -- data frames are lists of *columns* because the type
>> of each column is fixed. Treating them row-wise is extremely inefficient,
>> because you can't use any vector type to represent such thing (other than a
>> generic vector containing vectors of length 1).
>> 
> 
> Thanks, let's say this together with the experiments and other converging
> opinions lays the question to rest.
> 
> 
>>> that's helpful too in a way because it restricts the options. I
>>> thought I may be missing a simple primitive, like a t() for data frames
>>> (that doesn't coerce to matrix).
>> 
>> See above - I think you are misunderstanding data frames - t() makes no
>> sense for data frames.
>> 
> 
> I think you are misunderstanding my use of t(). Thanks
> 
> 
> Antonio
> 
> 
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> On Tue, May 1, 2012 at 5:46 AM, Prof Brian Ripley >> wrote:
>>> 
 On 01/05/2012 00:28, Antonio Piccolboni wrote:
 
> Hi,
> I was wondering if there is anything more efficient than split to do
>> the
> kind of conversion in the subject. If I create a data frame as in
> 
> system.time({fd =  data.frame(x=1:2000, y = rnorm(2000), id =
>> paste("x",
> 1:2000, sep =""))})
> user  system elapsed
> 0.004   0.000   0.004
> 
> and then I try to split it
> 
> system.time(split(fd, 1:nrow(fd)))
>> 
> user  system elapsed
> 0.333   0.031   0.415
> 
> 
> You will be quick to notice the roughly two orders of magnitude
>> difference
> in time between creation and conversion. Granted, it's not written
> anywhere
> 
 
 Unsurprising when you create three orders of magnitude more data frames,
 is it?  That's a list of 2000 data frames.  Try
 
 system.time(for(i in 1:2000) data.frame(x = i, y = rnorm(1), id =
 paste0("x", i)))
 
 
 
 that they should be similar but the latter seems interpreter-slow to me
> (split is implemented with a lapply in the data frame case) There is
>> also
> a
> memory issue when I hit about 2 elements (allocating 3GB when
> interrupted). So before I resort to Rcpp, despite the electrifying
>> feeling
> of approaching the bare metal and for the sake of getting things done,
>> I
> thought I would ask the experts. Thanks
> 
 
 You need to re-think your data structures: 1-row data frames are not
 sensible.
 
 
 
> 
> Antonio
> 
> [[alternative HTML version deleted]]
> 
> 
> __**
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/r-devel<
>> 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/<
>> http://www.stats.ox.ac.uk/~ripley/>
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595
 
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> ___

Re: [Rd] chown, chgrp?

[Jeff Ryan]

library(pwned)?

On Wed, Aug 15, 2012 at 10:56 AM, Barry Rowlingson
 wrote:
> On Wed, Aug 15, 2012 at 2:47 PM, Simon Urbanek
>  wrote:
>
>>
>> ... and moreover with the increasing adoption of ACL on unix and 
>> non-existence of uid/gid on Windows this is more an archaic curiosity so I 
>> don't think it makes sense to add it at this point.
>>
>
>  It does however raise the question, "What is Hadley up to now?" :)
>
> Barry
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] include dll in R-package

[Jeff Ryan]

Any package can link to external DLLs.  You'll need to make that an
explicit dependency, have some configure script and distribute the
library somewhere else, but many packages on CRAN already do this.

My RBerkeley uses a user installed Oracle Berkeley DB that is linked
to at configure time, of course there are many other examples as well.

And distributing _off_ CRAN is of course a reasonable alternative.

HTH
Jeff

On Fri, Aug 24, 2012 at 9:21 AM, Kasper Daniel Hansen
 wrote:
> On Fri, Aug 24, 2012 at 10:16 AM, Dirk Eddelbuettel  wrote:
>
>>
>> On 24 August 2012 at 09:06, LIYING HUANG wrote:
>> | We have several projects in the center done by researchers over years
>> | in Fortran, there are copy right issues etc to prevent us from
>> 
>> | giving away the source codes, but a lot of social scientist are
>>   
>> | interested to use the program. We tried to use dlls to make plugins
>> | (available in our website) in various statistics platforms
>> | (SAS, STATA and R) to make it available to general public.
>> |
>> | We used to be able to build R package using dll on version R-2.7.0,
>> | , but failed to build with newer R version with the same source.
>> | Any help is greatly appreciated.
>> |
>> | When I try to build R package for newer version of R, I could build
>> | to get "lcca_1.0.0.tar.gz", but when I "R CMD check lcca_1.0.0.tar.gz",
>> | I got error message as:
>> |
>> | * using log directory 'D:/project/LCCA/lcca.Rcheck'
>> | * using R version 2.15.1 (2012-06-22)
>> | * using platform: i386-pc-mingw32 (32-bit)
>> | * using session charset: ISO8859-1
>> | * checking for file 'lcca/DESCRIPTION' ... OK
>> | * checking extension type ... Package
>> | * this is package 'lcca' version '1.0.0'
>> | * checking package namespace information ... OK
>> | * checking package dependencies ... OK
>> | * checking if this is a source package ... OK
>> | * checking if there is a namespace ... OK
>> | * checking for executable files ... WARNING
>> | Found the following executable file(s):
>> |   libs/lcca.dll
>> | Source packages should not contain undeclared executable files.
>> | See section 'Package structure' in the 'Writing R Extensions' manual.
>> | * checking whether package 'lcca' can be installed ... ERROR
>>
>> This tells you that in order to have a proper package, you need to include
>> the very source code you want to hide.
>>
>> This is a CRAN Policy decision enforced by current R versions (but not the
>> rather old version you compared against), and there is now way around it.
>> You could try to construct "defunct" packages lacking the DLLs and instruct
>> the users to get them from somewhere else, but that is at the same rather
>> error prone (as you will lack all the built-time checks you would have with
>> source code, as well as a better assurrance that compatible tools are used)
>> and distasteful as CRAN is about Open Source.
>>
>> So your best bet may be to go back to the copyright holders
>>
>
> Dirk's comments are extremely relevant if you were hoping to host the
> package on CRAN (which you basically won't be allowed to).  You can still
> distribute it from your institutions homepage I think.
>
> Kasper
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Arrays Partial unserialization

[Jeff Ryan]

There is no such tool to my knowledge, though the mmap package can do
very similar things.  In fact, it will be able to do this exactly once
I apply a contributed patch to handle endianess.

The issue is that rds files are compressed by default, so directly
reading requires uncompressing, which makes subset selection not
possible, at least to the best of my knowledge of the compression
algorithms in use. (BDR's reply after this one clarifies)

What you can do though is writeBin by column, and read in
incrementally.  Take a look at the mmap package, specifically:

example(mmap)
example(struct)
example(types)

The struct one is quite useful for data.frame like structures on disk,
including the ability to modify struct padding etc.  This one is more
row oriented, so lets you store various types in row-oriented fashion
in one file.

?mmap.csv is an example function that will also let you read csv files
directly into an 'mmap' form - and shows the 'struct' functionality.

At some point I will write an article on all of this, but the vignette
for mmap is illustrative of most of the value.

The indexing package on R-forge (as well as talks about it given by me
at useR 2010 and R/Finance 2012) may also be of use - though that is
more 'database' rather than a more simplistic sequential stepping
through data on disk.

HTH
Jeff

On Fri, Aug 31, 2012 at 9:41 AM, Duncan Murdoch
 wrote:
> On 31/08/2012 9:47 AM, Damien Georges wrote:
>>
>> Hi all,
>>
>> I'm working with some huge array in R and I need to load several ones to
>> apply some functions that requires to have all my arrays values for each
>> cell...
>>
>> To make it possible, I would like to load only a part (for example 100
>> cells) of all my arrays, apply my function, delete all cells loaded,
>> loaded following cells and so on.
>>
>> Is it possible to unserialize (or load) only a defined part of an R array
>> ?
>> Do you know some tools that might help me?
>
>
> I don't know of any tools to do that, but there are tools to maintain large
> objects in files, and load only parts of them at a time, e.g. the ff
> package.  Or you could simply use readBin and writeBin to do the same
> yourself.
>
>>
>> Finally, I did lot of research to find the way array (and all other R
>> object) are serialized into binary object, but I found nothing
>> explaining really algorithms involved. If someone has some information
>> on this topic, I'm interesting in.
>
>
> You can read the source for this; it is in src/main/serialize.c.
>
> Duncan Murdoch
>
>>
>> Hoping my request is understandable,
>>
>> All the best,
>>
>> Damien.G
>>
>> __
>> 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



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R crashes when printing a named numeric vector of a specific class - Bug?

[Jeff Ryan]

print(x) in print.bar is calling print.bar again.

You need to do something like print(unclass(x))

HTH
Jeff

On Tue, Sep 11, 2012 at 9:53 AM, Basil Abou El-Komboz
 wrote:
> Dear useR's,
>
> today I stumbled over an interesting phenomenon: First, I created a
> named numeric vector with a certain class and several attributes via the
> structure() function. After that, I implemented a simple print method
> for this class. When calling this function it produces an endless loop
> of print calls until R crashes. :/
>
> What is going on here? Is this a bug or have I done something completely
> wrong? :)
>
> Below is a minimal example which reproduces the behavior. Be careful
> when calling foo() as this automatically calls print.bar() which causes
> R to crash (at least on my PC, see further informations about my system 
> below.)
>
> Greetings,
> Basil
>
> --
>
> Minimal example:
>
> foo <- function () {
>  x <- c("A" = 1.3, "B" = 0.7, "C" = -0.3)
>  structure(x, class = "bar")
> }
>
> print.bar <- function (x, ...) {
>   print(x, ...)
> }
>
> --
>
> Further informations about my system:
>
>> version
>   _
> platform   x86_64-unknown-linux-gnu
> arch   x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status
> major  2
> minor  15.1
> year   2012
> month  06
> day22
> svn rev59600
> language   R
> version.string R version 2.15.1 (2012-06-22)
> nickname   Roasted Marshmallows
>
>> sessionInfo()
>
> R version 2.15.1 (2012-06-22)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C   
> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
>  [6] LC_MESSAGES=en_US.UTF-8LC_PAPER=C LC_NAME=C  
> LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.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_2.15.1 tools_2.15.1
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] methods cbind2 bind_activation disrupts cbind everywhere

[Jeff Ryan]

Refreshing the memory on performance:

http://r.789695.n4.nabble.com/reduce-limit-number-of-arguments-in-methods-cbind-td921600.html#a921601

My issue had been resolved by a more careful approach taken by timeSeries.

The other option is wholesale deprecation of S4 ... but I won't start
that conversation with either of you ;-)

Jeff

On Fri, Sep 14, 2012 at 3:00 AM, Martin Maechler
 wrote:
>> Martin Morgan 
>> on Wed, 12 Sep 2012 15:23:02 -0700 writes:
>
> > The methods package ?cbind2 includes the instruction to
> > use via methods:::bind_activation(TRUE).
>
> well, "instruction" only if one wants to magically enable its
> use for cbind(), rbind()
>
> > use via methods:::bind_activation(TRUE). This changes the
> > default definition of cbind globally, disrupting proper
> > evaluation in packages not using cbind2.
>
> { really disrupting?  I seem to only recall examples of
>   performance loss, but that memory is fading.. }
>
> > evaluation in packages not using cbind2. Is cbind2 a
> > hold-over from a time when ... could not be used for
> > dispatch?
>
> Yes, exactly.
>
> As I'm sure you know well, and   ?dotMethods  explains,
> the ... dispatch was introduced only in R 2.8.0,
> *and* if you read that help page, it is alluded to several times
> that the implementation is still not "perfect" because it
> entails restrictions, and also because its implementation in
> pure R rather than (partially) C.
>
> I had hoped (but not spent work myself, alas!) that there would
> be evolution from there on, but it seems we forgot about it.
>
> > What is a safe way for a package to use cbind2?
>
> to define methods for cbind2 / rbind2, with nice multiple
> dispatch on both arguments,  as the 'Matrix' package has been
> doing for many years (long before R 2.8.0) --> Matrix/R/bind.R
>
> And then, instead of "bind_activation",
> Matrix now also defines  cBind() & rBind()
> as substitutes for cbind(), rbind(),
> simply as using  methods:::cbind()  which recursively calls
> cbind2(), rbind2().
>
> This has still the big drawback that  cbind() fails on "Matrix"
> matrices {and even with quite an unhelpful error message!},
> and useRs must learn to use cBind() instead
> not ideal, at all.
>
>
> In an ideal R world,
> 1) the "..." S4 dispatch would be improved and made faster
> 2) that part of Matrix would be rewritten, so that  cbind() and rbind()
>would work via '...' dispatch on both "Matrix" matrices and
>all standard R objects (atomic vectors, "matrix", data.frame,...),
>and the use of cBind() and rBind() could be deprecated.
>
> I also have a vague recollection that '2)' was not just a job to
> be done with finite some effort, but rather seemed not easily
> achievable with the current restriction of "..." dispatch
> needing all arguments to be of the same superclass.
> We would have to define
>
>  setGeneric("cbind", signature = "...")
>  setGeneric("rbind", signature = "...")
>
>  setMethod("cbind", "Mnumber", function(..., deparse.level=1) {
>  
>  
>  })
>
> similarly to what I do in the Rmpfr package,
> and where "Mnumber" is a *large* class union... defined in
> Rmpfr/R/AllClasses.R and if you look in there, you see comments
> with FIXME ... basically the solution was +- ok, but not really
> entirely satisfactory to me.
>
> Still, we maybe should really discuss to have the above two
> setGeneric()s in 'methods', and possibly also some class union /
> superclass  definitions there (that other packages could use!) possibly even
> with
> setMethod("cbind", ,
>   function(..., deparse.level=1) {
>   ..
>   })
> and of course the same with rbind().
>
>
> > This came up in the context of complex package
> > dependencies in Bioconductor, as detailed in this thread
> > (sorry for the html).
>
> > https://stat.ethz.ch/pipermail/bioc-devel/2012-September/003617.html
>
> > --
> > Dr. Martin Morgan Fred Hutchinson Cancer Research Center
> > 1100 Fairview Ave. N.  PO Box 19024 Seattle, WA 98109
>
> > __
> > 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



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Behavior or as.environment in function arguments/call (and force() behaviors...)

[Jeff Ryan]

Happy 2013!

Can someone with more knowledge of edge case scoping/eval rules explain
what is happening below?  Happens in all the versions of R I have on hand.

Behavior itself is confusing, but ?as.environment also provides no clue.
 The term used in that doc is 'search list', which is ambiguous, but the
see also section mentions search(), so I would *think* that is what is
intended.  Either way Fn1() below can't really be explained.

Major question is what in the world is Fn1 doing, and why is Fn2 not equal
to Fn3? [ Fn3/Fn4 are doing what I want. ]


Fn1 <- function(x="test",pos=-1,env=as.environment(pos)) {
ls(env)
}

Fn2 <- function(x="test",pos=-1,env=as.environment(pos)) {
force(env)
ls(env)
}

Fn3 <- function(x="test",pos=-1,env=as.environment(pos)) {
# should be the same as force() in Fn2, but not
# ?force
# Note:
#
#This is semantic sugar: just evaluating the symbol will do the
#same thing (see the examples).
env
ls(env)
}

Fn4 <- function(x="test",pos=-1,env=as.environment(pos)) {
# same as Fn3
env <- env
ls(env)
}

Fn1()
Fn2()
Fn3()
Fn4()
ls()

## output #
> Fn1()
[1] "doTryCatch" "expr"   "handler""name"   "parentenv"

> Fn2()
[1] "env" "pos" "x"

> Fn3()
[1] "Fn1" "Fn2" "Fn3" "Fn4"

> Fn4()
[1] "Fn1" "Fn2" "Fn3" "Fn4"

### .GlobalEnv
> ls()
[1] "Fn1" "Fn2" "Fn3" "Fn4"

> R.version
   _
platform   x86_64-apple-darwin11.2.0
arch   x86_64
os darwin11.2.0
system x86_64, darwin11.2.0
status
major  2
minor  15.1
year   2012
month  06
day22
svn rev59600
language   R
version.string R version 2.15.1 (2012-06-22)
nickname   Roasted Marshmallows

> R.version
   _
platform   x86_64-apple-darwin11.2.0
arch   x86_64
os darwin11.2.0
system x86_64, darwin11.2.0
status Under development (unstable)
major  3
minor  0.0
year   2012
month  12
day28
svn rev61464
language   R
version.string R Under development (unstable) (2012-12-28 r61464)
nickname   Unsuffered Consequences

-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Behavior or as.environment in function arguments/call (and force() behaviors...)

[Jeff Ryan]

Thanks Duncan.

I was hoping that pos= would be more useful, but envir is a bit easier to
grasp in terms of consistency.

The lazy eval was also pointed out to me off-list as a source of the
'weirdness' if you will, which makes perfect sense in retrospect.

Thanks for the prompt clarification, and I'm glad I wasn't just
missing/misreading the primary docs.

Best,
Jeff


On Tue, Jan 1, 2013 at 4:21 PM, Duncan Murdoch wrote:

> On 13-01-01 4:35 PM, Jeff Ryan wrote:
>
>> Happy 2013!
>>
>> Can someone with more knowledge of edge case scoping/eval rules explain
>> what is happening below?  Happens in all the versions of R I have on hand.
>>
>
> Even though it is used as a default in a number of places, the pos==-1
> value is really poorly documented.  You need to look in the source, in
> particular src/main/envir.c, function pos2env.  There you'll see that
> pos==-1 is special cased to be the environment from which pos.to.env
> (or as.environment in your case) was called.  For non-negative values, it
> indexes the search list (i.e. the list returned by search().)  Other values
> are errors.
>
> The trouble in your examples is that this location varies.  In Fn1, it is
> being called in the ls() call.  In Fn2, it is in the force() call. In Fn3
> and Fn4, it's the Fn3/Fn4 call.
>
> In spite of what the docs say in ?get, I would rarely if ever use a pos
> argument to as.environment.  Use an environment and pass it as envir.
>
> Duncan Murdoch
>
>
>
>> Behavior itself is confusing, but ?as.environment also provides no clue.
>>   The term used in that doc is 'search list', which is ambiguous, but the
>> see also section mentions search(), so I would *think* that is what is
>> intended.  Either way Fn1() below can't really be explained.
>>
>> Major question is what in the world is Fn1 doing, and why is Fn2 not equal
>> to Fn3? [ Fn3/Fn4 are doing what I want. ]
>>
>>
>> Fn1 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> ls(env)
>> }
>>
>> Fn2 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> force(env)
>> ls(env)
>> }
>>
>> Fn3 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> # should be the same as force() in Fn2, but not
>> # ?force
>> # Note:
>> #
>> #This is semantic sugar: just evaluating the symbol will do the
>> #same thing (see the examples).
>> env
>> ls(env)
>> }
>>
>> Fn4 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> # same as Fn3
>> env <- env
>> ls(env)
>> }
>>
>> Fn1()
>> Fn2()
>> Fn3()
>> Fn4()
>> ls()
>>
>> ## output #
>>
>>> Fn1()
>>>
>> [1] "doTryCatch" "expr"   "handler""name"   "parentenv"
>>
>>  Fn2()
>>>
>> [1] "env" "pos" "x"
>>
>>  Fn3()
>>>
>> [1] "Fn1" "Fn2" "Fn3" "Fn4"
>>
>>  Fn4()
>>>
>> [1] "Fn1" "Fn2" "Fn3" "Fn4"
>>
>> ### .GlobalEnv
>>
>>> ls()
>>>
>> [1] "Fn1" "Fn2" "Fn3" "Fn4"
>>
>>  R.version
>>>
>> _
>> platform   x86_64-apple-darwin11.2.0
>> arch   x86_64
>> os darwin11.2.0
>> system x86_64, darwin11.2.0
>> status
>> major  2
>> minor  15.1
>> year   2012
>> month  06
>> day22
>> svn rev59600
>> language   R
>> version.string R version 2.15.1 (2012-06-22)
>> nickname   Roasted Marshmallows
>>
>>  R.version
>>>
>> _
>> platform   x86_64-apple-darwin11.2.0
>> arch   x86_64
>> os darwin11.2.0
>> system x86_64, darwin11.2.0
>> status Under development (unstable)
>> major  3
>> minor  0.0
>> year   2012
>> month  12
>> day28
>> svn rev61464
>> language   R
>> version.string R Under development (unstable) (2012-12-28 r61464)
>> nickname   Unsuffered Consequences
>>
>>
>


-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] formal vs. passed args: parent.frame() behavior.

[Jeff Ryan]

Happy 2013, Day 2.

I can't seem to figure out why parent.frame() works differently depending
on whether it is a formal/default argument or a passed argument.

# code: basic setup 

tmp <- tempfile()
A <- 101
save(A,file=tmp);rm(A)

# these work as expected, loading into the parent of the call load()
load(tmp);str(A);rm(A)
load(tmp, parent.frame());str(A);rm(A)
load(tmp, environment());str(A);rm(A)



# but these are odd, using local()

# works
local( { load(tmp); str(A) } )

 #FAILS even though env=parent.frame() by default !?!!
local( { load(tmp,env=parent.frame()); str(A) } )

# works as well!
local( { load(tmp,env=environment()); str(A) } )

ls()## NOT in .GlobalEnv, correct!
args(load)  ## env=parent.frame() by default, but is it???


My question is why parent.frame() can't be specified in the args without
changing the behavior of the call itself if you aren't at the top level.

What am I missing?

Jeff


# output #

> tmp <- tempfile()
> A <- 101
> save(A,file=tmp);rm(A)
>
> # these work as expected, loading into the parent of the call load()
> load(tmp);str(A);rm(A)
 num 101
> load(tmp, parent.frame());str(A);rm(A)
 num 101
> load(tmp, environment());str(A);rm(A)
 num 101
>
>
>
> # but these are odd, using local()
>
> # works
> local( { load(tmp); str(A) } )
 num 101
>
>  #fails even though env=parent.frame() by default !?!!
> local( { load(tmp,env=parent.frame()); str(A) } )
Error in str(A) : object 'A' not found
>
> # works as well!
> local( { load(tmp,env=environment()); str(A) } )
 num 101
>
> ls()## NOT in .GlobalEnv, correct!
[1] "tmp"
> args(load)  ## env=parent.frame() by default, but is it???
function (file, envir = parent.frame())
NULL
>

-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Passing R code from webpage

[Jeff Ryan]

Another really great tool, leveraging Simon's incredible work with Rserve,
is to use pyRserve.  Combined with Flask as a web framework you can do
quite a bit with very minimal code.

http://flask.pocoo.org/
http://pypi.python.org/pypi/pyRserve/

HTH
Jeff


On Sun, Feb 17, 2013 at 12:10 PM, Simon Urbanek  wrote:

>
> On Feb 17, 2013, at 12:09 PM, Matevz Pavlic wrote:
>
> > Hi,
> >
> > yes, i saw that about Cshtml...but it's done already, can't change it
> now.
> >
> > Are there any samples of web pages or some samples to download for
> FastRWeb?
> > I am having troubles understanding how to install this and get it to
> work...
> >
>
> There is the INSTALL file in the package with all the details. Sample
> scripts (example*) will be installed as part of the installation process --
> if you want to look at them first, they are in the inst/web.R directory of
> the package sources. An example HTML page with JS to use AJAX is in the
> web/index.html file. Jay Emerson also has a blog entry about installing
> FastRWeb
>
> http://jayemerson.blogspot.com/2011/10/setting-up-fastrwebrserve-on-ubuntu.html
> You can ask questions about FastRWeb or Rserve on the stats-rosuda-devel
> mailing list.
>
> Cheers,
> Simon
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@lemnica.com

www.lemnica.com

R/Finance 2013: Applied R in Finance
May 17, 18 Chicago, IL
www.RinFinance.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] readBin on binary non-blocking connections (Windows & Unix differences/bugs)

[Jeff Ryan]

R-devel:

I am encountering a consistency issue using socketConnection and
readBin with *non-blocking* connections on Unix and Windows XP (no
Vista to test).

I am a bit confused by the behavior of *non-blocking* connections
under Windows specifically.  When calling readBin on a non-blocking
connection when there is no data to read on the socket, the connection
under Unix will return a vector of zero-length matching the type of
the 'what' argument to the readBin call.

The same call under Windows returns random data unless called with
what=raw(), which instead returns an error.


A simple example using two R processes to illustrate on one machine:


#
# PROCESS 1 (Windows/Unix -- the same code for both):
#

# Open the connection and don't write anything

s <- socketConnection(port=, server=TRUE, blocking=TRUE,open="ab")

#
# PROCESS 2 (Windows) use this to read:
#

s <- socketConnection(port=,blocking=FALSE,open="ab")
readBin(s, character())
readBin(s, character())
readBin(s, double())
readBin(s, raw())

# > readBin(s, character())
# [1] "\020âƒ\...@ûƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001
$ƒ\001 $ƒ\001 ...
# > readBin(s, character())
# [1] "X\n"
# > readBin(s, double())
# [1] 1.255609e-316
# > readBin(s, raw())
# Error in readBin(s, raw()) : negative length vectors are not allowed

##
# Using a *nix, the above works as I would expect
#
# PROCESS 2 (Unixes -- this example OSX 10.4, but is consistent on
other flavors)
#

s <- socketConnection(port=,blocking=FALSE, open="ab")
readBin(s, character())
readBin(s, raw())
readBin(s, double())

# > readBin(s, character())
# character(0)
# > readBin(s, raw())
# raw(0)
# > readBin(s, double())
# numeric(0)

Is this a bug in R or Windows?  Is there a workaround?  I would like
to have readBin on non-blocking connections work consistently across
platforms.  When data is present, both platforms behave consistently.
Incidentally, the readBin calls in my program are not using R as the
server, the above code is simply to illustrate the problem.

The fact that the raw() returns an error on Windows seems to indicate
that the error is able to be caught, and could be tested for.

One other interesting point of note; the character() calls on Windows
will return not just random data, but very non-random R type strings.
Somehow non-allocated memory is being read.

> readBin(s, character(),100)
  [1] "X\n"
  [2] "spatch"
  [3] ""
  [4] ""
  [5] "X\n"
  [6] "ssion"
  [7] "\002"
  [8] " $ƒ\001À|Ó\001\030[Ó\001°N¡\001°N¡\001 $ƒ\001\004"
  [9] "H\024¢\001\f\025¢\001,œŒ\001\002\002"
 [10] "è\026¢\001 $ƒ\001\005"
 [11] ""
 [12] "s.logical"
...
 [75] "8}ò\001À~ò\001\020—ò\001 $ƒ\001Œ}ò\001 $ƒ\001ô–ò\001
$ƒ\001¼–ò\001ˆ~ò\0014~ò\001Ø–ò\001È|ò\001€—ò\001¸—ò\001\034}ò\001œ—ò\001
$ƒ\001¬|ò\001 \177ò\001"
 [76] " $ƒ\001 $ƒ\001ˆ•ò\001\030•ò\001T”ò\001 $ƒ\001 $ƒ\001
$ƒ\001¬“ò\0010–ò\001 $ƒ\001 $ƒ\001¼–ò\0014•ò\001
\177ò\001X“ò\001\034”ò\001 $ƒ\001Œ”ò\001Ì’ò\001
|ò\001\004“ò\001ä“ò\0010\177ò\001ø•ò\001è{ò\001<“ò\001
$ƒ\001Ü•ò\001à}ò\001 “ò\001 $ƒ\001 $ƒ\001\024\177ò\001
$ƒ\001t“ò\001¨”ò\001ü}ò\001 $ƒ\001 $ƒ\001t|ò\001 $ƒ\001
$ƒ\001ô\177ò\001œ—ò\001ä|ò\001 |ò\001 $ƒ\001d—ò\001
$ƒ\001è’ò\001x{ò\001 $ƒ\001"
 [77] "' must be of length 1"

This behavior has been noticed by me at least as early as 2.6, and is
currently seen under 2.9.0.

Thanks for any pointers,
Jeff Ryan


-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] readBin on binary non-blocking connections (Windows & Unix differences/bugs)

[Jeff Ryan]

Thanks Gabor.

Unfortunately read/writeLines won't work in this particular
application.  Nor does readChar, as the returned values are not of a
fixed size.  I need to read each unknown length "character" up until
an embedded null.  readBin does this (almost) perfectly.

My current workaround is to simply force blocking=TRUE on Windows
users, but that seems not to be the right answer.

An alternate approach may be to rewrite readBin to allow for some sort
of buffering mechanism.  If readBin first reads in data as raw(), it
would be possible to test for an error and return via some switch
statement the appropriate length zero vector.

The main issue is that by reading in raw bytes I have to explicitly
convert to the appropriate data types (nul terminated character
strings in this case).

The second (bigger?) issue is that all readBin calls would have to
first look to the buffer before reading from the connection again.
This would require the buffer to be available --- either as an R
connection addition, or as a global variable.

The best option of course is for readBin to correctly catch the error
cases, but without guidance from those who know the full details of
sockets in R, I am afraid that option isn't realistic at this moment.

Jeff





On Mon, May 18, 2009 at 1:01 PM, Gabor Grothendieck
 wrote:
> Ryacas uses non-blocking sockets and works across all platforms
> but uses readLines/writeLines, rather than readBin, to communicate with
> yacas.  You could look at its source code in case it brings anything to mind.
>
> On Mon, May 18, 2009 at 1:40 PM, Jeff Ryan  wrote:
>> R-devel:
>>
>> I am encountering a consistency issue using socketConnection and
>> readBin with *non-blocking* connections on Unix and Windows XP (no
>> Vista to test).
>>
>> I am a bit confused by the behavior of *non-blocking* connections
>> under Windows specifically.  When calling readBin on a non-blocking
>> connection when there is no data to read on the socket, the connection
>> under Unix will return a vector of zero-length matching the type of
>> the 'what' argument to the readBin call.
>>
>> The same call under Windows returns random data unless called with
>> what=raw(), which instead returns an error.
>>
>>
>> A simple example using two R processes to illustrate on one machine:
>>
>>
>> #
>> # PROCESS 1 (Windows/Unix -- the same code for both):
>> #
>>
>> # Open the connection and don't write anything
>>
>> s <- socketConnection(port=, server=TRUE, blocking=TRUE,open="ab")
>>
>> #
>> # PROCESS 2 (Windows) use this to read:
>> #
>>
>> s <- socketConnection(port=,blocking=FALSE,open="ab")
>> readBin(s, character())
>> readBin(s, character())
>> readBin(s, double())
>> readBin(s, raw())
>>
>> # > readBin(s, character())
>> # [1] "\020âƒ\...@ûƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001
>> $ƒ\001 $ƒ\001 ...
>> # > readBin(s, character())
>> # [1] "X\n"
>> # > readBin(s, double())
>> # [1] 1.255609e-316
>> # > readBin(s, raw())
>> # Error in readBin(s, raw()) : negative length vectors are not allowed
>>
>> ##
>> # Using a *nix, the above works as I would expect
>> #
>> # PROCESS 2 (Unixes -- this example OSX 10.4, but is consistent on
>> other flavors)
>> #
>>
>> s <- socketConnection(port=,blocking=FALSE, open="ab")
>> readBin(s, character())
>> readBin(s, raw())
>> readBin(s, double())
>>
>> # > readBin(s, character())
>> # character(0)
>> # > readBin(s, raw())
>> # raw(0)
>> # > readBin(s, double())
>> # numeric(0)
>>
>> Is this a bug in R or Windows?  Is there a workaround?  I would like
>> to have readBin on non-blocking connections work consistently across
>> platforms.  When data is present, both platforms behave consistently.
>> Incidentally, the readBin calls in my program are not using R as the
>> server, the above code is simply to illustrate the problem.
>>
>> The fact that the raw() returns an error on Windows seems to indicate
>> that the error is able to be caught, and could be tested for.
>>
>> One other i

Re: [Rd] readBin on binary non-blocking connections (Windows & Unix differences/bugs)

[Jeff Ryan]

R-devel:

I'll escalate this to a bug report once I can fully document, but
something is seriously wrong with readBin on non-blocking connections.

>From ?readBin

Value:

 For 'readBin', a vector of appropriate mode and length the number
 of items read (which might be less than 'n').

On Windows, 'n' elements are always returned.  If 'n' < items waiting
to be read, then the vector of length 'n' will be returned with the
expected items.

If n > items, a vector of length n (yes, n) will be returned, padded
with random values taken from (somewhere???) in memory.

As expressed in a previous email, if what=raw() and n > items, the
entire process fails with an error.  The items are effectively read
and discarded.

I would be interested in assisting further with a patch, but I would
hope that someone (R-core or otherwise) who knows a bit more about the
internals of socket connections in R (w.r.t Windows - as *nix works
fine) could provide some much needed insight.

Best,
Jeff Ryan

On Mon, May 18, 2009 at 12:40 PM, Jeff Ryan  wrote:
> R-devel:
>
> I am encountering a consistency issue using socketConnection and
> readBin with *non-blocking* connections on Unix and Windows XP (no
> Vista to test).
>
> I am a bit confused by the behavior of *non-blocking* connections
> under Windows specifically.  When calling readBin on a non-blocking
> connection when there is no data to read on the socket, the connection
> under Unix will return a vector of zero-length matching the type of
> the 'what' argument to the readBin call.
>
> The same call under Windows returns random data unless called with
> what=raw(), which instead returns an error.
>
>
> A simple example using two R processes to illustrate on one machine:
>
>
> #
> # PROCESS 1 (Windows/Unix -- the same code for both):
> #
>
> # Open the connection and don't write anything
>
> s <- socketConnection(port=, server=TRUE, blocking=TRUE,open="ab")
>
> #
> # PROCESS 2 (Windows) use this to read:
> #
>
> s <- socketConnection(port=,blocking=FALSE,open="ab")
> readBin(s, character())
> readBin(s, character())
> readBin(s, double())
> readBin(s, raw())
>
> # > readBin(s, character())
> # [1] "\020âƒ\...@ûƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001
> $ƒ\001 $ƒ\001 ...
> # > readBin(s, character())
> # [1] "X\n"
> # > readBin(s, double())
> # [1] 1.255609e-316
> # > readBin(s, raw())
> # Error in readBin(s, raw()) : negative length vectors are not allowed
>
> ##
> # Using a *nix, the above works as I would expect
> #
> # PROCESS 2 (Unixes -- this example OSX 10.4, but is consistent on
> other flavors)
> #
>
> s <- socketConnection(port=,blocking=FALSE, open="ab")
> readBin(s, character())
> readBin(s, raw())
> readBin(s, double())
>
> # > readBin(s, character())
> # character(0)
> # > readBin(s, raw())
> # raw(0)
> # > readBin(s, double())
> # numeric(0)
>
> Is this a bug in R or Windows?  Is there a workaround?  I would like
> to have readBin on non-blocking connections work consistently across
> platforms.  When data is present, both platforms behave consistently.
> Incidentally, the readBin calls in my program are not using R as the
> server, the above code is simply to illustrate the problem.
>
> The fact that the raw() returns an error on Windows seems to indicate
> that the error is able to be caught, and could be tested for.
>
> One other interesting point of note; the character() calls on Windows
> will return not just random data, but very non-random R type strings.
> Somehow non-allocated memory is being read.
>
>> readBin(s, character(),100)
>  [1] "X\n"
>  [2] "spatch"
>  [3] ""
>  [4] ""
>  [5] "X\n"
>  [6] "ssion"
>  [7] "\002"
>  [8] " $ƒ\001À|Ó\001\030[Ó\001°N¡\001°N¡\001 $ƒ\001\004"
>  [9] "H\024¢\001\f\025¢\001,œŒ\001\002\002"
>  [10] "è\026¢\001 $ƒ\001\005"
>  [11] ""
>  [12] "s.logical"
> ...
>  [75] "8}ò\001À~ò\001\020—ò\001 $ƒ\001Œ}ò\001 $ƒ\001ô–ò\001
> $ƒ\001¼–ò\001ˆ~ò\0014~ò\001Ø–ò\001È|ò\001€—ò\001¸—ò\001\034}ò\001œ—ò\001
> $ƒ\001

Re: [Rd] How to create a permanent dataset in R.

[Jeff Ryan]

The biggest help would come by not pretending to be Albert Einstein.

hTh,
Jeff

On Fri, Jul 24, 2009 at 1:11 AM, Albert EINstEIN wrote:
>
>
> Hi everybody,
>
> Actually, we know that If we create a dataset in R ,after closing the
> session the dataset automatically is closed. I tried for creating dataset
> permanently in R.I am facing the problem of creating permanent dataset.
> can we create dataset permanently If possible?
> Could somebody help me out in this aspect,plz? Any help would be
> appreciated.
>
> Thanks in advance.
> --
> View this message in context: 
> http://www.nabble.com/How-to-create-a-permanent-dataset-in-R.-tp24639146p24639146.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> 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] inheriting C symbols

[Jeff Ryan]

This has been discussed before:

http://www.nabble.com/Dynamic-linking-to-binary-code-from-other-packages---td20167535.html#a20474561

Take a look at 'xts' on cran, or R-forge.  Specifically:

http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/inst/api_example/README?rev=386&root=xts&view=markup

HTH
Jeff

On Wed, Aug 5, 2009 at 11:29 AM, Terry Therneau wrote:
> The package coxme depends heavily on bdsmatrix, to the point of needing
> access to some of its C calls.  The kinship package (in progress) uses
> the R level functions in bdsmatrix, but not the C calls.  That is, I
> don't want to always export the symbols.
>
> For testing I can use an explicit dyn.load('somepath/bsdmatrix.so',
> local=F).  How do I incorporate such a dependency in the DESCRIPTION
> file for coxme, so that it happens in general?
>
> Terry T.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] inheriting C symbols

[Jeff Ryan]

Terry,

I think I don't quite follow what you want to do.

You have a package that needs to access the R level functions in
another, or the C level functions?

Do you need access *from R* for the above, or *from new C code*?

If you are just looking to call .Call("other_package", ...) I think
your only strategy is to list it as a dependency.  Is there some
reason you don't want to do that?

Once it is a dependency you can simply call the C routines like they
are called within the package's R code.

Jeff

On Wed, Aug 5, 2009 at 2:24 PM, Terry Therneau wrote:
> Thanks for the information.  I'd looked through the manual but missed
> this.  Follow-up questions
>
> 1. I'd never paid much attention to that whole "register routines"
> section of the manual because a) it didn't seem necessary (my code
> worked anyway) and b) it's quite complex.  Your answer is that if I dig
> into it, there is a way to export routines.  Is there any other real
> advantage to registration?
>
> 2. The simpler method is to use a local=FALSE argument to dyn.load.
> Since it wasn't mentioned, I'll assume that there is no way to add text
> to the DESCRIPTION file saying "and load the symbols too"?  It would be
> much simpler.  Also a bit more dangerous of course, since function
> prototypes are not being exported via a header.
>
>  Terry T
>
>
> On Wed, 2009-08-05 at 11:54 -0500, Jeff Ryan wrote:
>> This has been discussed before:
>>
>> http://www.nabble.com/Dynamic-linking-to-binary-code-from-other-packages---td20167535.html#a20474561
>>
>> Take a look at 'xts' on cran, or R-forge.  Specifically:
>>
>> http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/inst/api_example/README?rev=386&root=xts&view=markup
>>
>> HTH
>> Jeff
>>
>> On Wed, Aug 5, 2009 at 11:29 AM, Terry Therneau wrote:
>> > The package coxme depends heavily on bdsmatrix, to the point of needing
>> > access to some of its C calls.  The kinship package (in progress) uses
>> > the R level functions in bdsmatrix, but not the C calls.  That is, I
>> > don't want to always export the symbols.
>> >
>> > For testing I can use an explicit dyn.load('somepath/bsdmatrix.so',
>> > local=F).  How do I incorporate such a dependency in the DESCRIPTION
>> > file for coxme, so that it happens in general?
>> >
>> > Terry T.
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>>
>
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)

[Jeff Ryan]

Adam,

It seems that your attachment didn't make it through.

That aside, my experience with strange errors like those (random type
not implemented ones) has been that you may be looking at a memory
problem on you machine. Given that you can't replicate on another
platform (and the .csv file didn't come through), I would think it
wise to start there.

My 2c.  And I love bacon too :)

Jeff

On Fri, Aug 7, 2009 at 1:10 PM,  wrote:
>  This message is in MIME format.  The first part should be readable text,
>  while the remaining parts are likely unreadable without MIME-aware tools.
>
> --1660387551-1458482416-1249639718=:2997
> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
> Content-ID: 
>
> Hello,
>
>        There appears to be a bug in the nlm function, which I discovered
> when trying to run an SEM.  The SEM is not bizarre; the covariance matrix is
> solve-able and the eigenvalues are greater than zero, and I do not believe
> the "sem" package per se to be the problem (as nlm keeps being the part that
> fails, though I can't replicate this with other nlm tasks).  I apologize if
> I have put too many much information in this message; I'm not a programmer
> by trade so I don't really know what's going on here, which hampers my
> ability to write consise bug reports.
>
> Here is the code I use:
>
> library(sem)
> ice.S <- read.csv("iceS.csv") # attached
> rownames(ice.S) <- ice.S[,1]
> ice.S[,1] <- NULL
> ice.S <- as.matrix(ice.S)
> ice.ram <- specify.model("ice.ram") # attached
> ice.N <- 342
> ice.sem <- sem(ram=ice.ram, S=ice.S, N=ice.N)
>
> ...at this point, any number of problems could occur. I have seen the
> following.
>
> 1) Simple lack of convergence. (might be my model's fault.)
> 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
> :
>   type 31 is unimplemented in 'type2char'
> 3)  *** caught segfault ***
> address 0xc019c87b, cause 'memory not mapped'
>
> Traceback:
>  1: nlm(if (analytic.gradient) objective.2 else objective.1, start,
> hessian = TRUE, iterlim = maxiter, print.level = if (debug) 2 else 0,
> typsize = typsize, ...)
>  2: sem.default(ram = ram, S = S, N = N, param.names = pars, var.names =
> vars,     fixed.x = fixed.x, debug = debug, ...)
>  3: sem(ram = ram, S = S, N = N, param.names = pars, var.names = vars,
> fixed.x = fixed.x, debug = debug, ...)
>  4: sem.mod(ram = ice.ram, S = ice.S, N = ice.N)
>  5: sem(ram = ice.ram, S = ice.S, N = ice.N)
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection: 1
> aborting ...
> Segmentation fault
> swiss:data$
>
> (no core was dumped).
>
> Trying with debug mode provides other interesting errors:
>
>> ice.sem <- sem(ram=ice.ram, S=ice.S, N=ice.N, debug=TRUE)
>
> ...gets up to some iteration (not always 15), and then R dies ungracefully,
> and exits to the shell:
>
> iteration = 15
> Step:
>  [1]  1.253132e-02  1.183343e-02 -7.651342e-03 -2.490800e-03  2.278938e-03
>  [6]  3.197431e-04  6.137849e-04 -2.496882e-03 -1.065829e-03 -2.118179e-03
> [11]  2.942936e-03 -1.335936e-03 -3.665618e-03  3.090566e-03  8.534956e-04
> [16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-04
> [21]  7.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03  2.216899e-03
> [26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-04
> Parameter:
>  [1] -0.76604614 -1.19639662  0.83456888  0.72540413  0.08482452  0.56180393
>  [7]  0.50615814  0.55728015  0.83796696  0.88371335 -0.70465116  0.85251098
> [13] -0.18346956  0.66857787  0.57012481  0.39116561  0.91237990  0.63951482
> [19]  0.26601566  0.29240836  0.44710919  0.94734056  6.52039015  0.02524762
> [25] -0.01614603  2.88198219  0.03442452  3.52272237  1.44698423 -0.72964745
> Function Value
> [1] -15175.94
> Gradient:
>  [1] -2.085412e+07 -3.819717e+07  3.883989e+07  1.352594e+00 -4.283329e+00
>  [6] -1.437250e+00 -6.558913e-01  1.358276e+00  7.930865e+05 -1.293853e+06
> [11] -5.816627e+03  5.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e+07
> [16] -4.143068e+07 -6.159782e-01  1.044274e-01 -8.591048e+00 -2.083471e+00
> [21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+07
> [26] -7.106654e+02 -7.335293e+06 -7.335285e+05  3.117764e-01 -2.234989e+04
>
> Abort trap
> swiss:data$
>
> ...I have also seen convergence reached, and nlm then die with this message:
>
> Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
> :
>   type 27 is unimplemented in 'type2char'
>
> (similar to above, but now referring to type 27)
>
> I have shown this effect (or something similar...never know how it'll fail
> next) on the following platforms:
>
>> version
>                _
> platform       i386-apple-darwin9.7.0
> arch           i386
> os             darwin9.7.0
> system         i386, darwin9.7.0
> status
> major          2
> minor          9.1
> year           2009
> month          06
> day            26
> 

Re: [Rd] Why is strptime always returning a vector of length 9 ?

[Jeff Ryan]

The reason is in the ?strptime under value:

'strptime' turns character representations into an object of class
 '"POSIXlt"'.  The timezone is used to set the 'isdst' component
 and to set the '"tzone"' attribute if 'tz != ""'.

And POSIXlt is a list of length 9.


HTH
Jeff

On Sun, Aug 9, 2009 at 10:35 AM, Gabor
Grothendieck wrote:
> Try this to see its components:
>
>> str(unclass(xd))
> List of 9
>  $ sec  : num [1:6] 0 0 0 0 0 0
>  $ min  : int [1:6] 0 0 0 0 0 0
>  $ hour : int [1:6] 0 0 0 0 0 0
>  $ mday : int [1:6] 9 31 12 12 30 30
>  $ mon  : int [1:6] 2 4 10 10 6 6
>  $ year : int [1:6] 107 107 108 108 109 109
>  $ wday : int [1:6] 5 4 3 3 4 4
>  $ yday : int [1:6] 67 150 316 316 210 210
>  $ isdst: int [1:6] 0 1 0 0 1 1
>
> and read R News 4/1 for more.
>
> On Sun, Aug 9, 2009 at 10:20 AM, laurent wrote:
>> Dear List,
>>
>>
>> I am having an issue with strptime (see below).
>> I can reproduce it on R-2.8, R-2.9, and R-2.10-dev, I tempted to see
>> either a bug or my misunderstanding (and then I just don't currently see
>> where).
>>
>> # setup:
>> x <- c("March 09, 2007", "May 31, 2007", "November 12, 2008", "November
>> 12, 2008", "July 30, 2009", "July 30, 2009" )
>>
>> # showing the problem
>>> length(x)
>> 6
>>> xd <- strptime(x, format = "%B %d, %Y")
>>> length(xd)
>> 9
>>> xd[1:9]
>> [1] "2007-03-09" "2007-05-31" "2008-11-12" "2008-11-12" "2009-07-30"
>> [6] "2009-07-30" NA           NA           NA
>>> length(strptime(rep(x, 2), format="%B %d, %Y"))
>> [1] 9
>>> strptime(rep(x, 2), format="%B %d, %Y")[1:12]
>>  [1] "2007-03-09" "2007-05-31" "2008-11-12" "2008-11-12" "2009-07-30"
>>  [6] "2009-07-30" "2007-03-09" "2007-05-31" "2008-11-12" "2008-11-12"
>> [11] "2009-07-30" "2009-07-30
>>
>> Any pointer would be appreciated.
>>
>>
>>
>> L.
>>
>> __
>> 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
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] CRAN Server download statistics (Was: R Usage Statistics)

[Jeff Ryan]

While I think download statistics are potentially interesting for
developers, done incorrectly it can very likely damage the community.
A basic data reporting problem, with all of the caveats attached.

This information has also been readily available from the main CRAN
mirror for years:

http://www.r-project.org/awstats/awstats.cran.r-project.org.html
http://cran.r-project.org/report_cran.html

Best,
Jeff

On Sun, Nov 22, 2009 at 6:18 PM, Fellows, Ian  wrote:
> Hi All,
>
> It seems that the question of how may people use (or download) R, and it's 
> packages is one that comes up on a fairly regular basis in a variety of 
> forums (There was also recent thread on the subject on Stack Overflow). A 
> couple of students at UCLA (including myself), wanted to address the issue, 
> so we set up a system to get and parse the cran.stat.ucla.edu APACHE logs 
> every night, and display some basic statistics. Right now, we have a working 
> sketch of a site based on one week of observations.
>
> http://neolab.stat.ucla.edu/cranstats/
>
> We would very much like to incorporate data from all CRAN mirrors, including 
> cran.r-project.org. We would also like to set this up in a way that is 
> minimally invasive for the site administrators. Internally, our administrator 
> has set up a protected directory with the last couple days of cran activity. 
> We then pull that down using curl.
>
> What would be the best and easiest way for the CRAN mirrors to share their 
> data? Is the contact information for the administrators available anywhere?
>
>
> Thank you,
> Ian Fellows
>
>
>
> 
> From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf 
> Of Steven McKinney [smckin...@bccrc.ca]
> Sent: Thursday, November 19, 2009 2:21 PM
> To: Kevin R. Coombes; r-devel@r-project.org
> Subject: Re: [Rd] R Usage Statistics
>
> Hi Kevin,
>
> What a surprising comment from a reviewer for BMC Bioinformatics.
>
> I just did a PubMed search for "limma" and "aroma.affymetrix",
> just two methods for which I use R software regularly.
> "limma" yields 28 hits, several of which are published
> in BMC Bioinformatics.  Bengtsson's aroma.affymetrix paper
> "Estimation and assessment of raw copy numbers at the single locus level."
> is already cited by 6 others.
>
> It almost seems too easy to work up lists of usage of R packages.
>
> Spotfire is an application built around S-Plus that has widespread use
> in the biopharmaceutical industry at a minimum.  Vivek Ranadive's
> TIBCO company just purchased Insightful, the S-Plus company.
> (They bought Spotfire previously.)
> Mr. Ranadive does not spend money on environments that are
> not appropriate for deploying applications.
>
> You could easily cull a list of corporation names from the
> various R email listservs as well.
>
> Press back with the reviewer.  Reviewers can learn new things
> and will respond to arguments with good evidence behind them.
> Good luck!
>
>
> Steven McKinney
>
>
> 
> From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf 
> Of Kevin R. Coombes [krcoom...@mdacc.tmc.edu]
> Sent: November 19, 2009 10:47 AM
> To: r-devel@r-project.org
> Subject: [Rd] R Usage Statistics
>
> Hi,
>
> I got the following comment from the reviewer of a paper (describing an
> algorithm implemented in R) that I submitted to BMC Bioinformatics:
>
> "Finally, which useful for exploratory work and some prototyping,
> neither R nor S-Plus are appropriate environments for deploying user
> applications that would receive much use."
>
> I can certainly respond by pointing out that CRAN contains more than
> 2000 packages and Bioconductor contains more than 350. However, does
> anyone have statistics on how often R (and possibly some R packages) are
> downloaded, or on how many people actually use R?
>
> Thanks,
>    Kevin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rcpp: Clarifying the meaning of GPL?

[Jeff Ryan]

This is fantastically off-topic, and has nothing to do with *R*.

Out of "courtesy" to this list, the subscribers, and future readers,
please take this off-list where it belongs.

Jeff

On Tue, Dec 22, 2009 at 11:27 PM, Dominick Samperi
 wrote:
> Stavros Macrakis wrote:
>>
>> That said, as a matter of courtesy and clarity, I'd think that a fork
>> should use a different name.
>
> Yes, the point is that this is not a legal or technical matter, it is a
> matter of professional courtesy.
>
> I take this as one vote for the name change.
>
> On US copyright law, this should not be confused with "copyright" notices
> that appear in GPL
> source code. Remember that these are really "copyleft" notices, and copyleft
> is designed to
> protect the rights of copiers, not original contributors. My concern about
> the copyright notice
> should be viewed in the same spirit as the name change (professional
> courtesy).
>
> Since GPL is largely silent on these issues I have asked the R community to
> vote...
>
> Thanks,
> Dominick
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rcpp: Clarifying the meaning of GPL?

[Jeff Ryan]

One critical aspect to this is the fact that RcppTemplate seems to
have been where the Rcpp work moved to _before_ abandoning the Rcpp
project.

http://cran.r-project.org/src/contrib/Archive/RcppTemplate/

So the 'namespace' of Rcpp was left with seemingly no public intention
of picking it up.

One of the strengths of GPL is that a package can live on when the
original author has chosen to go a different route.  Rcpp was
maintained by another person (with backward compatibility I think) to
likely not break his (and other's) code.

I don't think it is in the best interest of the community to break
existing code, just because one would like to have complete control
over the end product.

Plus, everyone benefits from competition.  And we have a good one here.

My 2c ;-)

Jeff





On Wed, Dec 23, 2009 at 3:21 PM, Henrik Bengtsson  
wrote:
> I guess one problem is who is in charge of the name Rcpp on CRAN.  For
> instance, can I "fork" of yet another version of Rcpp (or any other
> CRAN package) and submit it to CRAN?  Can the original author submit a
> completely different Rcpp package breaking all the additions made by
> the new contributors?  I don't think the GPL answers those questions,
> but maybe there is something on the ownership to the (original)
> "title/label/name/identifier" of a GPL artifact.
>
> My $.02
>
> /Henrik
>
> On Wed, Dec 23, 2009 at 1:00 PM, Stavros Macrakis  
> wrote:
>> The central purpose of the GPL license is precisely to allow and indeed
>> encourage the behavior your are criticizing.  In particular, when you
>> release software under the GPL, you are *explicitly* giving recipients of
>> the software the right to modify it pretty much in any way (trivial or
>> radical) they please and redistribute it by any means they choose (as long
>> as they redistribute source with binary and maintain the legal notices).
>> There is no legal or ethical obligation to consult the original author in
>> any way, or even to acknowledge the original author other than by
>> maintaining his or her copyright notice.  The only legal obligation is to
>> maintain the copyright notice and the GPL license itself and to include a
>> notice that the software has been modified (GPL3 section 5a).
>>
>> This is not an accident.  The promulgators of the GPL, the FSF, believe that
>> these are the conditions under which software is best distributed -- that
>> implementors should be free to combine bits and pieces of software from a
>> variety of GPL-compatible licenses with no fear of violating any of their
>> licenses.
>>
>> Obviously these legal and ethical conditions are quite different from those
>> which prevail in academic publishing, and if you don't like them, you should
>> be releasing your software under a different license -- which will probably
>> have the effect of making your software less useful to the community and
>> therefore less widely known and used.
>>
>>               -s
>>
>>
>> On Wed, Dec 23, 2009 at 11:05 AM, Dominick Samperi
>> wrote:
>>
>>> In my view what has happened is not much different from a situation where I
>>> place my
>>> name as co-author on a research paper that you have created, without your
>>> permission,
>>> after making a few small edits that you may not agree with. Furthermore, if
>>> you complain
>>> I simply present the results (at conferences) as my own without mentioning
>>> your name.
>>>
>>> Is this just a dispute between implementers?
>>>
>>> Stavros Macrakis wrote:
>>>
>>>  On Wed, Dec 23, 2009 at 12:27 AM, Dominick Samperi <
 djsamp...@earthlink.net > wrote:

    Stavros Macrakis wrote:

        That said, as a matter of courtesy and clarity, I'd think that
        a fork should use a different name.

    Yes, the point is that this is not a legal or technical matter, it
    is a matter of professional courtesy.

    I take this as one vote for the name change.


 The naming and maintenance history of this package (or these packages:
 Rcpp and RcppTemplate) appears to be complicated, and I have no interest in
 becoming an arbitrator or voter in what is a dispute between you and other
 implementers.

    On US copyright law, this should not be confused with "copyright"
    notices that appear in GPL
    source code. Remember that these are really "copyleft" notices,
    and copyleft is designed to
    protect the rights of copiers, not original contributors.


 The copyright notice is a correct and legally valid copyright notice.  The
 GPL (copyleft) is the copyright *license*.  Like all licenses, it defines
 the relationship between authors and copiers.  The GPL explicitly avoided
 the so-called "obnoxious BSD advertising clause", which has requirements
 about giving credit.

              -s


>>>
>>
>>        [[alternative HTML version deleted]]
>>
>> _

Re: [Rd] optional package dependency

[Jeff Ryan]

Hi Ross,

The quantmod package makes available routines from a variety of
contributed packages, but gets around your issues with a bit of, um,
trickery.

Take a look here (unless your name is Kurt ;-) ):

http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367&root=quantmod&view=markup

It would be nice to have Suggests really mean suggests to check, but I
am sure there is a good reason it doesn't.

HTH
Jeff

On Fri, Jan 15, 2010 at 12:00 AM, Ross Boylan  wrote:
> I have a package that can use rmpi, but works fine without it.  None of
> the automatic test code invokes rmpi functionality.  (One test file
> illustrates how to use it, but has quit() as its first command.)
>
> What's the best way to handle this?  In particular, what is the
> appropriate form for upload to CRAN?
>
> When I omitted rmpi from the DESCRITPION file R CMD check gave
> 
> * checking R code for possible problems ... NOTE
> alldone: no visible global function definition for ‘mpi.bcast.Robj’
> alldone: no visible global function definition for ‘mpi.exit’
> 
> followed by many more warnings.
>
> When I add
> Suggests: Rmpi
> in DESCRIPTION the check stops if the package is not installed:
> 
> * checking package dependencies ... ERROR
> Packages required but not available:
>  Rmpi
> 
> Rmpi is not required, but I gather from previous discussion on this list
> that suggests basically means required for R CMD check.
>
> NAMESPACE seems to raise similar issues; I don't see any mechanism for
> optional imports.  Also, I have not used namespaces, and am not eager to
> destabilize things so close to release.  At least, I hope I'm close to
> release :)
>
> Thanks for any advice.
>
> Ross Boylan
>
> P.S. Thanks, Duncan, for your recent advice on my help format problem
> with R 2.7.  I removed the nested \description, and now things look OK.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] gc() reports bytes (MB) but uses notation for bits (Mb)

[Jeff Ryan]

I am not a standards expert, but the notation here seems incorrect to me:

> gc()
  used (Mb) gc trigger  (Mb) max used  (Mb)
Ncells  138668  7.5 650970  34.8   492193  26.3
Vcells 6668566 50.9   18582019 141.8 17001419 129.8

In the IEEE 1541-2002 document (
http://en.wikipedia.org/wiki/IEEE_1541-2002) the recommended notation
for bytes is a capital B, whereas bits is either
a lower case "b", (or "bits" per IEC 60027-2)

Both documents, while possibly in disagreement as to the prefix (e.g. M vs.
Mi) agree that B is for bytes.

gc's output is commonly considered confusing, or at least not overly obvious
to many, but the notational confusion surely can't help.

Additional link:
http://physics.nist.gov/cuu/Units/binary.html

Thanks,
Jeff

-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ranges and contiguity checking

[Jeff Ryan]

Providing the wrapper would allow for both performance as well as
user-simplicity.

x[RANGE(1,1e6)] and x[1:1e6] could both be handled internally, where:

RANGE <- function(from,to) {
  structure(seq(from,to), class="RANGE")
}

Just testing for a 'RANGE' object in your [. method would let the
optimization be up to the end user.

The 'xts' package provides something similar with respect to subsetting by
time.  We accept a character string conforming to ISO8601 style time ranges,
as well as standard classes that would be available to subset any other
matrix-like object.

The ISO way will get you fast binary searching over the time-index, whereas
using POSIX time is a linear search.

HTH
Jeff

On Wed, May 12, 2010 at 3:27 PM, James Bullard wrote:

> >> -Original Message-
> >> From: r-devel-boun...@r-project.org
> >> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
> >> Sent: Wednesday, May 12, 2010 11:35 AM
> >> To: bull...@stat.berkeley.edu
> >> Cc: r-de...@stat.math.ethz.ch
> >> Subject: Re: [Rd] ranges and contiguity checking
> >>
> >> On 12/05/2010 2:18 PM, James Bullard wrote:
> >> > Hi All,
> >> >
> >> > I am interfacing to some C libraries (hdf5) and I have
> >> methods defined for
> >> > '[', these methods do hyperslab selection, however, currently I am
> >> > limiting slab selection to contiguous blocks, i.e., things
> >> defined like:
> >> > i:(i+k). I don't do any contiguity checking at this point,
> >> I just grab the
> >> > max and min of the range and them potentially do an
> >> in-memory subselection
> >> > which is what I am definitely trying to avoid. Besides
> >> using deparse, I
> >> > can't see anyway to figure out that these things (i:(i+k)
> >> and c(i, i+1,
> >> > ..., i+k)) are different.
> >> >
> >> > I have always liked how 1:10 was a valid expression in R
> >> (as opposed to
> >> > python where it is not by itself.), however I'd somehow
> >> like to know that
> >> > the thing was contiguous range without examining the un-evaluated
> >> > expression or worse, all(diff(i:(i+k)) == 1)
> >
> > You could define a sequence class, say 'hfcSeq'
> > and insist that the indices given to [.hfc are
> > hfcSeq objects.  E.g., instead of
> > hcf[i:(i+k)]
> > the user would use
> > hcf[hfcSeq(i,i+k)]
> > or
> > index <- hcfSeq(i,i+k)
> > hcf[index]
> > max, min, and range methods for hcfSeq
> > would just inspect one or both of its
> > elements.
>
> I could do this, but I wanted it to not matter to the user whether or not
> they were dealing with a HDF5Dataset or a plain-old matrix.
>
> It seems like I cannot define methods on: ':'. If I could do that then I
> could implement an immutable 'range' class which would be good, but then
> I'd have to also implement: '['(matrix, range) -- which would be easy, but
> still more work than I wanted to do.
>
> I guess I was thinking that there is some inherent value in an immutable
> native range type which is constant in time and memory for construction.
> Then I could define methods on '['(matrix, range) and '['(matrix,
> integer). I'm pretty confident this is more less what is happening in the
> IRanges package in Bioconductor, but (maybe for the lack of support for
> setting methods on ':') it is happening in a way that makes things very
> non-transparent to a user. As it stands, I can optimize for performance by
> using a IRange-type wrapper or I can optimize for code-clarity by killing
> performance.
>
> thanks again, jim
>
>
>
>
>
> >
> > Bill Dunlap
> > Spotfire, TIBCO Software
> > wdunlap tibco.com
> >
> >>
> >> You can implement all(diff(x) == 1) more efficiently in C,
> >> but I don't
> >> see how you could hope to do any better than that without
> >> putting very
> >> un-R-like restrictions on your code.  Do you really want to say that
> >>
> >> A[i:(i+k)]
> >>
> >> is legal, but
> >>
> >> x <- i:(i+k)
> >> A[x]
> >>
> >> is not?  That will be very confusing for your users.  The problem is
> >> that objects don't remember where they came from, only arguments to
> >> functions do, and functions that make use of this fact mainly
> >> do it for
> >> decorating the output (nice labels in plots) or making error messages
> >> more intelligible.
> >>
> >> Duncan Murdoch
> >>
> >> __
> >> 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
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Restrict access to variables in parent environment

[Jeff Ryan]

This isn't like a local variable though, since any function above the
baseenv() in the search path will also not be found.

> f
function(a) { rnorm(b) }


> f()
Error in f() : could not find function "rnorm"

Jeff

On Fri, May 14, 2010 at 9:20 AM, Hadley Wickham  wrote:

> > Hello All,
> >
> > By default, a reference of a variable in a function cause R to look
> > for the variable in the parent environment if it is not available in
> > the current environment (without generating any errors or warnings).
> > I'm wondering if there is a way to revert this behaviors, such that it
> > will not look for the parent environment and will generate an error if
> > the variable is not available in the current environment. Is this
> > tuning has to be done at the C level?
>
> Try this:
> b <- 1
> f <- function(a) {
>  b
> }
>
> environment(f) <- baseenv()
> f()
>
> Hadley
>
> --
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] segfault on 2.11.0 with large POSIXct vector using as.character

[Jeff Ryan]

Running "as.character" on a large POSIXct causes a segfault on my 2.11
(2010-04-22) install.  Seems to crash at around 9e4 ... on OSX and Ubuntu at
least.

> invisible(as.character(Sys.time()+1:7e4))
> invisible(as.character(Sys.time()+1:8e4))
> invisible(as.character(Sys.time()+1:9e4))
Error: segfault from C stack overflow


> invisible(as.character(Sys.time()+1:5e5))
Error: segfault from C stack overflow

Thanks,
Jeff

> sessionInfo()
R version 2.11.0 (2010-04-22)
x86_64-apple-darwin10.2.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base


> sessionInfo()
R version 2.11.0 (2010-04-22)
i486-pc-linux-gnu

locale:
 [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
 [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8
 [7] LC_PAPER=en_US.utf8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
>

-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] segfault on 2.11.0 with large POSIXct vector using as.character

[Jeff Ryan]

>
>
> This has been fixed for a while in R-patched.  The 2.11.1 release on Monday
> should be fine.
> Apparently people aren't running the betas/release candidates.  You really
> should run the test versions to flush out bugs.  If you'd run the
> pre-release versions of 2.11.0, this bug would likely have been found before
> release.  The standard tests can miss things; the advantage of open source
> is there are many eyes looking for bugs.  But if those eyes are closed, the
> model doesn't work.
>

I'd say it does work, and did.  As far as catching before release, that
sounds great, as great as having no bugs.

I am not too sure that my tests could have caught a bug that the got passed
the R tests though, so passing along a segfault issue to those who might
know the source better seemed prudent -- even if I could only have the time
to test against the released version.

Thanks for the fix!

Jeff


> Duncan Murdoch
>
>
>>
>>> invisible(as.character(Sys.time()+1:7e4))
>>> invisible(as.character(Sys.time()+1:8e4))
>>> invisible(as.character(Sys.time()+1:9e4))
>>>
>>>
>> Error: segfault from C stack overflow
>>
>>
>>
>>
>>> invisible(as.character(Sys.time()+1:5e5))
>>>
>>>
>> Error: segfault from C stack overflow
>>
>> Thanks,
>> Jeff
>>
>>
>>
>>> sessionInfo()
>>>
>>>
>> R version 2.11.0 (2010-04-22)
>> x86_64-apple-darwin10.2.0
>>
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>>
>>
>>
>>> sessionInfo()
>>>
>>>
>> R version 2.11.0 (2010-04-22)
>> i486-pc-linux-gnu
>>
>> locale:
>>  [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
>>  [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
>>  [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8
>>  [7] LC_PAPER=en_US.utf8   LC_NAME=C
>>  [9] LC_ADDRESS=C  LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>>
>>
>
>


-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] as.Date.numeric origin default

[Jeff Ryan]

R-devel,

I would like to second Gabor Grothendieck's request from September (
http://www.nabble.com/as.Date.numeric-to12962733.html#a12962733 )
on adding a default value (1970-01-01) to the origin argument of
as.Date.numeric.

I realize there is good reason to allow for origin to be specified,
but I don't see why it must be up to the user at each and every
invocation if most (if not all) users will simply be using 1970-01-01.

My first contact was building quantmod for CRAN - many more hidden
errors occur as I test  on R-devel.  It just seems to me to be an easy
compromise to what will undoubtedly cost many hours of debugging
across all packages/users.

Thank you for your consideration,
Jeff Ryan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] numbers after dot missing (PR#10663)

[Jeff Ryan]

YOU can fix the "problem" : )

Try:

> identical(76079320.32 + 21374.27 + 7630.04 + 28432.47,76136757.1)
[1] TRUE

> identical(76079320.32 + 21374.27 + 7630.04 + 28432.47,76136757)
[1] FALSE

> options(digits=10)
> 76079320.32 + 21374.27 + 7630.04 + 28432.47
[1] 76136757.1

> sessionInfo()
R version 2.7.0 Under development (unstable) (2007-12-25 r43783)
i386-apple-darwin8.11.1

locale:
C

attached base packages:
[1] graphics  grDevices utils datasets  stats methods   base

other attached packages:
[1] quantmod_0.3-2 Defaults_1.1-1 xts_0.0-6  zoo_1.4-1

loaded via a namespace (and not attached):
[1] grid_2.7.0 lattice_0.17-2 rpart_3.1-36
>


On Jan 30, 2008 1:45 AM,  <[EMAIL PROTECTED]> wrote:
> Full_Name: Michael
> Version: 2.6.1
> OS: Windows XP
> Submission from: (NULL) (81.223.30.219)
>
>
> i recognized a problem with the numbers behind a dot, an example:
>
> 76079320.32+21374.27+7630.04+28432.47
> [1] 76136757 // should be 76,136,757.10
>
> > 32+27+4+47 // proof it should be xxx.1
> [1] 110
>
> that kind of problem happened more than 1 time
>
> hope u can fix it :)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
There's a way to do it better - find it.
Thomas A. Edison

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Routine and Deep testing with R CMD check

[Jeff Ryan]

A combination of RUnit from CRAN and .Rbuildignore provide a workable
solution for the 'xts' package I work on, though this obviously
removes the tests from the distributed code.

http://cran.r-project.org/web/packages/RUnit/index.html

--and--

http://wiki.r-project.org/rwiki/doku.php?id=developers:runit

Jeff

On Wed, Jun 11, 2008 at 10:05 AM, Kevin R. Coombes
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I recently provoked some discussion over on the BioConductor developer list
> about testing and R CMD check. In brief, the salient points that arose from
> the discussion are:
>
> [1] Because of the need for a nightly build of BioConductor, the tests (in
> the ./tests directory) of a package that run routinely as part of "R CMD
> check" must complete in five minutes.
> [2] Nontrivial regression testing of complex algorithms on real data can
> easily take longer than five minutes.
> [3] Maintaining and improving code that works on various kinds of "omics"
> data is greatly facilitated by the inclusion of nontrivial regression tests.
>
> Of course, points [1] and [3] are incompatible in the current setup. Both
> could, however, be accommodated by changing the way "R CMD check" runs test
> scripts. There are at least two ways this could be accomplished.
>
> One possibility would be to define a separate directory as part of the
> package structure to store the more complex, longer, "deep" tests. That is,
> one might have
>package/R
>package/man
>package/tests
>package/deeptests  [or some better name]
> Then the default for "R CMD check" would be to run all the .R scripts in
> tests but none of the .R scripts in deep tests. However, one would also have
> to add an option, perhaps something like
>R CMD check --run-deeptests [package]
> to run the more elaborate test scripts.
>
> The second possibility would be to keep all the tests in the same (existing
> ./tests) directory but include a standard file in that directory to indicate
> which scripts are more complex.  This would be a little trickier to design,
> since it would be nice to keep the existing behavior for someone who ignores
> the new structure. One, could however, allow for something like
>
> 
> ## CONTROLTESTS
>
> complex: test1.R, test3.R
> simple:  test2.R, test4.R
> -
>
> The default (in the absence of A CONTROLTESTS file or for scripts in the
> directory that are not listed in the file) is to assume "simple", which
> would then get the existing behavior without changes to existing packages.
>
> How hard would it be to implement one of these approaches for R CMD check?
>
>  -- Kevin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
There's a way to do it better - find it.
Thomas A. Edison

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Passing method to returns() /fSeries (PR#12713)

[Jeff Ryan]

This is a concern of the package maintainer.  Nothing to do with
R-devel or R-bugs.

See the Rmetrics site or fSeries package details for their contact information.

Jeff

On Fri, Sep 5, 2008 at 10:05 AM,  <[EMAIL PROTECTED]> wrote:
> Full_Name: Robert Iquiapaza
> Version: 2.7.2
> OS: Vista
> Submission from: (NULL) (69.127.35.170)
>
>
> In the help Examples for returns(fSeries) it is said that you can pass the
> method to compute ("continuous", "discrete", "compound", "simple") returns 
> using
> 'type='
> i.e.
> # Discrete Returns:
>   returns(MSFT, type = "discrete")
> However when you use 'type' it does compute always the continuous returns, no
> matter what method you select.
> The only way to get the discrete returns is using 'method=' instead
> i.e
> # Discrete Returns:
>   returns(MSFT, method = "discrete")
> I think the help and pdf documentation need to be updated
>
> Robert
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dates in C api

[Jeff Ryan]

If you are looking for examples of handling dates/times (specifically
POSIXct) within C code, the dev branch of xts has quite a bit of code
now.

http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/dev/pkg/src/?root=xts

Assigning the class (or any attribute) within the C code will be much
faster than doing it outside of C, at least in my experience with
larger data.

setAttrib(ans, R_ClassSymbol, mkString("Date"))

HTH
Jeff

On Wed, Sep 17, 2008 at 12:24 PM, Lee, Philip (IT)
<[EMAIL PROTECTED]> wrote:
> r-devel,
>
> I've been trying to write a C plugin for R, and I'm struggling to
> understand how dates are represented.
>
> I can create a date in R:
>> mydate<-as.Date(1, origin="1900-01-01") mydate
> [1] "1900-01-02"
>
> When I pass my date to a plugin, though, it's type is that of a real.
> There doesn't seem to be a date type in Rinternals.h, is there a way to
> recognize that a value is a date rather than a real?
>
> Equally, does anyone know if it's possible to create date values in the
> C api?
>
> Thanks,
> Phil Lee
>
> Philip Lee
> Morgan Stanley | Technology
> 750 Seventh Avenue, 12th Floor | New York, NY  10019
> [EMAIL PROTECTED]
> 
>
> NOTICE: If received in error, please destroy and notify sender. Sender does 
> not intend to waive confidentiality or privilege. Use of this email is 
> prohibited when received in error.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] conditionally import a namespace?

[Jeff Ryan]

Or something along the lines of:

Suggests: RGtk2

f <- function (x, ...)
{
stopifnot("package:RGtk2" %in% search() || require("RGtk2", quietly = TRUE))
 # do Rgtk2 stuff here
}

Jeff

On Thu, Oct 30, 2008 at 9:15 AM, Martin Maechler
<[EMAIL PROTECTED]> wrote:
>> "FA" == Felix Andrews <[EMAIL PROTECTED]>
>> on Thu, 30 Oct 2008 17:40:17 +1100 writes:
>
>FA> Dear R-devel,
>FA> I have a problem defining the dependencies for a package.
>
>FA> My package (latticist, not yet released) "Suggests" RGtk2, but
>FA> specifically does not require it. If RGtk2 is available, the user can
>FA> call a function that builds a GUI with RGtk2. However, I do not want
>FA> to attach the RGtk2 namespace, because it is irrelevant to the user
>FA> and exports about 7500 symbols.
>
>FA> Last time I asked a similar question to this, Professor Ripley noted
>FA> that the usual method to get around this situation is the use an
>FA> explicit package prefix to function calls (the `::` operator). But
>FA> this is not so easy with non-standard functions. Take this chunk of
>FA> code:
>
>FA> widg <- gtkComboBoxEntryNewText()
>FA> widg$show()
>FA> widg["width-request"] <- 100
>
>FA> The first call is easy to prefix, as RGtk2::gtkComboBoxEntryNewText()
>FA> but the others, `$.RGtkObject` and `[<-.RGtkObject` are not.
>
> indeed.
>
>FA> While I *could* rewrite all the code to use explicit functions, I
>FA> think, the resulting code would be much less clear.
>
>FA> Essentially what I want to do is conditionally import the RGtk2 
> namespace.
>FA> Any suggestions?
>
> Maybe something along the line of
>
> if(is.function(try(RGtk2::gtkComboBoxEntryNewText))) {
>   library(RGtk2)
>   
>   
> }
>
> ??
>
> Regards,
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] .C(..., DUP=FALSE) memory costs depending on input size?

[Jeff Ryan]

Marcel,

If you are writing the C code from scratch, take a look at either
.Call or .External, as both make no copies of the input objects, and
require no explicit conversion to the underlying storage type
(numeric/integer/etc) within the function call.

An even greater benefit is that you will also have access to the
actual R objects within C.

Jeff

On Thu, Nov 6, 2008 at 2:05 PM, MarcelK <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I'm trying to create my own C code for use within R. While optimizing the
> code I've noticed that even while only using pointers to get my data to C
> the time needed still depends on data (vector) size.
>
> To test this, I've created an empty C function to which I've send vectors
> containing various sizes of elements. The time needed for each call is
> measured and plotted. I would expect a flat line (a little above y=0) since
> the only thing send are pointers. What I do not expect is to see a linear
> climbing line when the vector size increases. Initializing the vectors isn't
> being measured, only the '.C' call to an empty C function, see below.
>
> Is there anything I'm missing that can explain this input-size dependent
> latency? The only reason I can think of is that these vectors are being
> copied along the way.
>
> What follows is both the R and C code which I use only for testing and a
> plot of both measurements with DUP=TRUE and DUP=FALSE:
>
> (RED: DUP=FALSE, GREEN: DUP=TRUE)
> http://www.nabble.com/file/p20368695/CandR.png
>
>
> R code:
> --
> # sequence from 512 to 2^23 with 2^17 stepsize
> a <- seq(512, 2^23, 2^17)
> # storage for wall time
> h <- length(a); j <- length(a)
> for (i in 1:length(a)) {
>x <- as.double(1:a[i])
>y <- as.double(x)
># system.time()[3] is (actual) wall time
>h[i] <- system.time(.C("commTest", x, y, DUP=FALSE))[3]
>j[i] <- system.time(.C("commTest", x, y, DUP=TRUE))[3]
>x <- 0
>y <- 0
> }
> # plot:
> plot(a, h, type="l", col="red", xlab="Vector Size -->", ylab="Time in
> Seconds -->"); lines(a, j, col="green")
>
>
> C code:
> ---
> #include
> extern "C" {
>void commTest(double* a, double* b);
> }
>
> /*
> * Empty function
> * Just testing communication costs between R --> C
> */
> void commTest(double* a, double* b) {
>  /* Do ab-so-lute-ly-nothing.. */
> }
>
> System Details:
> -
> Linux gpu 2.6.18-6-amd64 #1 SMP Thu May 8 06:49:39 UTC 2008 x86_64 GNU/Linux
> R version 2.7.1 (2008-06-23)
> --
> View this message in context: 
> http://www.nabble.com/.C%28...%2C-DUP%3DFALSE%29-memory-costs-depending-on-input-size--tp20368695p20368695.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dynamic linking to binary code from other packages??

[Jeff Ryan]

Charles,

> I've looked through the "Writing R Extensions" manual, and can't find
> this documented very clearly.  A previous question to the list gave me
> the very kind response pasted below.  I've looked at the suggested
> examples (lme4 using C functions from Matrix).

It isn't really "clearly" explained.  I will give it a try though.

You can't use compiled/packaged functions from within _your_ compiled
code unless the package that you are referring to (affxparser) makes
them available for export.

If affxparser doesn't do this you are back to Dirk's method.

For the sake of others who have gone down this road I will explain
what I know, and probably in the process learn what I may be doing
wrong. (all of this I learned by reading the sources for R and lme4
and Matrix).

Matrix has a copy of the Matrix.h header in its /inst directory,
specifically /inst/include/Matrix.h

This gets installed as /include/Matrix.h, which is where LinkingTo
links to during compilation.

You (or the affxparser author) will also need a handful of C calls
that are complementary to ones in the package you are getting the
functions from.

An example from Matrix:

/include/Matrix_stubs.c contains

...
CHM_DN attribute_hidden
M_as_cholmod_dense(CHM_DN ans, SEXP x)
{
static CHM_DN(*fun)(CHM_DN,SEXP) = NULL;
if(fun == NULL)
fun = (CHM_DN(*)(CHM_DN,SEXP))
R_GetCCallable("Matrix", "as_cholmod_dense");
return fun(ans, x);
}
...

The above is far from obvious, so I will try my best to explain.

With respect to the R_GetCCallable call, Writing R Extensions says:

" p_myCfun = R_GetCCallable("packA", "myCfun");
The author of packB is responsible for ensuring that p_myCfun has an
appropriate declaration. What exactly that means was hard to determine
at first."

Taking the first line, the first CHM_DN is the function return type
(could be int, SEXP, etc), and the second (along with the SEXP) is the
argument type(s).

Generalized you'd have something like:

SEXP attribute_hidden
FUNNAME(SEXP ans, SEXP x)
{
static SEXP(*fun)(SEXP,SEXP) = NULL;
if(fun == NULL)
fun = (SEXP(*)(SEXP,SEXP))
R_GetCCallable("PACKAGE", "FUNCTION");
return fun(ans, x);
}

lme4 then simply "#include"s this .c file in a file
/src/local_stubs.c, which is compiled right along side of the src code
in lme4.

At this point you can then use the functions that are
'exported/registered' as you would a C function defined in your own
package.

The other side of this is what the Matrix (affxparser?) package needs
to do.  It needs a registration routine that specifically registers
the routines as callable using:
  R_RegisterCCallable  (which is documented in Writing R Extensions)

In Matrix this is in /src/init.c via a macro.

A simpler in-progress bit of code can be found in the /dev branch of
xts on R-forge.  Take a look at

http://r-forge.r-project.org/scm/?group_id=118

/dev/src/init.c
/dev/inst/include/xts.h
/dev/inst/include/xts_stubs.c

As far as C++ goes, I would suspect the Matrix package again has all
the bits you are looking for.

HTH
Jeff




-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem trying to download rimage package (second try)

[Jeff Ryan]

You are receiving no reply to your request as you are asking a list
for R package and core developers about a single package (1 of 1600+
on CRAN alone).

1) You should first try everything possible yourself to fix the
problem, AND show your work... (as per posting rules)

2) Then contact the maintainer (as per posting rules).

3) Then ask R-help (not R-devel),

and only then (if ever) as a last resort come here for general install
questions.

The package description to get you to step #2:

http://cran.r-project.org/web/packages/rimage/index.html

Jeff

On Fri, Nov 14, 2008 at 5:34 PM, Shantanu D <[EMAIL PROTECTED]> wrote:
> Hi,
> There seems to have been some problem with posting my earlier message and am
> providing a link to the problem I faced which is at
> https://stat.ethz.ch/pipermail/r-devel/attachments/20081114/84972faf/attachment.pl
> Any help would be appreciated as I need to use this package urgently and
> also tried various other things without luck
> Thanks
>
>[[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] reduce limit number of arguments in methods:::cbind

[Jeff Ryan]

My 2c:

The real issue for me is that this approach to handling S4 objects by
altering R functions for the worse is incorrect. (by calling
bind_activation)

m <- matrix(1:2e6L)  # 2 million obs
> system.time(cbind(m,m))
   user  system elapsed
  0.027   0.017   0.044
> methods:::bind_activation(TRUE)
[1] FALSE

# the additional overhead of cbind is now damaging to cbind S3 methods
> system.time(cbind(m,m))
   user  system elapsed
  0.043   0.034   0.077 [~175% of the original time]

Wouldn't a better near-term approach involve writing S3 methods to dispatch on.

> methods:::bind_activation(FALSE)
> library(Matrix)
> M <- Matrix(1:10)
> cbind(M,M)
 M M
[1,] ? ?

> cbind.dgeMatrix <- function(..., deparse.level=1) methods:::cbind(..., 
> deparse.level=deparse.level)
> cbind(M,M)
10 x 2 Matrix of class "dgeMatrix"
  [,1] [,2]
 [1,]11
 [2,]22
 [3,]33
 [4,]44
 [5,]55
 [6,]66
 [7,]77
 [8,]88
 [9,]99
[10,]   10   10

# this approach "does no harm" to regular S3 methods
> system.time(cbind(m,m))
   user  system elapsed
  0.028   0.017   0.045

Obviously this negates part of the S4 dispatch value, but that can be
had by calling cbind2 directly.


Jeff

-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] any suggestions to deal with 'Argument list too long' for a R CMD check?

[Jeff Ryan]

Never used, but I seem to recall that this was good for that:

http://en.wikipedia.org/wiki/Xargs

Jeff

On Tue, Dec 9, 2008 at 3:13 PM, Whit Armstrong <[EMAIL PROTECTED]> wrote:
> Since, gcc was using upwards of 2gb of ram to compile my package, I
> just split all the functions into individual files.
>
> I guess I'm too clever for myself, because now I get hit with the
> "Argument list too long" error.
>
> Is there a way to deal with this aside from writing my own configure
> script (which could possibly feed the gcc commands one by one).
>
> -Whit
>
> RHEL 5
> [EMAIL PROTECTED] uname -a
> Linux linuxsvr.kls.corp 2.6.18-92.1.18.el5 #1 SMP Wed Nov 5 09:00:19
> EST 2008 x86_64 x86_64 x86_64 GNU/Linux
>
> from 00install.out:
>
> * Installing *source* package 'RFincad' ...
> ** libs
> g++ -I/usr/local/lib64/R/include  -I/usr/local/include
> -I./RAbstraction -I./R.tslib.backend -I./tslib -fpic  -g -O2 -c
> aaAccrual_days_act252.cpp -o aaAccrual_days_act2\
> 52.o
> make: execvp: g++: Argument list too long
> make: *** [aaAccrual_days_act252.o] Error 127
> ERROR: compilation failed for package 'RFincad'
> ** Removing 
> '/home/whit/dvl/fincad.utils/fincad.generate.R/RFincad.Rcheck/RFincad'
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] package development

[Jeff Ryan]

A quick comment on two subjects:

First to get the line # from the command line:

cat pkg/R/* > all.R
wc all.R
vim +LINE all.R  (or pick you favorite method here...)

>From there it should be easy enough to get context.  At least enough
to grep back into the R directory.

Also, the use of unit-tests is IMO the best answer  for managing a
separate test suite that you can selectively run (all of part of)
during the build phase.

Simply editing/adding an .Rbuildignore is all you need to turn it off
or on.  This makes it easy not to distribute the tests as well, if you
choose not too.

RUnit is a good tool to look into.

HTH
Jeff

On Fri, Dec 12, 2008 at 8:12 AM, Paul Gilbert
 wrote:
>
>
> Duncan Murdoch wrote:
>>
>> On 11/12/2008 6:04 PM, Terry Therneau wrote:
>>>
>>>  I'm making the move of the survival package from my own environment to,
>>> and have stumbled into a vacuum.   The R Extensions manual has really
>>> nice
>>> instructions about how to lay out the directories, order the files, and
>>> run tests for DISTRIBUTION of a product, but I can't find anything on how
>>> to set up a reasonable DEVELOPMENT environment.
>>>   In my local world, I had the .c and .s files in a common directory,
>>> with
>>> a Makefile that I had created, and the test suite in a subdirectory.
>>>  Debugging
>>> and development was quite nice.
>>>make
>>>cd test
>>>R
>>>attach("..")
>>>try something and perhaps it fails
>>>q()
>>>cd ..
>>> Fix and repeat. The Makefile took some time to create, but paid for
>>> itself a
>>> hundred times over.
>>>  So, I've now rearranged everything into standard R order.  Then I did
>>> the
>>> only thing I could find
>>>R CMD INSTALL ~/myRlib  survival  where "survival" is said directory.
>>>   This turns out to be not useful at all.
>>> The survival package is large, and I rather suspected that I would goof
>>> something up, and I did, resulting in the following message
>>>
>>>Error in parse(n = -1, file = file) : unexpected end of input at
>>>14450: }
>>>14451:
>>> It is not exactly obvious which of the 132 files in my R/ directory is
>>> the culprit here.
>>
>> That's something I would like to fix too.  There are (at least) two
>> possible ways:  stop concatenating the files (which is not really needed
>> nowadays, most packages install saved images), or add some markup to the
>> concatenated file so that the parser can report on the original filename and
>> line number (like the #LINE directives output by the C preprocessor).
>
> I would certainly appreciate a fix for this.  When this has happened to me,
> I usually end up just sourcing the individual files into an R session until
> I find the bad file, and get a report with the right line number. It always
> seems like a lot of work for something that should be trivial.
>
>>
>>>
>>>   In general:
>>> 1. The library is large, and recompiling/reparsing everything is very far
>>> from
>>> instantaneous.  It is not the edit/load cycle I desire.
>>
>> If you install from the directory, the compiling should only be done once
>> (unless you change a file, of course).  (The alternative is installing from
>> the tarball, which is recommended for later stages of testing before
>> distribution, because it's possible something could go wrong in building the
>> tarball.  But it won't include any object files, so you'll recompile every
>> time.)
>>
>> You can also use option "--docs=none" to skip building the help system;
>> this will save a bit of time.
>>
>>
>>>
>>> 2. I take testing seriously: the test suite takes on the order of 15
>>> minutes to
>>> run on a fast machine.  I most certainly don't want to run it in the mid
>>> cycle.
>>
>> I don't quite follow this.  If you want to run all your tests, you would
>> use R CMD check.  If you only want to run some of them, then you can source
>> things out of the tests directory while running interactively.
>>
>>>   Someone must have tackled this.  I'm hoping that there is some
>>> documentation
>>> that I have managed to overlook which discussess a good setup for this
>>> middle
>>> ground between concieving of a library and packaging it for delivery; the
>>> "build, test, make sure it acually works" part of development.
>
> In my experience there are two differ sorts of problems that I think could
> benefit from some improvement. The first is that there should be a standard
> way to have extra tests, that do not get run in the normal CRAN testing
> cycle, or by developers when using a "quick" R CMD check, but can be run
> with a standard mechanism. I do this by putting the tests in a separate
> package, and I have seen reports of different mechanisms, but I think they
> are all somewhat ad hoc. Currently, if you put too much testing in your
> package then all the testing gets omitted on some CRAN testing platforms.
> Just a common directory like extraTests/ would be a good start.
>
> The second problem is that a developer usually needs to run te

Re: [Rd] package development

[Jeff Ryan]

I think the /tmp file gets removed:

ERROR: lazy loading failed for package 'xts'
** Removing '/private/tmp/Rinst625532301/xts'
 ERROR
Installation failed.
Removing '/tmp/Rinst625532301'

At least it seems to when I run R CMD from the shell.

>
> Yes, there are several options for not distributing tests.  I was thinking
> more about how to distribute them with a simple mechanism for anyone to run
> them, but in a way that they are not run by the usual R CMD check.
>

You can still distribute the tests in the inst/unitTests directory,
you would just have to make sure that the calling script in the /tests
directory is commented out.

Alternately you could have that /tests/doRUnit.R script (or whatever
you call it/them) check for some environment variable to be set before
running the full suite.

Jeff

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] length of POSIXlt object (PR#13482)

[Jeff Ryan]

Read the docs. POSIXlt is a list of 9 elements. Each element length is
what you think it should be returning.  That is not correct.

?POSIXlt

Details:

 There are two basic classes of date/times.  Class '"POSIXct"'
 represents the (signed) number of seconds since the beginning of
 1970 as a numeric vector.  Class '"POSIXlt"' is a named list of
 vectors representing

> unclass(as.POSIXlt(as.POSIXlt('2007-01-01')+1:11))
$sec
 [1]  1  2  3  4  5  6  7  8  9 10 11

$min
 [1] 0 0 0 0 0 0 0 0 0 0 0

$hour
 [1] 0 0 0 0 0 0 0 0 0 0 0

$mday
 [1] 1 1 1 1 1 1 1 1 1 1 1

$mon
 [1] 0 0 0 0 0 0 0 0 0 0 0

$year
 [1] 107 107 107 107 107 107 107 107 107 107 107

$wday
 [1] 1 1 1 1 1 1 1 1 1 1 1

$yday
 [1] 0 0 0 0 0 0 0 0 0 0 0

$isdst
 [1] 0 0 0 0 0 0 0 0 0 0 0

attr(,"tzone")
[1] """CST" "CDT"


Jeff


On Wed, Jan 28, 2009 at 4:15 PM,   wrote:
> The length() of a POSIXlt object is given as 9 regardless of the actual
> length. For example:
>
>> make.date.time
> function (year=c(2006,2006),month=c(8,8),day=2:5,hour=13,minute=45)
> {# convert year, etc., into POSIXlt object
> #
> d=as.character(make.date(year,month,day))
> t=paste(hour,minute,sep=":")
> as.POSIXlt(paste(d,t))
> }
>> t=make.date.time()
>> t
> [1] "2006-08-02 13:45:00" "2006-08-03 13:45:00" "2006-08-04 13:45:00"
> [4] "2006-08-05 13:45:00"
>> length(t)
> [1] 9
>> t[1]
> [1] "2006-08-02 13:45:00"
>> length(t[1])
> [1] 9
>
>
>
> --
> blog.sethroberts.net
> www.shangriladiet.com
> boards.shangriladiet.com
> cell phone 510 418 7753 (Berkeley)
>
>[[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] POSIXlt, POSIXct, strptime, GMT and 1969-12-31 23:59:59

[Jeff Ryan]

R-devel:

Some very inconsistent behavior, that I can't seem to find documented.

Sys.setenv(TZ="GMT")

str(unclass(strptime("1969-12-31 23:59:59","%Y-%m-%d %H:%M:%S")))
List of 9
 $ sec  : num 59
 $ min  : int 59
 $ hour : int 23
 $ mday : int 31
 $ mon  : int 11
 $ year : int 69
 $ wday : int 3
 $ yday : int 364
 $ isdst: int 0
 - attr(*, "tzone")= chr "GMT"

# setting to 59 seconds now reports 0
str(unclass(as.POSIXlt("1969-12-31 23:59:59")))
List of 9
 $ sec  : num 0
 $ min  : int 59
 $ hour : int 23
 $ mday : int 31
 $ mon  : int 11
 $ year : int 69
 $ wday : int 3
 $ yday : int 364
 $ isdst: int 0
 - attr(*, "tzone")= chr "GMT"
>

Setting the secs in the string to 58 returns a correct structure:
str(unclass(as.POSIXlt("1969-12-31 23:59:58")))
List of 9
 $ sec  : num 58
 $ min  : int 59
 $ hour : int 23
 $ mday : int 31
 $ mon  : int 11
 $ year : int 69
 $ wday : int 3
 $ yday : int 364
 $ isdst: int 0
 - attr(*, "tzone")= chr "GMT"

Some additional strangeness occurs once as.POSIXct is called:

str(as.POSIXct(as.POSIXlt("1969-12-31 23:59:58")))
 POSIXct[1:1], format: "1969-12-31 23:59:58"

# this incorrectly ignores the secs
str(as.POSIXct(as.POSIXlt("1969-12-31 23:59:59")))
 POSIXct[1:1], format: "1969-12-31 23:59:00"

# this should be -1, if I am not mistaken
str(as.POSIXct(strptime("1969-12-31 23:59:59","%Y-%m-%d %H:%M:%S")))
 POSIXct[1:1], format: NA

According to ?strptime NA should be returned if the time doesn't
exist.  As far as I can tell, 1969-12-31 23:59:59 does exists.

Using a simple C program (source follows this message):

[veblen:~/Rforge/xts] jryan% ./a.out
Date as tm struct (POSIXlt):1969-12-31 23:59:59
   sec: 59
   min: 59
  hour: 23
  mday: 31
   mon: 11
  year: 69
  wday: 3
  yday: 364
seconds since the Epoch: -1

Which gives the -1. This is all run on a Intel Mac, though has been
tested on FreeBSD and Ubuntu as well with the same outcome.  It does
seem to work fine on Windows though.  I think the workaround for
Windows is what is causing the failure elsewhere.

As far as I can see, the code that is causing this is do_asPOSIXct in
datetime.c:

 695 if(!R_FINITE(secs) || tm.tm_min == NA_INTEGER ||
 696tm.tm_hour == NA_INTEGER || tm.tm_mday == NA_INTEGER ||
 697tm.tm_mon == NA_INTEGER || tm.tm_year == NA_INTEGER)
 698 REAL(ans)[i] = NA_REAL;
 699 else {
 700 errno = 0;
 701 tmp = mktime0(&tm, 1 - isgmt);
 702 #ifdef MKTIME_SETS_ERRNO
 703 REAL(ans)[i] = errno ? NA_REAL : tmp + (secs - fsecs);
 704 #else
 705 REAL(ans)[i] = (tmp == (double)(-1)) ?
 706 NA_REAL : tmp + (secs - fsecs);
 707 #endif
 708 }

I haven't been able to look further into this logic, but the test for
-1 strikes me as where this is happening.

Thank you for any insight you can provide.

Jeff

> sessionInfo()
R version 2.9.0 Under development (unstable) (2009-02-27 r48020)
i386-apple-darwin8.11.1

locale:
C

attached base packages:
[1] stats graphics  grDevices utils     datasets  methods   base


# C PROGRAM #

#include 
#include 
/*
   code modified from:

   http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html
   by Jeff Ryan
*/

struct tm tm;
time_t t;


int main()
{
char DATE[] = "1969-12-31 23:59:59";
printf("Date as tm struct (POSIXlt):%s\n", DATE);

strptime(DATE, "%Y-%m-%d %H:%M:%S", &tm);

tm.tm_isdst = -1;  /* Not set by strptime(); tells mktime()
  to determine whether daylight saving time
  is in effect */
t = mktime(&tm);
printf(
   "   sec: %d\n"
   "   min: %d\n"
   "  hour: %d\n"
   "  mday: %d\n"
   "   mon: %d\n"
   "  year: %d\n"
   "  wday: %d\n"
   "  yday: %d\n",
   tm.tm_sec,
   tm.tm_min,
   tm.tm_hour,
   tm.tm_mday,
   tm.tm_mon,
   tm.tm_year,
   tm.tm_wday,
   tm.tm_yday);

printf("seconds since the Epoch: %d\n", t);
return 0;
}


-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug of *switch* function

[Jeff Ryan]

This isn't a bug in R.

You are assigning within the switch statement, and it is returning the
first TRUE value (human).

Use "=" not "<-"

species <- switch(organism, human="HS", fly="DM", yeast="SC")
> species
[1] "SC"


HTH
Jeff

On Mon, Mar 9, 2009 at 8:55 AM, guangchuang yu  wrote:
> Hi,
>
> When I call the *switch* function first time, it works. but when I call it
> at the second time, it does nothing. The version I use is R version 2.9.0
> Under development (unstable) (2009-02-21 r47969)
>
>
> here is the output:
>
>> organism="human"
>>     species <- switch(organism,
>        human <- "Hs",
>        fly <- "Dm",
>        mouse <- "Mm",
>        rat <- "Rn",
>        yeast <- "Sc"
>    )
>  species <- switch(organism,
> +   human <- "Hs",
> +   fly <- "Dm",
> +   mouse <- "Mm",
> +   rat <- "Rn",
> +   yeast <- "Sc"
> +  )
>> species
> [1] "Hs"
>> organism="yeast"
>>     species <- switch(organism,
>        human <- "Hs",
>        fly <- "Dm",
>        mouse <- "Mm",
>        rat <- "Rn",
>        yeast <- "Sc"
>    )
>  species <- switch(organism,
> +   human <- "Hs",
> +   fly <- "Dm",
> +   mouse <- "Mm",
> +   rat <- "Rn",
> +   yeast <- "Sc"
> +  )
>> species
> [1] "Hs"
>
>
> when I change *organism* to "yeast", and call *switch* function again,
> *species* suppose to be changed to "Sc", but it remain it's original value.
>
> You can see my screenshot at
> http://ygc.azpala.com/2009/03/09/bug-of-r-29-dev
>
> --
> Bests,
> Guangchuang Yu
>
> --~--~-~--~~~---~--~~
> Rm 848 Dept 9
> Institute of Radiation Medicine
> 27 Taiping Rd. Haidian Dist.
> Beijing, 100850, China
> Telephone: (86)-010-66931422
> Mobile: +86-13439009806
> Email: guangchuan...@gmail.com
> -~--~~~~--~~--~--~---
>
>        [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Jeffrey Ryan
jeffrey.r...@insightalgo.com

ia: insight algorithmics
www.insightalgo.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel