Re: [Bioc-devel] saturday build

2016-08-31 Thread Hervé Pagès 

moscato1 became unstable again. I rebooted it this evening and
hopefully we'll have a build report on Friday. Sorry for the
inconvenience...

H.

On 08/31/2016 07:39 PM, Kasper Daniel Hansen wrote:

No build monday either it seems like?

On Tue, Aug 23, 2016 at 6:45 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:


On 08/22/2016 09:01 PM, Kasper Daniel Hansen wrote:


Did the Saturday build not get started.  I have updated the experimental
data package, minfiData, and that was re-build on Saturday.  But minfi,
which has failed in level for some time due to minfiData, has not been
rebuild since last Wednesday.

Or is there some issue here that minfi does not get build again because it
failed and I have not pushed any updates to the package itself, only to
its
dependencies?



The Saturday builds failed to propagate, and I failed to catch this
yesterday. The culprit seems to be extremely slow windows builds. Martin



Best,
Kasper

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or confidential
information.  If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited.  If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] saturday build

2016-08-31 Thread Kasper Daniel Hansen 
No build monday either it seems like?

On Tue, Aug 23, 2016 at 6:45 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 08/22/2016 09:01 PM, Kasper Daniel Hansen wrote:
>
>> Did the Saturday build not get started.  I have updated the experimental
>> data package, minfiData, and that was re-build on Saturday.  But minfi,
>> which has failed in level for some time due to minfiData, has not been
>> rebuild since last Wednesday.
>>
>> Or is there some issue here that minfi does not get build again because it
>> failed and I have not pushed any updates to the package itself, only to
>> its
>> dependencies?
>>
>
> The Saturday builds failed to propagate, and I failed to catch this
> yesterday. The culprit seems to be extremely slow windows builds. Martin
>
>
>> Best,
>> Kasper
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] A bug in the R Mersenne Twister (RNG) code?

2016-08-31 Thread Paul Gilbert 



On 08/30/2016 06:29 PM, Duncan Murdoch wrote:

I don't see evidence of a bug.  There have been several versions of the
MT; we may be using a different version than you are.  Ours is the
1999/10/28 version; the web page you cite uses one from 2002.

Perhaps the newer version fixes some problems, and then it would be
worth considering a change.  But changing the default RNG definitely
introduces problems in reproducibility,


Well "problems in reproducibility" is a bit vague. Results would always 
be reproducible by specifying kind="Mersenne-Twister" or kind="Buggy
Kinderman-Ramage" for older results, so there is no problem reproducing 
results. The only problem is that users expecting to reproduce results 
twenty years later will need to know what random generator they used. 
(BTW, they may also need to record information about the normal or other 
generator, as well as the seed.) Of course, these changes are recorded 
pretty well for R, so the history of "default" can always be found.


I think it is a mistake to encourage users into thinking they do not 
need to keep track of some information if they want reproducibility. 
Perhaps the default should be changed more often in order to encourage 
better user habits.


More seriously, I think "default" should continue to be something that 
is currently considered to be good. So, if there really is a known 
problem, then I think "default" should be changed.


(And, no I did not get burned by the R 1.7.0 change in the default 
generator. I got burned by a much earlier, unadvertised, and more subtle 
change in the Splus generator.)


Paul Gilbert

so it's not obvious that we

would do it.

Duncan Murdoch


On 30/08/2016 5:45 PM, Mark Roberts wrote:

Whomever,

I recently sent the "bug report" below tor-c...@r-project.org and have
just been asked to instead submit it to you.

Although I am basically not an R user, I have installed version 3.3.1
and am also the author of a statistics program written in Visual Basic
that contains a component which correctly implements the Mersenne
Twister (MT) algorithm.  I believe that it is not possible to generate
the correct stream of pseudorandom numbers using the MT default random
number generator in R, and am not the first person to notice this.  Here
is a posted 2013 entry
(www.r-bloggers.com/reproducibility-and-randomness/) on an R website
that asserts that the SAS computer program implementation of the MT
algorithm produces different numbers than R does when using the same
starting seed number.  The author of this post didn’t get anyone to
respond to his query about the reason for this SAS vs. R discrepancy.

