[Rd] hanging spaces prior to linebreak from cat()

[Tim Triche, Jr.]

(re-sending after confirming list subscription; apologies if this ends up
being sent to the list twice)

Is the expected behavior from cat(), as used below, a hanging space before
\n at the end of the emitted line?

 firstheader = gsub("\\s+$", "", paste(c("Hybridization REF", s, s),
collapse = "\t"))
 cat(firstheader, "\n", file = filename)

When I run the above code, which is followed by appending the contents of a
data.frame via write.table(), what I get is a file whose first line ends in
a " \n" (note the space preceding the newline).  I would think that the
gsub() would have trimmed off this hanging space, but it doesn't.  Is this a
strange bug or expected behavior?  I have attached the version of cat.R in
from the SVN checkout I am running as my R build; it doesn't seem awry...
?!?

> sessionInfo()
R version 2.14.0 Under development (unstable) (2011-04-21 r55577)
Platform: x86_64-unknown-linux-gnu (64-bit)

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

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

other attached packages:
 [1] EGC.tools_1.0
IlluminaHumanMethylation27k.db_1.4.6
 [3] IlluminaHumanMethylation450k.db_1.4.6 org.Hs.eg.db_2.5.0
 [5] RSQLite_0.9-4 DBI_0.2-5
 [7] AnnotationDbi_1.15.7  Biobase_2.13.2
 [9] gtools_2.6.2  reshape_0.8.4
[11] plyr_1.4

loaded via a namespace (and not attached):
[1] annotate_1.31.0   grid_2.14.0   lattice_0.19-17   matrixStats_0.2.2
[5] methylumi_1.9.5   xtable_1.5-6


-- 
If people do not believe that mathematics is simple, it is only because they
do not realize how complicated life is.
John von 
Neumann
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R cmd check and multicore foreach loop

[Tim Triche, Jr.]

I'll see if I can put together a self-contained example.  Primarily, the
times that I use multicore (and attempted to use doSMP, mostly because one
of my users refuses to ditch Windows) are when I am reading a ton of binary
files, none of which depend on the others.  This is a blindingly obvious
use-case for e.g. doMC and doSMP, yet what typically happens is that the
entire operation wedges.  I'm told that doSMP really only works well with
Revolution R, but per above, I will try to put together a working
self-contained example to show how.


On Wed, Aug 17, 2011 at 4:39 AM, Renaud Gaujoux wrote:

> **
> I did notice some strange behaviour once, but things were working without a
> problem for a while now.
> foreach loops and concepts are nice concepts, which I'd like to carry on
> using.
> Maybe somebody from the foreach-dopar packages could explain why they have
> such issues?
>
> Tim do you have concrete examples of the issues you talked with other
> developers?
>
> Thank you.
>
> Renaud
>
> On 17/08/2011 12:45, Tim Triche, Jr. wrote:
>
> yes -- doMC (and doSMP) are kind of bogus and I just use
> multicore::mclapply() to good effect these days.  I checked around with
> other people doing similar things at the Bioconductor developer day and
> pretty much everyone confirmed that doWHATEVER seems to have issues, where
> as multicore itself... doesn't.
>
>  Just my $0.02,
>
>  --t
>
>
> On Wed, Aug 17, 2011 at 1:45 AM, Renaud Gaujoux <
> ren...@mancala.cbio.uct.ac.za> wrote:
>
>> Hi,
>>
>> in R 2.12.1, R CMD check hangs when building a vignette that uses a
>> foreach loop with the doMC parallel backend.
>> This does not happen in R 2.13.1, nor if I use doSEQ instead of doMC.
>> All versions of multicore, doMC and foreach are the same on both my R
>> installations.
>>
>> Has anybody encountered a similar issue?
>>
>> Thank you.
>> Renaud
>>
>>
>>
>>
>> ###
>> UNIVERSITY OF CAPE TOWN
>> This e-mail is subject to the UCT ICT policies and e-mai...{{dropped:5}}
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
>  --
>  If people do not believe that mathematics is simple, it is only because
> they do not realize how complicated life is.
> John von 
> Neumann<http://www-groups.dcs.st-and.ac.uk/%7Ehistory/Biographies/Von_Neumann.html>
>
>
>  ###
>
> UNIVERSITY OF CAPE TOWN
>
>  This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
> addressed. If the e-mail has reached you in error, please notify the author.
> If you are not the intended recipient of the e-mail you may not use,
> disclose, copy, redirect or print the content. If this e-mail is not related
> to the business of UCT it is sent by the sender in the sender's individual
> capacity.
>
>  ###
>



-- 
When you emerge in a few years, you can ask someone what you missed, and
you'll find it can be summed up in a few minutes.

Derek Sivers <http://sivers.org/berklee>

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

[Tim Triche, Jr.]

Or maybe it would be sensible to ask GitHub if they can fix this.

If it's a common-ish use case (e.g. for mirrors), it's not something that
should be terribly challenging engineering-wise, and it would prevent a lot
of hooha.

Funfact: GitHub is run and staffed by actual people, most of them pretty
cool



Statistics is the grammar of science.
Karl Pearson 

On Tue, May 26, 2015 at 10:43 AM, Henrik Bengtsson <
henrik.bengts...@ucsf.edu> wrote:

> On Tue, May 26, 2015 at 12:45 AM, Gábor Csárdi 
> wrote:
> > On Mon, May 25, 2015 at 8:28 PM, Simon Urbanek <
> simon.urba...@r-project.org>
> > wrote:
> >
> >> One issue I have with this is that it doesn't point to the original
> GitHub
> >> repositories of the packages, so you end up with additional
> repositories on
> >> Github in Gabor's name that have nothing to do with the actual Github
> >> repositories of the packages. I understand that it's technically
> necessary,
> >> but I fear it will lead to a lot of confusion...
> >
> >
> > Well, we point to the original GitHub repo is that is given in the URL
> > field. It would be nice to have an "official" field for source code
> > repository in DESCRIPTION.
> >
> > But I agree with you that this has great potential for confusion. Several
> > people have been sending pull requests to github.com/cran repos, most of
> > them not realizing that they are not the right repos to fork. (Although
> > many packages are not on GH or any other similar service, and then are
> kind
> > of the places to fork.)
> >
> > I could have a large warning popup on the link from r-pkg.org, with red
> > flags, and you would see this before the actual repo. But this has its
> own
> > problems, like being annoying after a while, how to turn it off with
> > browser cookies, etc.
> >
> > The best would be to somehow have a warning on the GitHub repo pages, but
> > there isn't a lot I can modify there if I don't want to change/add the
> > README file, which would effectively change the package. I could probably
> > add 'WARNING: this is a read-only mirror, and not the original package
> > repository' to the one-line description on the top.
> >
> > If you have other ideas, please let me know.
>
> If people send pull requests, maybe adding a generic open pull request
> to each repository with title "MIRROR ONLY: Do not send pull requests
> here" would help.  The fancy version would be to say "MIRROR ONLY: All
> patches/pull requests should be sent to ", where  is from
> the DESCRIPTION field 'URL'.  That might prevent a few more.
> You can boost it with lots of colorful "WARNING", "NO
> TRESPASSING", ... labels as well.   The next level up is to
> have a service that automatically reject pull requests with an
> informative error message.
>
> /Henrik
>
>
> >
> > Gabor
> >
> >
> >> On May 24, 2015, at 5:44 AM, Rainer M Krug  wrote:
> >>
> >> > Gábor Csárdi  writes:
> >> >
> >> >> Dear All,
> >> >>
> >> >> [ I was wondering if this should have gone to the new mailing list.
> >> Maybe. ]
> >> >>
> >> >> As some of you maybe know from my earlier posts, I am building a
> simple
> >> >> search engine for R packages. Now the search engine has a proper web
> >> site,
> >> >> where you can also browse CRAN packages.
> >> >>
> >> >> http://www.r-pkg.org/
> >> >>
> >> >> As I see the value is in
> >> >> 1. package search (search box on top right)
> >> >> 2. APIs, see http://www.r-pkg.org/services
> >> >>
> >> >> It is in alpha version, meaning that things seem to work, some pages
> >> are a
> >> >> bit slow and there are a lot of glitches to fix.
> >> >
> >> > I had a quick peek, and it looks really nice! I particularly think the
> >> > github integration for diff-ing versions can be very use full!
> >> >
> >> > It might be an idea, to also add R itself to the github repo for
> >> > diff-ing?
> >> >
> >> > Thanks a lot,
> >> >
> >> > Rainer
> >> >
> >> >>
> >> >> Please tell me what you think.
> >> >>
> >> >> Best,
> >> >> Gabor
> >> >>
> >> >>  [[alternative HTML version deleted]]
> >> >>
> >> >
> >> > --
> >> > Rainer M. Krug
> >> > email: Rainerkrugsde
> >> > PGP: 0x0F52F982
> >> > __
> >> > 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
>
> __
> 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] MetaCran website v1.0.0-alpha