There are two ways of initializing the original MT computer program
(written in C) so that an identical stream of numbers can be repeatedly
generated:  1) with a particular integer seed number, and 2) with a
particular array of integers.   In the 'compilation and usage' section
of this webpage (https://github.com/cslarsen/mersenne-twister) there is
a listing of the first 200 random numbers the MT algorithm should
produce for seed number = 1.  The inventors of the Mersenne Twister
random number generator provided two different sets of the first 1000
numbers produced by a correctly coded 32-bit implementation of the MT
algorithm when initializing it with a particular array of integers at:
www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.out.
[There is a link to this output at:
www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html.]

My statistics program obtains exactly those 200 numbers from the first
site mentioned in the previous paragraph and also obtains those same
numbers from the second website (though I didn't check all 2000 values).
   Assuming that the MT code within R uses the 32-bit MT algorithm, I
suspect that the current version of R can't do that.  If you (i.e.,
anyone who might knowledgeably respond to this report) is able to
duplicate those reference test-values, then please send me the R code to
initialize the MT code within R to successfully do that, and I apologize
for having wasted your time. If you (collectively) can't do that, then R
is very likely using incorrectly implemented MT code.  And if this
latter possibility is true, it seems to me that this is something that
should be fixed.

Mark Roberts, Ph.D.

[[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


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

[Bioc-devel] git mirror fails

2016-08-31 Thread Lara Urban 
Dear All,

I hope this is the right platform to post my question: I am currently
trying to update my package on the devel branch. It is available via a
GitHub repo. I followed the instructions (
http://bioconductor.org/developers/how-to/git-mirror/) and can commit/push
to GitHub, but when I switch to the devel branch and want to push again, I
am "unable to access 'https://github.com/Bioconductor-mirror/covRNA.git/': The
requested URL returned error: 403". However, I can access the URL via
browser. Does someone know what is going wring there? Please let me know if
you need further information.

Many thanks in advance.

Kind regards, Lara

-- 
Lara Urban

Predoctoral Fellow
EMBL-European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge
CB10 1SD
United Kingdom

PhD Student
Wolfson College
University of Cambridge

phone:  + 49 (0) 176 76 37 99 03 <%2B%2044%20%280%29%201223%20494%20655>
email: lara.h.ur...@ebi.ac.uk 

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] New strptime conversion specification for ordinal suffixes

2016-08-31 Thread Michael Chirico 
As touched on briefly on SO ,
base R has what appears to me to be a serious deficiency in its inability
to recognize dates formatted as character strings with ordinal suffixes:

ord_dates <- c("September 1st, 2016", "September 2nd, 2016",
   "September 3rd, 2016", "September 4th, 2016")

?strptime lists no conversion specification which could match ord_dates in
one pass (as I discovered, even lubridate only manages to succeed by going
through the vector in several passes).

How difficult would it be to add a new conversion specification which would
handle this, which would seem to me to be a pretty common instance of dates
to be found in the raw data wild?

My suggestion would be %o for ordinal suffixes. These would obviously be
locale-specific, but in English, %o would match to:


   - st
   - nd
   - rd
   - th
   - st
   - nd
   - rd
   - th


Other languages may be covered by this
 and/or this

Wikipedia page on ordinal superscripts & Unicode superscripts, respectively.

With this implemented, converting ord_dates to a Date or POSIXct would be
as simple as:

as.Date(ord_dates, format = "%B %d%o, %Y")

Is there something on the C level preventing this from happening?

Michael Chirico

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Git mirror out of sync

2016-08-31 Thread Angerer, Philipp via Bioc-devel 
hi, it happened 
again:https://github.com/Bioconductor-mirror/destinyout of 
sync… 


Von: "Angerer, Philipp via Bioc-devel"  
An: "Martin Morgan"  
CC: "bioc-devel"  
Gesendet: Donnerstag, 11. August 2016 13:05:58 
Betreff: Re: [Bioc-devel] Git mirror out of sync 

great, thanks! 


Von: "Martin Morgan"  
An: "Angerer, Philipp" , "bioc-devel" 
 
Gesendet: Donnerstag, 11. August 2016 12:54:50 
Betreff: Re: [Bioc-devel] Git mirror out of sync 

On 08/09/2016 04:18 AM, Angerer, Philipp via Bioc-devel wrote: 
> Hi, 
> 
> destiny ’s git mirror has been out of sync for quite some time. 
> 
> The currently latest SVN revision has bumped the version to 1.3.4 , but git 
> master is still on 1.3.0 . 
> 

This should be back on track now, please let us know if problems occur 
again. 

Martin 

> Thanks for looking at it, 
> Philipp 
> 
> 
> 
> 
> Helmholtz Zentrum Muenchen 
> 
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) 
> 
> Ingolstaedter Landstr. 1 
> 
> 85764 Neuherberg 
> 
> www.helmholtz-muenchen.de 
> 
> Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe 
> 
> Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen, Renate 
> Schlusen (komm.) 
> 
> Registergericht: Amtsgericht Muenchen HRB 6466 
> 
> USt-IdNr: DE 129521671 
> 
> 
> [[alternative HTML version deleted]] 
> 
> ___ 
> Bioc-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/bioc-devel 
> 


This email message may contain legally privileged and/or confidential 
information. If you are not the intended recipient(s), or the employee or agent 
responsible for the delivery of this message to the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or use of this 
email message is prohibited. If you have received this message in error, please 
notify the sender immediately by e-mail and delete this email message from your 
computer. Thank you. 




Helmholtz Zentrum Muenchen 

Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) 

Ingolstaedter Landstr. 1 

85764 Neuherberg 

www.helmholtz-muenchen.de 

Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe 

Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen 

Registergericht: Amtsgericht Muenchen HRB 6466 

USt-IdNr: DE 129521671 


[[alternative HTML version deleted]] 

___ 
Bioc-devel@r-project.org mailing list 
https://stat.ethz.ch/mailman/listinfo/bioc-devel 




Helmholtz Zentrum Muenchen

Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)