[Tim Triche, Jr.]

What you are doing is great, and that's a pretty clear warning (I would go
ahead and add "DO NOT FORK ME" to the verbiage since I am one of the
dumbasses who submitted a pull request in such a fashion, whereupon the
original author got to set up a Git repo, I re-PR'ed against that, and all
was well).  But the fact that Dan wrote a bot for the BioC git mirror
specifically to bounce PR's... well, it's unlikely that this is an isolated
need.

A simple switch indicating that a repo is a mirror and should not accept
pull requests would be something that GitHub could implement once, and an
entire class of users would benefit from it.  It might even be a selling
point for business users, people who pay for private repos, etc.

I am going to get in touch with a former coworker who now works at GitHub
and ask him how much trouble this would really be on their end.  It's so
easy to underestimate the scope of features from outside, but if it really
is as easy as adding a hook to bounce PRs, I hope they will consider it as
a use case.




Statistics is the grammar of science.
Karl Pearson 

On Tue, May 26, 2015 at 11:16 AM, Gábor Csárdi 
wrote:

> On Tue, May 26, 2015 at 2:10 PM, Gabriel Becker 
> wrote:
> [...]
>
> >
> > Well, sort of. I mean if the package is being actively developed not on
> > github, forking your archive repo and developing a patch/etc against it
> > won't necessarily be particularly effective, as there is no way to have
> the
> > right starting point (state of trunk), right?
> >
>
> Well, then you can do 1) git rebase or 2) get the patch if the original
> repo is not in git.
>
> Yes, this is not ideal. I could remove that "Browse the source" completely,
> that is an option, and remove the link from the version number as well.
> There there will be no links to github.com/cran. Experienced users will
> just type in the URL. That's fine with me, too.
>
> Btw. how does this look for a warning: https://github.com/cran/crayon
> This is the most red I could find.
>
> G.
>
> [[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] [RFC] A case for freezing CRAN

[Tim Triche, Jr.]

That doesn't make sense.

If an API changes (e.g. in Matrix) and a program written against the old
API can no longer run, that is a very different issue than if the same
numbers (data) give different results.  The latter is what I am guessing
you address.  The former is what I believe most people are concerned about
here.  Or at least I hope that's so.

It's more an issue of usability than reproducibility in such a case, far as
I can tell (see e.g.
http://liorpachter.wordpress.com/2014/03/18/reproducibility-vs-usability/).
 If the same data produces substantially different results (not
attributable to e.g. better handling of machine precision and so forth,
although that could certainly be a bugaboo in many cases... anyone who has
programmed numerical routines in FORTRAN already knows this) then yes,
that's a different type of bug.  But in order to uncover the latter type of
bug, the code has to run in the first place.  After a while it becomes
rather impenetrable if no thought is given to these changes.

So the Bioconductor solution, as Herve noted, is to have freezes and
releases.  There can be old bugs enshrined in people's code due to using
old versions, and those can be traced even after many releases have come
and gone, because there is a point-in-time snapshot of about when these
things occurred.  As with (say) ANSI C++, deprecation notices stay in place
for a year before anything is actually done to remove a function or break
an API.  It's not impossible, it just requires more discipline than
declaring that the same program should be written multiple times on
multiple platforms every time.  The latter isn't an efficient use of
anyone's time.

Most of these analyses are not about putting a man on the moon or making
sure a dam does not break.  They're relatively low-consequence exploratory
sorties.  If something comes of them, it would be nice to have a
point-in-time reference to check and see whether the original results were
hooey.  That's a lot quicker and more efficient than rewriting everything
from scratch (which, in some fields, simply ensures things won't get
checked).

My $0.02, since we do still have those to bedevil cashiers.



Statistics is the grammar of science.
Karl Pearson 


On Thu, Mar 20, 2014 at 1:28 PM, Ted Byers  wrote:

> On Thu, Mar 20, 2014 at 3:14 PM, Hervé Pagès  wrote:
>
> > On 03/20/2014 03:52 AM, Duncan Murdoch wrote:
> >
> >> On 14-03-20 2:15 AM, Dan Tenenbaum wrote:
> >>
> >>>
> >>>
> >>> - Original Message -
> >>>
>  From: "David Winsemius" 
>  To: "Jeroen Ooms" 
>  Cc: "r-devel" 
>  Sent: Wednesday, March 19, 2014 11:03:32 PM
>  Subject: Re: [Rd] [RFC] A case for freezing CRAN
> 
> 
>  On Mar 19, 2014, at 7:45 PM, Jeroen Ooms wrote:
> 
>   On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt
> >  wrote:
> >
> >> Reading this thread again, is it a fair summary of your position
> >> to say "reproducibility by default is more important than giving
> >> users access to the newest bug fixes and features by default?"
> >> It's certainly arguable, but I'm not sure I'm convinced: I'd
> >> imagine that the ratio of new work being done vs reproductions is
> >> rather high and the current setup optimizes for that already.
> >>
> >
> > I think that separating development from released branches can give
> > us
> > both reliability/reproducibility (stable branch) as well as new
> > features (unstable branch). The user gets to pick (and you can pick
> > both!). The same is true for r-base: when using a 'released'
> > version
> > you get 'stable' base packages that are up to 12 months old. If you
> > want to have the latest stuff you download a nightly build of
> > r-devel.
> > For regular users and reproducible research it is recommended to
> > use
> > the stable branch. However if you are a developer (e.g. package
> > author) you might want to develop/test/check your work with the
> > latest
> > r-devel.
> >
> > I think that extending the R release cycle to CRAN would result
> > both
> > in more stable released versions of R, as well as more freedom for
> > package authors to implement rigorous change in the unstable
> > branch.
> > When writing a script that is part of a production pipeline, or
> > sweave
> > paper that should be reproducible 10 years from now, or a book on
> > using R, you use stable version of R, which is guaranteed to behave
> > the same over time. However when developing packages that should be
> > compatible with the upcoming release of R, you use r-devel which
> > has
> > the latest versions of other CRAN and base packages.
> >
> 
> 
>  As I remember ... The example demonstrating the need for this was an
>  XML package that cause an extract from a website where the headers
>  were mis

Re: [Rd] [RFC] A case for freezing CRAN

[Tim Triche, Jr.]

> There is nothing like backups with due attention to detail.

Agreed, although given the complexity of dependencies among packages, this
might entail several GB of snapshots per paper (if not several TB for some
papers) in various cases.  Anyone who is reasonably prolific then gets the
exciting prospect of managing these backups.

At least if I grind out a vignette with a bunch of Bioconductor packages
and call sessionInfo() at the end, I can find out later on (if, say, things
stop working) what was the state of the tree when it last worked, and what
might have changed since then.  If a self-contained C++ or FORTRAN program
is sufficient to perform an entire analysis, that's awesome, and it ought
to be stuffed into revision control (doesn't everyone already do this?).
 But once you start using tools that depend on other tools, it becomes
substantially more difficult to ensure that

1) a comprehensive snapshot is taken
2) reviewers, possibly on different platforms and/or major versions, can
run using that snapshot
3) some means of a quick sanity check ("does this analysis even return
sensible results?") can be run

Hopefully this is better articulated than my previous missive.

I believe we fundamentally agree; some of the particulars may be an issue
of notation or typical workflow.



Statistics is the grammar of science.
Karl Pearson 


On Thu, Mar 20, 2014 at 2:13 PM, Ted Byers  wrote:

> On Thu, Mar 20, 2014 at 4:53 PM, Jeroen Ooms  >wrote:
>
> > On Thu, Mar 20, 2014 at 1:28 PM, Ted Byers 
> wrote:
> >>
> >> Herve Pages mentions the risk of irreproducibility across three minor
> >> revisions of version 1.0 of Matrix.  My gut reaction would be that if
> the
> >> results are not reproducible across such minor revisions of one library,
> >> they are probably just so much BS.
> >>
> >
> > Perhaps this is just terminology, but what you refer to I would generally
> > call 'replication'. Of course being able to replicate results with other
> > data or other software is important to validate claims. But being able to
> > reproduce how the original results were obtained is an important part of
> > this process.
> >
> > Fair enough.
>
>
> > If someone is publishing results that I think are questionable and I
> > cannot replicate them, I want to know exactly how those outcomes were
> > obtained in the first place, so that I can 'debug' the problem. It's
> quite
> > important to be able to trace back if incorrect results were a result of
> a
> > bug, incompetence or fraud.
> >
> > OK.  That is where archives come in.  When I had to deal with that sort
> of
> thing, I provided copies of both data and code to whoever asked.  It ought
> not be hard for authors to make an archive, to e.g. an optical disk, that
> includes the software used along with the data, and store it like any other
> backup, so it can be provided to anyone upon request.
>
>
> > Let's take the example of the Reinhart and Rogoff case. The results
> > obviously were not replicable, but without more information it was just
> the
> > word of a grad students vs two Harvard professors. Only after reproducing
> > the original analysis it was possible to point out the errors and proof
> > that the original were incorrect.
> >
> >
> >
> >
> > Ok, but, if the practice I used were used, then a copy of the optical
> disk
> to which everything relevant was stored would solve that problem (and it
> would be extremely easy for the researcher or his/her supervisor to do).  I
> once had a reviewer complain he couldn't reproduce my results, so I sent
> him my code, which, translated into any of the Algol family of languages,
> would allow  him, or anyone else, to replicate my results regardless of
> their programming language of choice.  Once he had my code, he found his
> error and reported back that he had finally replicated my results.  Several
> of my colleagues used the same practice, with the same consequences
> (whenever questioned, they just provide their code, and related software,
> and then their results were reproduced).  There is nothing like backups
> with due attention to detail.
>
> Cheers
>
> Ted
>
> --
> R.E.(Ted) Byers, Ph.D.,Ed.D.
>
> [[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] [RFC] A case for freezing CRAN

[Tim Triche, Jr.]

Heh, you just described BioC

--t

> On Mar 20, 2014, at 7:15 PM, Gábor Csárdi  wrote:
> 
> On Thu, Mar 20, 2014 at 9:45 PM, William Dunlap  wrote:
> 
>>> In particular, updating a package with many reverse dependencies is a
>>> frustrating process, for everybody. As a maintainer with ~150 reverse
>>> dependencies, I think not twice, but ten times if I really want to
>> publish
>>> a new version on CRAN.
>> 
>> It might be easier if more of those packages came with good test suites.
> 
> Test suites are great, but I don't think this would make my job easier.
> More tests means more potential breakage. The extreme of not having any
> examples and tests in these 150 packages would be the easiest for _me_,
> actually. Not for the users, though.
> 
> What would really help is either fully versioned package dependencies
> (daydreaming here), or having a CRAN-devel repository, that changes and
> might break often, and a CRAN-stable that does not change (much).
> 
> Gabor
> 
> [...]
> 
>[[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] [RFC] A case for freezing CRAN

[Tim Triche, Jr.]

Except that tests (as vignettes) are mandatory for BioC. So if something blows 
up you hear about it right quick :-)

--t

> On Mar 20, 2014, at 7:15 PM, Gábor Csárdi  wrote:
> 
> On Thu, Mar 20, 2014 at 9:45 PM, William Dunlap  wrote:
> 
>>> In particular, updating a package with many reverse dependencies is a
>>> frustrating process, for everybody. As a maintainer with ~150 reverse
>>> dependencies, I think not twice, but ten times if I really want to
>> publish
>>> a new version on CRAN.
>> 
>> It might be easier if more of those packages came with good test suites.
> 
> Test suites are great, but I don't think this would make my job easier.
> More tests means more potential breakage. The extreme of not having any
> examples and tests in these 150 packages would be the easiest for _me_,
> actually. Not for the users, though.
> 
> What would really help is either fully versioned package dependencies
> (daydreaming here), or having a CRAN-devel repository, that changes and
> might break often, and a CRAN-stable that does not change (much).
> 
> Gabor
> 
> [...]
> 
>[[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] MetaCran website v1.0.0-alpha

[Tim Triche, Jr.]

> Please tell me what you think.

I think it is awesome, just like the CRAN-github bridge.

It would be cool if you provided CRAN authors with instructions on how to
fork the CRAN-github clones of the source code so that I don't have to
retarget pull requests ;-)

In conclusion, keep up the great work


Statistics is the grammar of science.
Karl Pearson 

On Sat, May 23, 2015 at 7:02 AM, Gábor Csárdi 
wrote:

> Dear All,
>
> [ I was wondering if this should have gone to the new mailing list. Maybe.
> ]
>
> As some of you maybe know from my earlier posts, I am building a simple
> search engine for R packages. Now the search engine has a proper web site,
> where you can also browse CRAN packages.
>
> http://www.r-pkg.org/
>
> As I see the value is in
> 1. package search (search box on top right)
> 2. APIs, see http://www.r-pkg.org/services
>
> It is in alpha version, meaning that things seem to work, some pages are a
> bit slow and there are a lot of glitches to fix.
>
> Please tell me what you think.
>
> Best,
> Gabor
>
> [[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

[Rd] parallel::mclapply() dummy function on Windows?

[Tim Triche, Jr.]

Hi all,

Would it be possible to have the new 'parallel' library export a dummy
function, something akin to

if(Windows) mclapply <- lapply

to paper over the lack of fork() support on said platform?  This may not be
the world's greatest idea, but it would make it easier for me to maintain my
package and still offer most users good parallel support.  Plus, I can't
really see where it would cause problems, but then I don't develop R,
myself.

Thanks for any thoughts on the matter.


-- 
If people do not believe that mathematics is simple,
it is only because they do not realize how complicated life is. John von
Neumann

[[alternative HTML version deleted]]

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

Re: [Rd] parallel::mclapply() dummy function on Windows?

[Tim Triche, Jr.]

On Thu, Oct 6, 2011 at 11:25 PM, Prof Brian Ripley wrote:

>
> Why would it make it easier?  And how could using a dummy for 'most users'
> (who are on Windows) offer them 'good parallel support'?


Good point.  Most of my users are on unix, because my use of mclapply() is
primarily to expedite processing of raw scanner data.  Only a handful of
users for the packages that call mclapply() are on Windows.  Right now, I
default to having parallel=FALSE flags all over the place, but I'd prefer
for the default to be "go as fast as practical in the common case", i.e.,
Unix.  It would have been more accurate for me to say "I would like to
parallelize by default, without having the methods fail on Windows in the
default configuration" than to claim that I want "good parallel support" for
Windows.  When I have tried using the foreach/doMC combination in the past,
it has not worked out satisfactorily, so I don't know how well I can support
Windows users... period.

Take a look at e.g. package 'boot' to see how to offer alternatives. (A
> version that uses 'parallel' is pending on CRAN, or see
> http://www.stats.ox.ac.uk/pub/**R/boot_1.3-3.tar.gz<http://www.stats.ox.ac.uk/pub/R/boot_1.3-3.tar.gz>.)
>  Package 'parallel' may in future offer a higher-level abstraction layer
> that makes offers such a choice, but as the 'boot' code shows, deciding what
> to send to the workers in a snow-style cluster is not simple.
>

It seems similar to what I do (off topic: why do you use the file extension
'.q' for all of the R/S code files?): pass flags around.  I suppose I was
just being lazy, but I would love to default to "go as fast as possible"
without having Windows users get left out in the cold (unless they add flags
to their function calls).

Thank you for your suggestions, I will look into this further.

--
Tim Triche, Jr.
USC Biostatistics

[[alternative HTML version deleted]]

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

Re: [Rd] Beta binomial and Beta negative binomial

[Tim Triche, Jr.]

use the gsl package for Kummer's hypergeometric and others.

you might find implementing the distributions in C or C++ worthwhile for
speed.

thanks for doing this, by the way.



On Sat, Mar 17, 2012 at 11:38 AM, Joan Maspons wrote:

> Hello,
>
>
> El 16 de març de 2012 20:34, Christophe Dutang  ha
> escrit:
> > Hi,
> >
> > Please look at the distribution task view (
> http://cran.r-project.org/web/views/Distributions.html) and the package
> gamlss.dist.
>
> Thanks for the tip. There are Beta binomial functions but they don't
> have the number of trials parameter so I supose it's a Beta Bernoulli
> distribution.
>
> >
> > Regards
> >
> > Christophe
> >
> > --
> > Christophe Dutang
> > Ph.D. student at ISFA, Lyon, France
> > website: http://dutangc.free.fr
> >
> > Le 16 mars 2012 à 18:41, Joan Maspons a écrit :
> >
> >> Hi,
> >> I need Beta binomial and Beta negative binomial functions ...
> >>
> >> Can I implement these new functions inside stats
> >> package following the
> >> same patterns as other probability distributions?
> >>
> >> Yours,
> >> --
> >> Joan Maspons
>
> I have implemented a prototype of the beta negative binomial:
>
> FindParamBetaDist<- function(mu, sigma){ #
> return(data.frame(a=shape1,b=shape2))
> # mu<- a/(a+b)  [mean]
> # sigma<- ab/((a+b)^2 (a+b+1))  [variance]
> # Maxima: solve([mu= a/(a+b) , sigma= a*b/((a+b)^2 * (a+b+1))], [a,b]);
>  a<-  -(mu * sigma + mu^3 - mu^2) / sigma
>  b<- ((mu-1) * sigma + mu^3 - 2 * mu^2 + mu) / sigma
>  if (a <= 0 | b <= 0) return (NA)
>  return (data.frame(a,b))
> }
>
> #Rmpfr::pochMpfr()?
> pochhammer<- function (x, n){
>return (gamma(x+n)/gamma(x))
> }
>
> # PMF:
> # P (X = x) = ((alpha)_n (n)_x (beta)_x)/(x! (alpha+beta)_n
> (n+alpha+beta)_x) |  for  | x>=0
> # (a)_b Pochhammer symbol
> dbetanbinom<- function(x, size, mu, sigma){
>param<- FindParamBetaDist(mu, sigma)
>if (is.na(sum(param))) return (NA) #invalid Beta parameters
>if (length(which(x<0))) res<- 0
>else
>res<- (pochhammer(param$a, size) * pochhammer(size, x) *
> pochhammer(param$b, x)
>/ (factorial(x) * pochhammer(param$a + param$b, size)
>* pochhammer(size + param$a + param$b, x)))
>return (res)
> }
>
> curve(dbetanbinom(x, size=12, mu=0.75, sigma=.1), from=0, to=24, n=25,
> type="p")
>
> # CDF:
> # P (X<=x) = 1-(Gamma(n+floor(x)+1) beta(n+alpha, beta+floor(x)+1)
> #genhypergeo(1, n+floor(x)+1, beta+floor(x)+1;floor(x)+2,
> n+alpha+beta+floor(x)+1;1))
> #/(Gamma(n) beta(alpha, beta) Gamma(floor(x)+2)) |  for  | x>=0
> pbetanbinom<- function(q, size, mu, sigma){
>require(hypergeo)
>param<- FindParamBetaDist(mu, sigma)
>if (is.na(sum(param))) return (NA) #invalid Beta parameters
>res<- numeric(length(q))
>for (i in 1:length(q)){
>if (q[i]<0) res[i]<- 0
>else res[i]<- (1-(gamma(size+floor(q[i])+1) *
> beta(size+param$a, param$b+floor(q[i])+1)
>* genhypergeo(c(1, 1+size+floor(q[i]), 1+param$b+floor(q[i])),
> c(2+floor(q[i]),1+size+param$a+param$b+floor(q[i])), 1))
>/ (beta(param$a, param$b) * gamma(size) * gamma(2+floor(q[i]
>}
>return (res)
> }
>
> ## genhypergeo not converge. Increase iterations or tolerance?
> pbetanbinom(0:10x, size=20, mu=0.75, sigma=0.03)
>
> I have to investigate
> http://mathworld.wolfram.com/GeneralizedHypergeometricFunction.html
> Any tip on how to solve the problem?
>
>
> --
> Joan Maspons
> CREAF (Centre de Recerca Ecològica i Aplicacions Forestals)
> Universitat Autònoma de Barcelona, 08193 Bellaterra (Barcelona), Catalonia
> Tel +34 93 581 2915j.masp...@creaf.uab.cat
> http://www.creaf.uab.cat
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] drawing the graph with many nodes

[Tim Triche, Jr.]

there's also Rgraphviz, although with 30,000+ edges it may not survive
*this* graph :-)


On Tue, Mar 27, 2012 at 4:11 AM, Whit Armstrong wrote:

> if you don't mind going outside of R to create it, then check out
> Graphviz: http://www.graphviz.org/Gallery.php
>
> you may have to reformat your data a little, but this tool is great
> for drawing graphs.
>
> -Whit
>
>
> On Tue, Mar 27, 2012 at 5:14 AM, MSousa  wrote:
> > Good morning,
> >
> >
> > I'm trying to draw a graph, and I'm using the following code.
> >
> > test.matrix<-read.table("~/Desktop/Results/testgephi.csv", header = T,
> > sep=",")
> > colnames(test.matrix) <- gsub("X", "", colnames(test.matrix))
> > #drop first column
> > drops <- c("")
> > test.matrix<-test.matrix[,!(names(test.matrix) %in% drops)]
> > test.matrix
> > test.matrix<-data.matrix(test.matrix)
> > am.graph<-new("graphAM", adjMat=test.matrix, edgemode="directed")
> > am.graph
> > plot(am.graph, attrs = list(node = list(fillcolor = "lightblue"),edge =
> > list(arrowsize=0.5)))
> >
> >
> > The file testgephi.csv is following.
> > "","1","2","3","4","5"
> > "1",393,55,66,44,88
> > "2",44,23,47,57,89
> > "3",57,87,98,456,43
> > "4",77,767,86,32,77
> > "5",43,88,23,76,46
> >
> >  In the example graph of the drawing works well, the problem is when I'm
> > trying to draw the graph from a file wih A graphAM graph with directed
> edges
> > Number of Nodes = 217
> > Number of Edges = 32804
> >
> > is there any package or tool that can draw a structure like this
> >
> >
> >   Thanks
> >
> >
> > --
> > View this message in context:
> http://r.789695.n4.nabble.com/drawing-the-graph-with-many-nodes-tp4508319p4508319.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
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] Patch to add Beta binomial distribution. Mentor needed!

[Tim Triche, Jr.]

it's already in the VGAM package

http://www.stat.auckland.ac.nz/~yee/VGAM/



On Tue, May 22, 2012 at 7:59 AM, Joshua Ulrich wrote:

> On Tue, May 22, 2012 at 8:27 AM, Joan Maspons 
> wrote:
> > Hello,
> >
> > 2012/5/22 Christophe Dutang 
> >
> >> Dear Joan,
> >>
> 
> >> If you want to contribute to R, you should write a package and submit it
> >> to CRAN. See http://cran.r-project.org/doc/manuals/R-exts.html
> >>
> >
> > It's necessary to develop a package before to add the functions to
> R-base?
> > I just want to add beta binomial and beta negative binomial distributions
> > which from my point of view are not more strange than distributions
> > included in R-base. I think they are quite common in order to simulate a
> > binomial or negative binomial process in an stochastic environment.
> >
> In order to add functions to the main R distribution, you have to
> convince someone on R-core to maintain the code.
>
> > In the other hand I have no experience in writing packages so it would
> take
> > me more time.
> >
> The actuar package contains many additional distributions.  You might
> see if the maintainer(s) would be interested in incorporating your
> code (if they don't have that functionality already).
>
> > Yours,
> > Joan
> >
> > Regards
> >>
> >> Christophe
> >>
> >> --
> >> Christophe Dutang
> >> Ph.D. student at ISFA, Lyon, France
> >> website: http://dutangc.free.fr
> >>
> >> Le 22 mai 2012 à 12:14, Joan Maspons a écrit :
> >>
> >> > Hello,
> >> >
> >> > I implemented the Beta binomial distribution following the patterns of
> >> the
> >> > binomial distribution code and inspired by JAGS' code [1]. I have
> studied
> >> > the code carefully but it's my first run in the R internals.
> >> >
> >> > Can somebody review the code and if everything it's ok commit to the
> >> > repository?
> >> >
> >> > [1]
> >> >
> >>
> http://mcmc-jags.hg.sourceforge.net/hgweb/mcmc-jags/mcmc-jags/file/15af65a4be29/src/modules/bugs/distributions/DBetaBin.cc
> >> >
> >> >
> >> > --
> >> > Joan Maspons
> >> > CREAF (Centre de Recerca Ecològica i Aplicacions Forestals)
> >> > Universitat Autònoma de Barcelona, 08193 Bellaterra (Barcelona),
> >> Catalonia
> >> > Tel +34 93 581 2915j.masp...@creaf.uab.cat
> >> > http://www.creaf.uab.cat
> >> > __
> >> > R-devel@r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >
> >
> > --
> > Joan Maspons
> > CREAF (Centre de Recerca Ecològica i Aplicacions Forestals)
> > Universitat Autònoma de Barcelona, 08193 Bellaterra (Barcelona),
> Catalonia
> > Tel +34 93 581 2915j.masp...@creaf.uab.cat
> > http://www.creaf.uab.cat
> >
> >[[alternative HTML version deleted]]
> >
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] Patch to add Beta binomial distribution. Mentor needed!

[Tim Triche, Jr.]

It's in VGAM, remember?  Not a bug.



On Fri, Jun 1, 2012 at 10:38 AM, Joan Maspons wrote:

> Hi,
> I filled a bug [1] and I tried to build a package without success. If there
> are no news in a while I'll try some to convince some package developers to
> add this distribution
>
> [1] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14936
>
> Thanks for the feedback,
> Joan
>
> 2012/5/22 Ben Bolker 
>
> >
> > [various snippage]
> >
> > also see
> >
> > library("sos")
> > findFn("dbetabin*")
> >
> > and
> >
> > http://stackoverflow.com/questions/8065835/
> >   proposing-feature-requests-to-the-r-core-team/8066062#8066062
> > [url broken]
> >
> >  for some context on why you should build a package instead
> > of trying to get a patch accepted in base R ...
> >
> >  Ben Bolker
> >
> >
> > > > On Tue, May 22, 2012 at 8:27 AM, Joan Maspons
> > > > wrote:
> > > > > Hello,
> > > > >
> > > > > 2012/5/22 Christophe Dutang  gmail.com>
> > > > >
> > > > >> Dear Joan,
> > > > >>
> > > > 
> > > > >> If you want to contribute to R, you should write a package and
> > submit it
> > > > >> to CRAN. See http://cran.r-project.org/doc/manuals/R-exts.html
> > > > >>
> > > > >
> > > > > It's necessary to develop a package before to add the functions to
> > > > R-base?
> > > > > I just want to add beta binomial and beta negative binomial
> > distributions
> > > > > which from my point of view are not more strange than distributions
> > > > > included in R-base. I think they are quite common in order to
> > simulate a
> > > > > binomial or negative binomial process in an stochastic environment.
> > > > >
> > > > In order to add functions to the main R distribution, you have to
> > > > convince someone on R-core to maintain the code.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
>
> --
> Joan Maspons
> CREAF (Centre de Recerca Ecològica i Aplicacions Forestals)
> Universitat Autònoma de Barcelona, 08193 Bellaterra (Barcelona), Catalonia
> Tel +34 93 581 2915j.masp...@creaf.uab.cat
> http://www.creaf.uab.cat
>
> [[alternative HTML version deleted]]
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] Bounty on Error Checking

[Tim Triche, Jr.]

Here is a JIT suggestion:  add the message to errors/coredump reports

"If you would like to submit a patch for this error, please contact r-devel@
r-project.org for further instructions.
 If you cannot, or would prefer not to, fix this error yourself, please
consider donating $20 to the Fix My Bug (R) fund.

patch:   ;-)

if(R_Interactive) {
  REprintf("\nPossible actions:\n1: %s\n2: %s\n3: %s\n4: %s\n5: %s\n",
 "abort (with core dump, if enabled)",
 "normal R exit",
 "exit R without saving workspace",
 "exit R saving workspace",
>   "donate $20"
);



--t


nb.  if I am not mistaken, Dr. Gentleman is fairly busy these days at
Genentech, sequencing anything he/they can get his/their hands on
Prof. Ripley might be a more sensible choice for these sorts of suggestions
if you are going to cc: people besides the r-devel list
if there is history between you and Dr. Gentleman then by all means please
ignore whatever irrelevant crap I typed above


On Thu, Jan 3, 2013 at 10:00 AM, ivo welch wrote:

> r




-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] Incorporating single functions from other packages: rules and regulations?

[Tim Triche, Jr.]

 a n00b question:

if I call importFrom(IRanges, ranges) in my NAMESPACE file, that works
great.
but if  I call

R> importFrom(IRanges, ranges)
## Error: could not find function "importFrom"

well, that doesn't work great.  The closest thing I can find in base is

base:::importIntoEnv

which helpfully informs me that it is one of several

Internal namespace support functions.  Not intended to be called directly.


Where's the best place to learn about how namespaces and import/export
facilities (particularly in R-3.0) are implemented?

thanks,

--t




On Sun, Jan 13, 2013 at 7:05 AM, Dirk Eddelbuettel  wrote:

>
> On 13 January 2013 at 11:16, Johannes Graumann wrote:
> | In a little pkg I'm developing I am in need of the functionality
> provided by
> | plotrix::listDepth.
> |
> | I am loath of having the depend on and import the whole package just for
> | that purpose.
>
> Step back and realize that your total R installation (including all
> packages)
> is already much bigger than the single package. And derives value from all
> those packages.
>
> So I would use importForm(plotrix, listDepth) in my package's NAMESPACE,
> and
> add the Imports: in the DESCRIPTION.
>
> IMHO that is the right way to do it rather than creating _stale_ and (even
> worse) _disconnected_ copies which will never receive updates or fixes from
> the _original author_ of that code.
>
> Dirk
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

[Rd] slotName defined in object, present in instance, but inaccessible

[Tim Triche, Jr.]

from a package I'm writing

##setClass('Occupancy',contains="DataFrame",
## representation(states="StatesORNULL"))
##
R> foo <- occupancy(pooledMethSegs)
R> plotOccupancy(foo)
Error in slot(object, "states") :
  no slot of name "states" for this object of class "Occupancy"
R> slotNames(foo)
[1] "states"  "rownames""nrows"   "listData"
[5] "elementType" "elementMetadata" "metadata"
R> foo@states
Error: no slot of name "states" for this object of class "Occupancy"


Any ideas as to what's going on here?


R> sessionInfo()
R Under development (unstable) (2013-01-29 r61783)
Platform: x86_64-unknown-linux-gnu (64-bit)

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

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

other attached packages:
 [1] rtracklayer_1.19.9chromophobe_0.49  pheatmap_0.7.4
 [4] ggplot2_0.9.3 reshape2_1.2.2GenomicRanges_1.11.28
 [7] IRanges_1.17.31   BiocGenerics_0.5.6BiocInstaller_1.9.6
[10] gtools_2.7.0  devtools_1.0

loaded via a namespace (and not attached):
 [1] Biostrings_2.27.10 bitops_1.0-5   BSgenome_1.27.1
 colorspace_1.2-1
 [5] dichromat_2.0-0digest_0.6.2   evaluate_0.4.3 gtable_0.1.2

 [9] httr_0.2   labeling_0.1   lattice_0.20-13MASS_7.3-23

[13] Matrix_1.0-10  memoise_0.1munsell_0.4plyr_1.8

[17] proto_0.3-10   RColorBrewer_1.0-5 RCurl_1.95-3
Rsamtools_1.11.15
[21] scales_0.2.3   stats4_3.0.0   stringr_0.6.2  tools_3.0.0

[25] whisker_0.1XML_3.95-0.1   zlibbioc_1.5.0

[[alternative HTML version deleted]]

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

Re: [Rd] Regression stars

[Tim Triche, Jr.]

Changing the default for show.signif.stars should be sufficient to ensure
that, if people are going to get themselves into trouble, they will have to
do it on purpose.  It's just a visual cue; removing it will not remove the
underlying issue, namely blind acceptance of unlikely null models and
distributions.

For any complex problem, there is a solution that is simple, elegant, and
wrong.  As grants and careers can depend on these magic numbers, Upton
Sinclair might save everyone some trouble... It is difficult to get a man
to understand something, when his salary depends upon his not
understanding.

stringsAsFactors, however, is responsible for an endless stream of mildly
irritating misunderstandings, and defaulting that to FALSE would be very
nice.

Just my $0.02.  Defaults are one of the most powerful forces in the
universe.

Also, I liked your book.



On Sat, Feb 9, 2013 at 10:48 AM, Norm Matloff wrote:

> Thanks for bringing this up, Frank.
>
> Since many of us are "educators," I'd like to suggest a bolder approach.
> Discontinue even offering the stars as an option.  Sadly, we can't stop
> reporting p-values, as the world expects them, but does R need to cater
> to that attitude by offering star display?  For that matter, why not
> have R report confidence intervals as a default?
>
> Many years ago, I wrote a short textbook on stat, and included a
> substantial section on the dangers of significance testing.  All three
> internal reviewers liked it, but the funny part is that all three said,
> "I agree with this, but no one else will." :-)
>
> Norm
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] Regression stars

[Tim Triche, Jr.]

To clarify, I favor changing the defaults for stringsAsFactors and
show.signif.stars to FALSE in R-3.0.0, and view any attempt to remove
either functionality as a seemingly simple but fundamentally misguided idea.

This is just my opinion, of course.  The change could easily be accompanied
by a startup notice or release notes indicating that the changes have been
made, and can be reverted to past behavior if the user so desires.  Perhaps
more users will investigate the various settings, as a happy side effect.

My thanks to everyone who spends time supporting and working on R-core.



On Sat, Feb 9, 2013 at 12:44 PM, Tim Triche, Jr. wrote:

> Changing the default for show.signif.stars should be sufficient to ensure
> that, if people are going to get themselves into trouble, they will have to
> do it on purpose.  It's just a visual cue; removing it will not remove the
> underlying issue, namely blind acceptance of unlikely null models and
> distributions.
>
> For any complex problem, there is a solution that is simple, elegant, and
> wrong.  As grants and careers can depend on these magic numbers, Upton
> Sinclair might save everyone some trouble... It is difficult to get a man
> to understand something, when his salary depends upon his not
> understanding.
>
> stringsAsFactors, however, is responsible for an endless stream of mildly
> irritating misunderstandings, and defaulting that to FALSE would be very
> nice.
>
> Just my $0.02.  Defaults are one of the most powerful forces in the
> universe.
>
> Also, I liked your book.
>
>
>
> On Sat, Feb 9, 2013 at 10:48 AM, Norm Matloff wrote:
>
>> Thanks for bringing this up, Frank.
>>
>> Since many of us are "educators," I'd like to suggest a bolder approach.
>> Discontinue even offering the stars as an option.  Sadly, we can't stop
>> reporting p-values, as the world expects them, but does R need to cater
>> to that attitude by offering star display?  For that matter, why not
>> have R report confidence intervals as a default?
>>
>> Many years ago, I wrote a short textbook on stat, and included a
>> substantial section on the dangers of significance testing.  All three
>> internal reviewers liked it, but the funny part is that all three said,
>> "I agree with this, but no one else will." :-)
>>
>> Norm
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> *A model is a lie that helps you see the truth.*
> *
> *
> Howard Skipper<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>