Ingolstaedter Landstr. 1

85764 Neuherberg

www.helmholtz-muenchen.de

Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe

Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen

Registergericht: Amtsgericht Muenchen HRB 6466

USt-IdNr: DE 129521671


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] 'droplevels' inappropriate change

2016-08-31 Thread Martin Maechler 
> Martin Maechler 
> on Sat, 27 Aug 2016 18:55:37 +0200 writes:

> Suharto Anggono Suharto Anggono via R-devel 
> on Sat, 27 Aug 2016 03:17:32 + writes:

>> In R devel r71157, 'droplevels' documentation, in "Arguments" section, 
says this about argument 'exclude'.
>> passed to factor(); factor levels which should be excluded from the 
result even if present.  Note that this was implicitly NA in R <= 3.3.1 which 
did drop NA levels even when present in x, contrary to the documentation.  The 
current default is compatible with x[ , drop=FALSE].

>> The part
>> x[ , drop=FALSE]
>> should be
>> x[ , drop=TRUE]

> Yes, definitely, thank you!
> a "typo" by me. .. fixed now.

>> Saying that 'exclude' is factor levels is not quite true for NA element. 
NA may be not an original level, but NA in 'exclude' affects the result.

>> For a factor 'x', factor(x, exclude = exclude) doesn't really work for 
excluding in general. See, for example, 
https://stat.ethz.ch/pipermail/r-help/2005-September/079336.html .
>> factor(factor(c("a","b","c")), exclude="c")

>> However, this excludes "2":
>> factor(factor(2:3), exclude=2)

>> Rather unexpectedly, this excludes NA:
>> factor(factor(c("a",NA), exclude=NULL), exclude="c")

>> For a factor 'x', factor(x, exclude = exclude) can only exclude 
integer-like or NA levels. An explanation is in 
https://stat.ethz.ch/pipermail/r-help/2011-April/276274.html .

> Well, Peter Dalgaard (in that R-devel e-mail, a bit more than 5
> years ago) is confirming the problem there,  and suggesting (as
> you, right?) that actually   `factor()` is not behaving
> correctly here.

> And your persistence is finally getting close to convince me
> that it is not just droplevels(), but  factor() itself which
> needs care here.

> Interestingly, the following patch *does* pass 'make check-all'
> (after small change in tests/reg-tests-1b.R which is ok),
> and leads to behavior which is much closer to the documentation,
> notably for your two examples above would give what one would
> expect.

> (( If the R-Hub would support experiments with branches of R-devel 
> from R-core members,  I could just create such a branch and R Hub
> would run 'R CMD check '  for thousands of CRAN packages
> and provide a web page with the *differences* in the package
> check results ... so we could see ... ))

> I do agree that we should strongly consider such a change.

as nobody has commented, I've been liberal and have taken these
no comments as consent.

Hence I have committed


r71178 | maechler | 2016-08-31 09:45:40 +0200 (Wed, 31 Aug 2016) | 1 line
Changed paths:
   M /trunk/doc/NEWS.Rd
   M /trunk/src/library/base/R/factor.R
   M /trunk/src/library/base/man/factor.Rd
   M /trunk/tests/reg-tests-1b.R
   M /trunk/tests/reg-tests-1c.R

factor(x, exclude) more "rational" when x or exclude are character


which apart from documentation, examples, and regression tests
is just the patch below.

Martin Maechler
ETH Zurich


> --- factor.R  (revision 71157)
> +++ factor.R  (working copy)
> @@ -28,8 +28,12 @@
> levels <- unique(y[ind])
> }
> force(ordered) # check if original x is an ordered factor
> -exclude <- as.vector(exclude, typeof(x)) # may result in NA
> -x <- as.character(x)
> +if(!is.character(x)) {
> + if(!is.character(exclude))
> + exclude <- as.vector(exclude, typeof(x)) # may result in NA
> + x <- as.character(x)
> +} else
> + exclude <- as.vector(exclude, typeof(x)) # may result in NA
> ## levels could be a long vectors, but match will not handle that.
> levels <- levels[is.na(match(levels, exclude))]
> f <- match(x, levels)

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