[[alternative HTML version deleted]]

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

Re: [Rd] Regression stars

[Tim Triche, Jr.]

I think it may have been John D. Cook who first observed that p-values are
linearly correlated with the amount of time remaining on a grant.

Perhaps a suitable transform would reveal an ordinal relationship with
stars.



On Tue, Feb 12, 2013 at 7:03 AM, Ravi Varadhan wrote:

> They are "reaching for the stars".  Pardon my jest, but I couldn't resist.
>
> Ravi
>
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
> On Behalf Of Uwe Ligges
> Sent: Tuesday, February 12, 2013 10:01 AM
> To: Frank Harrell
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Regression stars
>
>
>
> On 12.02.2013 15:42, Frank Harrell wrote:
> > Uwe I've been consulting for decades and have never once been asked
> > for such stars.
>
> Honestly: last time I have been asked last week.
>
> And when I answered (in another case few months ago) "OK, I can add you
> another 5 stars for p values smaller than 0.5" they did not find it too
> funny.
>
> Best,
> Uwe
>
> > And when a clinical researcher puts a sentence in a study protocol
> > that P<0.05 will be considered "significant" I get them to take it out.
> >
> > Frank
> >
> > Uwe Ligges-3 wrote
> >> On 12.02.2013 14:54, Ben Bolker wrote:
> >>> Duncan Murdoch
> >> 
> >>   gmail.com> writes:
> >>>
> >>> [snip]
> 
>  Regarding stringsAsFactors:  I'm not going to defend keeping it as
>  is, I'll let the people who like it defend it.
> >>>
> >>> Would someone (anyone) like to come forward and give us a
> >>> defense of stringsAsFactors=TRUE -- even someone who doesn't
> >>> personally like it but would like to play devil's advocate?
> >>
> >> Sure:
> >> I will have to change all my scripts, my teaching examples, my book,
> >> and lots of code examples for research and particularly consulting jobs.
> >>
> >> Personally, I think having stringsAsFactors=TRUE is not too bad for
> >> read.table() but less useful for data.frame().
> >>
> >> And since you ask for the devil's advocate already, related to the
> >> subject line: Removing stars is horrible for consulting: With all
> >> those people from biology, medicine and other fields who even ask us
> >> questions in term of significance stars that are obviously very common
> for them.
> >> Many of them will certainly ask us for the stars, and ask us to
> >> switch to another software product once they do not get it from R.
> >> They may not be interested in being taught about the advantages or
> >> disadvantages of p-values or stars.
> >>
> >> There are different use cases of R, and I want to keep stars for
> >> consulting tasks where things have to be delivered within minutes. I
> >> am happy with or without for teaching, where I have the time and can
> >> easily talk about the sense and nonsense of p-values.
> >>
> >>
> >> Best,
> >> Uwe
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
>  What I will likely do is
>  make a few changes so that character vectors are automatically
>  changed to factors in modelling functions, so that operating with
>  stringsAsFactors=FALSE doesn't trigger silly warnings.
> 
>  Duncan Murdoch
> 
> >>>
> >>>[apologies for snipping context: "gmane made me do it"]
> >>>
> >>> __
> >>>
> >
> >> R-devel@
> >
> >>   mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>
> >> __
> >
> >> R-devel@
> >
> >>   mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> >
> >
> >
> > -
> > Frank Harrell
> > Department of Biostatistics, Vanderbilt University
> > --
> > View this message in context:
> > http://r.789695.n4.nabble.com/Regression-stars-tp4657795p4658268.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
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] [BioC] enabling reproducible research & R package management & install.package.version & BiocLite

[Tim Triche, Jr.]

seen QuasR (and/or gmapR, Rsubread, etc.)?  one can run BowTie, gsnap, etc.
from R

this certainly makes it easier for me to remember how I did some ChIP-seq
or BS-seq or RNA-seq processing a year ago, when it turns out I need to add
a sample or samples and carry on with an existing analysis pipeline




On Wed, Mar 6, 2013 at 10:17 AM, Cook, Malcolm  wrote:

> Thanks David, I've looked into them both a bit, and I don't think the
> provide an approach for R (or Perl, for that matter) library management,
> which is the wicket I'm trying to get less sticky now.
>
> They could be useful to manage the various installations of version of R
> and analysis files (we're talking allot of NextGenSequencing, so, bowtie,
> tophat, and friends) quite nicely similarly in service of an approach to
> enabling reproducible results.
>
> THanks for you thoughts, and, if you know of others similar to
> dotkit/modules I'd be keen to here of them.
>
> ~Malcolm
>
>
>  .-Original Message-
>  .From: Lapointe, David [mailto:david.lapoi...@umassmed.edu]
>  .Sent: Wednesday, March 06, 2013 7:46 AM
>  .To: Cook, Malcolm; 'Paul Gilbert'
>  .Cc: 'r-devel@r-project.org'; 'bioconduc...@r-project.org'; '
> r-discuss...@listserv.stowers.org'
>  .Subject: RE: [BioC] [Rd] enabling reproducible research & R package
> management & install.package.version & BiocLite
>  .
>  .There are utilities ( e.g. dotkit, and modules) which facilitate version
> management, basically creating on the fly PATH and env setups, if
>  .you are comfortable keeping all that around.
>  .
>  .David
>  .
>  .-Original Message-
>  .From: bioconductor-boun...@r-project.org [mailto:
> bioconductor-boun...@r-project.org] On Behalf Of Cook, Malcolm
>  .Sent: Tuesday, March 05, 2013 6:08 PM
>  .To: 'Paul Gilbert'
>  .Cc: 'r-devel@r-project.org'; 'bioconduc...@r-project.org'; '
> r-discuss...@listserv.stowers.org'
>  .Subject: Re: [BioC] [Rd] enabling reproducible research & R package
> management & install.package.version & BiocLite
>  .
>  .Paul,
>  .
>  .I think your balanced and reasoned approach addresses all my current
> concerns.  Nice!  I will likely adopt your methods.  Let me
>  .ruminate.  Thanks for this.
>  .
>  .~ Malcolm
>  .
>  . .-Original Message-
>  . .From: Paul Gilbert [mailto:pgilbert...@gmail.com]
>  . .Sent: Tuesday, March 05, 2013 4:34 PM
>  . .To: Cook, Malcolm
>  . .Cc: 'r-devel@r-project.org'; 'bioconduc...@r-project.org'; '
> r-discuss...@listserv.stowers.org'
>  . .Subject: Re: [Rd] [BioC] enabling reproducible research & R package
> management & install.package.version & BiocLite  .
>  . .(More on the original question further below.)  .
>  . .On 13-03-05 09:48 AM, Cook, Malcolm wrote:
>  . .> All,
>  . .>
>  . .> What got me started on this line of inquiry was my attempt at  .>
> balancing the advantages of performing a periodic (daily or
>  .weekly)  .> update to the 'release' version of locally installed
> R/Bioconductor  .> packages on our institute-wide installation of R with
>  .the  .> disadvantages of potentially changing the result of an analyst's
>  .> workflow in mid-project.
>  . .
>  . .I have implemented a strategy to try to address this as follows:
>  . .
>  . .1/ Install a new version of R when it is released, and packages in the
> R  .version's site-library with package versions as available at the
>  .time  .the R version is installed. Only upgrade these package versions
> in the  .case they are severely broken.
>  . .
>  . .2/ Install the same packages in site-library-fresh and upgrade these
>  .package versions on a regular basis (e.g. daily).
>  . .
>  . .3/ When a new version of R is released, freeze but do not remove the
> old  .R version, at least not for a fairly long time, and freeze
>  ..site-library-fresh for the old version. Begin with the new version as
> in  .1/ and 2/. The old version remains available, so "reverting" is
>  .trivial.
>  . .
>  . .
>  . .The analysts are then responsible for choosing the R version they use,
>  .and the library they use. This means they do not have to
>  .change R and  .package version mid-project, but they can if they wish. I
> think the  .above two libraries will cover most cases, but it is
>  .possible that a few  .projects will need their own special library with
> a combination of  .package versions. In this case the user could
>  .create their own library,  .or you might prefer some more official
> mechanism.
>  . .
>  . .The idea of the above strategy is to provide the stability one might
>  .want for an ongoing project, and the possibility of an upgraded
>  .package  .if necessary, but not encourage analysts to remain
> indefinitely with old  .versions (by say, putting new packages in an old R
>  .version library).
>  . .
>  . .This strategy has been implemented in a set of make files in the
> project  .RoboAdmin available at http://automater.r-forge.r-
>  .project.org/. It can  .be done entirely automatically with a cron job.
> Constructive comments 

Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)

[Tim Triche, Jr.]

+1 to having runnable code emitted

patch seems to work nicely, hopefully R-core will agree to apply it to HEAD



On Wed, May 1, 2013 at 9:45 AM, Paul Johnson  wrote:

> Whoa.
>
> Don't let my valuable suggestion get lost.
>
>  I want "} else {".  Yihue wants "} else {".  And I have not heard anybody
> say they prefer the other way, unless you interpret Duncan's comment
> "that's nonsense" as a blanket defense of the status quo. But I don't think
> he meant that.  This is a matter of style consistency and avoidance of new
> R-user confusion and error.
>
> After reading the help for "if", I don't see how anybody can argue against
> this.  Good R code has this style:
>
> } else {
>
> and not
>
> }
>  else
>
> because the latter fails if it is run line-by-line.  While trying to teach
> people how to write R programs, it would be nice if the output of
> print.function was consistent with the good way, the way that is actually
> practiced in the R source code itself. This is a major source of new
> programmer confusion. Its very tough to explain and teach.
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science  Assoc. Director
> 1541 Lilac Lane, Room 504  Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org   http://quant.ku.edu
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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

Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)

[Tim Triche, Jr.]

What harm comes of having the code be cut-and-paste-able?

I do not mean to be contrary but a downside to applying the patch seems to
be lacking.
Perhaps I am missing something obvious and if so I beg your pardon for
wasting your time.

Thanks,

--t



On Wed, May 1, 2013 at 12:19 PM, Duncan Murdoch wrote:

> On 01/05/2013 1:34 PM, Tim Triche, Jr. wrote:
>
>> +1 to having runnable code emitted
>>
>
> It does emit runnable code, which is why Herve's complaint was nonsense.
>  It doesn't emit code of which every substring is runnable.
>
> Duncan Murdoch
>
>
>
>> patch seems to work nicely, hopefully R-core will agree to apply it to
>> HEAD
>>
>>
>>
>> On Wed, May 1, 2013 at 9:45 AM, Paul Johnson 
>> wrote:
>>
>> > Whoa.
>> >
>> > Don't let my valuable suggestion get lost.
>> >
>> >  I want "} else {".  Yihue wants "} else {".  And I have not heard
>> anybody
>> > say they prefer the other way, unless you interpret Duncan's comment
>> > "that's nonsense" as a blanket defense of the status quo. But I don't
>> think
>> > he meant that.  This is a matter of style consistency and avoidance of
>> new
>> > R-user confusion and error.
>> >
>> > After reading the help for "if", I don't see how anybody can argue
>> against
>> > this.  Good R code has this style:
>> >
>> > } else {
>> >
>> > and not
>> >
>> > }
>> >  else
>> >
>> > because the latter fails if it is run line-by-line.  While trying to
>> teach
>> > people how to write R programs, it would be nice if the output of
>> > print.function was consistent with the good way, the way that is
>> actually
>> > practiced in the R source code itself. This is a major source of new
>> > programmer confusion. Its very tough to explain and teach.
>> >
>> > pj
>> > --
>> > Paul E. Johnson
>> > Professor, Political Science  Assoc. Director
>> > 1541 Lilac Lane, Room 504  Center for Research Methods
>> > University of Kansas University of Kansas
>> > http://pj.freefaculty.org   http://quant.ku.edu
>> >
>> > [[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>
>> >
>>
>>
>>
>>
>


-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>

[[alternative HTML version deleted]]

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

Re: [Rd] locking down R

[Tim Triche, Jr.]

short of running everything in a VM, I'd have to guess you're hosed...  I
don't understand how an operating system with internals as opaque as
Windows (NT/2000/beyond, not just the old DOS-based garbage) could ever be
considered secure for intensive computation, but that seems beside the
point.  You could perhaps recompile R, leaving out the bits offensive to
management, and use that... ?

If they will let you run in a VM, on the other hand, RAppArmor could
satisfy most of these demands in a hurry.



On Mon, May 20, 2013 at 8:12 AM, Ben Bolker  wrote:

> On 13-05-19 06:08 PM, R. Michael Weylandt wrote:
> > On Sun, May 19, 2013 at 7:16 PM, Ben Bolker  wrote:
> >>
> >>   Is anyone on this list aware of discussions about locking
> down/securing R?
> >>
> >>   My colleagues and I are working with health statistics in an office
> >> that disallows many useful tools (e.g. emacs, vim, perl, make) on the
> >> grounds that they represent a security risk.  We are considering pushing
> >> back, but we are worried that if we attract the attention of the Powers
> >> That Be to the reality that R allows execution of arbitrary shell
> >> commands, they will then disallow the use of R (SAS and Stata are our
> >> other optiona). It might be useful to be able to give them options for
> >> securing R.
> >>
> >>   Possibly useful information:
> >>
> >> * the office allows use of SAS (and Stata, MLWiN, etc.) but uses the
> >> NOXCMD specification to prevent shell access from within SAS. They also
> >> disallow access to the Windows shell (in the current configuration,
> >> shell() works fine from within R, but we think this may have escaped
> >> their notice ...) The workstations have no access to external networks,
> >> nor to external media (thumb drives etc.) [information transfer to the
> >> outside world is via shared drives that can be accessed by
> >> administrators with network access].
> >>
> >> * I stipulate that (1) the security policies don't make sense, (2)
> >> allowing users access to arbitrary shell commands should _not_ represent
> >> a security risk on a well-administered, modern operating system (they're
> >> running WinXP), (3) R probably offers many other avenues for system
> >> access to a malicious user, even in the absence of shell access,
> >> compilers, etc..
> >
> > If you really mean a "modern operating system"... ;-)
> >
> > http://arxiv.org/abs/1303.4808
> >
> > Cheers,
> > MW
>
>   Interesting, of course, but WinXP is the target OS (unless your point
> is that people are worrying about this even on Linux).  (Another point
> not mentioned previously is that users have to sign a fairly serious
> confidentiality oath to get access to this system in the first place,
> which presumably includes an implied "I won't hack the system" clause ...)
>
>   RAppArmor is an interesting idea, as is sandboxR (mentioned in the
> paper); I also looked up Sandboxie (a Windows program for sandboxing).
> I don't think any of these will really solve the problem, though ...
>
>  thanks
>Ben Bolker
>
> >
> >>
> >> * I suspect the answer given here will be "if you really want to secure
> >> R, run it within a standard restricted-access shell (e.g. chroot on a
> >> Linux system)".  If anyone has experience of 'locking down' R on Windows
> >> (XP) in a sensitive environment, I'd be curious about the details.
> >>
> >>  thanks
> >>   Ben Bolker
> >>
> >> __
> >> 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
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

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