date:20170126

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

2017-01-26 Thread James Collins

Thanks Valerie --- this makes complete sense, but I did not think about it. 
Might be good to post to the new package development FAQ if not there already.

> On Jan 26, 2017, at 5:20 PM, Obenchain, Valerie 
>  wrote:
> 
> It's good practice to bump the version as part of
> your final commit. When you don't, the version doesn't really represent
> a snapshot of  the package - you have drift here over 5 commits, all
> with the same version. The version bump is the trigger that refreshes /
> posts to the package landing page so it's important to bump as part of
> your final commit.


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

2017-01-26 Thread Obenchain, Valerie

This should have said 2:15pm PST deadline, not 2:25pm.
> Looking at the svn logs for LOBSTAHS in devel, there were quite a few
> commits on Jan 25. About 1/3 were before the 2:25pm deadline. These were
> probably the commits that straddled the deadline:



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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

2017-01-26 Thread Obenchain, Valerie

Hi,

Just to clarify, we do have daily software builds that start at 2:15pm
PST. We did not have a devel build report this week on Tuesday, Jan 24
due to a problem with the postrun script. AFAIK that is the only day
this week we haven't had a full build report.

Looking at the svn logs for LOBSTAHS in devel, there were quite a few
commits on Jan 25. About 1/3 were before the 2:25pm deadline. These were
probably the commits that straddled the deadline:


r126164 | j.collins | 2017-01-25 14:34:52 -0800 (Wed, 25 Jan 2017) | 1 line

Merge branch 'master' of https://github.com/Bioconductor-mirror/LOBSTAHS
into devel

r126159 | j.collins | 2017-01-25 13:56:09 -0800 (Wed, 25 Jan 2017) | 1 line

Remove .tar files

So the package picked up by the builds was r126159. If we check this
revision out of svn

  svn co -r126159 
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/LOBSTAHS

and look at the DESCRIPTION file the version is 1.1.1. So that version
was picked up yesterday for today's builds. The new build report just
posted for Jan 26 (which started Jan 25 at 2:25pm PST) and it is again
showing version 1.1.1 as we would expect.

It looks like you bumped the version in -r126221 but made several
changes after that. It's good practice to bump the version as part of
your final commit. When you don't, the version doesn't really represent
a snapshot of  the package - you have drift here over 5 commits, all
with the same version. The version bump is the trigger that refreshes /
posts to the package landing page so it's important to bump as part of
your final commit.


r126225 | j.collins | 2017-01-25 14:58:22 -0800 (Wed, 25 Jan 2017) | 1 line
Changed paths:
   M /trunk/madman/Rpacks/LOBSTAHS/README.md

Reversing the stylistic edit

r126224 | j.collins | 2017-01-25 14:58:15 -0800 (Wed, 25 Jan 2017) | 1 line
Changed paths:
   M /trunk/madman/Rpacks/LOBSTAHS/README.md

Stylistic edit

r126223 | j.collins | 2017-01-25 14:58:08 -0800 (Wed, 25 Jan 2017) | 1 line
Changed paths:
   M /trunk/madman/Rpacks/LOBSTAHS/README.md
   M /trunk/madman/Rpacks/LOBSTAHS/man/LOBdbase.Rd
   M /trunk/madman/Rpacks/LOBSTAHS/man/LOBdefaults.Rd
   M /trunk/madman/Rpacks/LOBSTAHS/man/doLOBscreen.Rd
   M /trunk/madman/Rpacks/LOBSTAHS/man/generateLOBdbase.Rd
   M /trunk/madman/Rpacks/LOBSTAHS/vignettes/LOBSTAHS.Rmd

Adding Fulton E. hux. paper to references throughout package

r126222 | j.collins | 2017-01-25 14:57:56 -0800 (Wed, 25 Jan 2017) | 1 line
Changed paths:
   M /trunk/madman/Rpacks/LOBSTAHS/data/default.LOBdbase.RData

Commit updated default database

r126221 | j.collins | 2017-01-25 14:57:47 -0800 (Wed, 25 Jan 2017) | 1 line
Changed paths:
   M /trunk/madman/Rpacks/LOBSTAHS/DESCRIPTION

Bump version, date


The builds tomorrow should post results for 1.1.3.

Valerie


On 01/26/2017 11:05 AM, Kasper Daniel Hansen wrote:
> Traditionally we have had daily builds, which then takes more than 12h to
> complete.  Recently, the daily build schedule has been more intermitten - I
> don't know for sure but I thought we were back to daily builds.
>
> Still, there can be a big delay due to build time and start, like up to
> 36h.  But it is 1.1.3 in subversion, so I think it is a build delay.
>
> On Thu, Jan 26, 2017 at 11:04 AM, James Collins <
> james.r.coll...@aya.yale.edu> wrote:
>
>> Thanks, Kasper. On your second point: Yes, several recent updates. The
>> bump to v1.1.2 was two days ago, so I figured that would have been
>> reflected in a newer build already. I will give it a few more days.
>> Jamie
>>
>>
>> On Jan 26, 2017, at 11:57 AM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com> wrote:
>>
>> It happens in devel that your dependencies fail and then your package
>> fails.  Right now XCMS fails in devel because mzR fails.  That will
>> presumably be sorted out.
>>
>> The latest build report
>>   http://bioconductor.org/checkResults/3.5/bioc-LATEST/LOBSTAHS/
>> is 1.1.1.  Did you do a couple of updates very recently - remember the
>> build system gets run (at most) daily.
>>
>> Best,
>> Kasper
>>
>> On Thu, Jan 26, 2017 at 9:53 AM, James Collins > yale.edu> wrote:
>>
>>> Hi all:
>>>
>>> Two questions regarding the LOBSTAHS package:
>>>
>>> 1. Dev build seems to be failing (“error”) on toluca2 after I pushed some
>>> updates from our git repository to Bioc svn. Error is:
>>> * installing to library ‘/Library/Frameworks/R.framewo
>>> rk/Versions/3.4/Resources/library’
>>> ERROR: dependencies ‘xcms’, ‘CAMERA’

[Bioc-devel] Recent changes in xcms

2017-01-26 Thread Rainer Johannes

Dear all,

we are currently in the middle of refactoring and updating the xcms package, 
which could cause (on the short term) some problems in packages depending on 
functionality from xcms. In the long run everything should work and integration 
of functionality from xcms in other packages should become easier (i.e. have an 
eye on the new "do_" functions which expose core algorithm without having to 
use classes from xcms). Also, we will reuse classes and functionality from the 
MSnbase package in order to create a more streamlined functionality for MS 
based data.

If you want to know more have a look at our github page 
https://github.com/sneumann/xcms , if you run into problems either drop me a 
line or (preferrably) open an issue on github.

thanks, Johannes and Steffen



[[alternative HTML version deleted]]

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

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

2017-01-26 Thread Kasper Daniel Hansen

Traditionally we have had daily builds, which then takes more than 12h to
complete.  Recently, the daily build schedule has been more intermitten - I
don't know for sure but I thought we were back to daily builds.

Still, there can be a big delay due to build time and start, like up to
36h.  But it is 1.1.3 in subversion, so I think it is a build delay.

On Thu, Jan 26, 2017 at 11:04 AM, James Collins <
james.r.coll...@aya.yale.edu> wrote:

> Thanks, Kasper. On your second point: Yes, several recent updates. The
> bump to v1.1.2 was two days ago, so I figured that would have been
> reflected in a newer build already. I will give it a few more days.
> Jamie
>
>
> On Jan 26, 2017, at 11:57 AM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> It happens in devel that your dependencies fail and then your package
> fails.  Right now XCMS fails in devel because mzR fails.  That will
> presumably be sorted out.
>
> The latest build report
>   http://bioconductor.org/checkResults/3.5/bioc-LATEST/LOBSTAHS/
> is 1.1.1.  Did you do a couple of updates very recently - remember the
> build system gets run (at most) daily.
>
> Best,
> Kasper
>
> On Thu, Jan 26, 2017 at 9:53 AM, James Collins  yale.edu> wrote:
>
>> Hi all:
>>
>> Two questions regarding the LOBSTAHS package:
>>
>> 1. Dev build seems to be failing (“error”) on toluca2 after I pushed some
>> updates from our git repository to Bioc svn. Error is:
>> * installing to library ‘/Library/Frameworks/R.framewo
>> rk/Versions/3.4/Resources/library’
>> ERROR: dependencies ‘xcms’, ‘CAMERA’ are not available for package
>> ‘LOBSTAHS’
>> * removing ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/
>> library/LOBSTAHS’
>> However, seems to build fine on oaxaca. Any ideas why this is happening?
>> xcms and CAMERA should be available for the package, correct?
>>
>> 2. After bumping the version number (from 1.1.1 to 1.1.2 and then 1.1.3)
>> with the updates, the latest version (1.1.3) does not appear to be showing
>> on the dev page, which leads me to believe it is not the version being
>> disseminated with biocLite()
>>
>> http://bioconductor.org/packages/3.5/bioc/html/LOBSTAHS.html <
>> http://bioconductor.org/packages/3.5/bioc/html/LOBSTAHS.html>
>>
>> Perhaps this is because I cherry-pick all my commits when committing from
>> git to the Bioc svn? Or because of the error message?
>>
>> Thanks in advance!
>>
>> Jamie Collins
>>
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] rtracklayer

2017-01-26 Thread Michael Lawrence

Hi,

We're working on resolving the issue. Sorry for the trouble.

Michael

On Thu, Jan 26, 2017 at 9:25 AM, Kathleen Klein <
kathleen.kl...@mail.mcgill.ca> wrote:

> A number of packages are failing in the recent build of R-devel due to
> rtracklayer.
> Any news on a fix for rtracklayer?
> I am getting the following error when R is trying to load the
> rtracklayer.so file
> unable to load shared object rtracklayer.so:  undefined symbol:
> append_string_to_CharAEAE
>
> Kathleen Oros Klein
> Research Associate / Lab Manager for Dr Celia MT Greenwood's lab
> Lady Davis Institute (LDI)
> 3755 Chemin de la Côte-Sainte-Catherine,
> Montréal, QC H3T 1E2
> 514-340-8222 ext. 8381
>
> Email: kathleen.kl...@mail.mcgill.ca
>
>
> [[alternative HTML version deleted]]
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] : strptime bug [no more!]

2017-01-26 Thread rob vech

Thank you Georg!
It definitely resolves the problem!
Adding the correct time zone (tz='GMT') returns a valid number as my 
data are in solar time.
rob

[[alternative HTML version deleted]]

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

[Bioc-devel] xps build problem on toluca2

2017-01-26 Thread cstrato


Dear all,

Since Dan, who was always very helpful and took care of the special 
requirements of my package 'xps', is no longer part of the BioC group, 
and I do not know who is currently responsible for the BioC servers, I 
am writing to you to inform you of the problem building 'xps' on the new 
Mac server 'toluca2':

http://bioconductor.org/checkResults/devel/bioc-LATEST/xps/toluca2-buildsrc.html

Could you please install ROOT on toluca2 to prevent the build error of 
'xps'.


Since both, toluca2 and oaxaca, are running Mac OS X Mavericks, it 
should be no problem to transfer ROOT and the corresponding settings to 
toluca2.


Thank you in advance.
Best regards,
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n   S.t.r.a.t.o.w.a
V.i.e.n.n.a   A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._

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

Re: [Bioc-devel] plotPCA in affycoretools not working

2017-01-26 Thread James W. MacDonald

This isn't a question for Bioc-devel, which is intended for questions about
package development. In future, please use the support site,
https://support.bioconductor.org

That said, I have checked in a fix which should propagate through the build
servers in the next day or two. In the meantime you can simply do

exprs <- ExpressionSet(WEHAsum)
plotPCA(exprs[,-1])

On Thu, Jan 26, 2017 at 10:38 AM, Vojtech Kulvait  wrote:

> When using this code
>
> WEHAsum = read.csv("/tmp/wehasum.csv", check.names = FALSE, as.is=TRUE)
> plotPCA(as.matrix(WEHAsum[,-1][,sort(colnames(WEHAsum[,-1]))]),
> x.coord=-20, y.coord=20)
>
> I get
>
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function 'plotPCA' for signature
> '"matrix"'
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

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

[Bioc-devel] rtracklayer

2017-01-26 Thread Kathleen Klein

A number of packages are failing in the recent build of R-devel due to 
rtracklayer.
Any news on a fix for rtracklayer?
I am getting the following error when R is trying to load the rtracklayer.so 
file
unable to load shared object rtracklayer.so:  undefined symbol: 
append_string_to_CharAEAE

Kathleen Oros Klein
Research Associate / Lab Manager for Dr Celia MT Greenwood's lab
Lady Davis Institute (LDI)
3755 Chemin de la C�te-Sainte-Catherine,
Montr�al, QC H3T 1E2
514-340-8222 ext. 8381

Email: kathleen.kl...@mail.mcgill.ca


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

2017-01-26 Thread James Collins

Thanks, Kasper. On your second point: Yes, several recent updates. The bump to 
v1.1.2 was two days ago, so I figured that would have been reflected in a newer 
build already. I will give it a few more days.
Jamie  

> On Jan 26, 2017, at 11:57 AM, Kasper Daniel Hansen 
>  wrote:
> 
> It happens in devel that your dependencies fail and then your package fails.  
> Right now XCMS fails in devel because mzR fails.  That will presumably be 
> sorted out.
> 
> The latest build report
>   http://bioconductor.org/checkResults/3.5/bioc-LATEST/LOBSTAHS/ 
> 
> is 1.1.1.  Did you do a couple of updates very recently - remember the build 
> system gets run (at most) daily.
> 
> Best,
> Kasper
> 
> On Thu, Jan 26, 2017 at 9:53 AM, James Collins  > wrote:
> Hi all:
> 
> Two questions regarding the LOBSTAHS package:
> 
> 1. Dev build seems to be failing (“error”) on toluca2 after I pushed some 
> updates from our git repository to Bioc svn. Error is:
> * installing to library 
> ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’
> ERROR: dependencies ‘xcms’, ‘CAMERA’ are not available for package ‘LOBSTAHS’
> * removing 
> ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/LOBSTAHS’
> However, seems to build fine on oaxaca. Any ideas why this is happening? xcms 
> and CAMERA should be available for the package, correct?
> 
> 2. After bumping the version number (from 1.1.1 to 1.1.2 and then 1.1.3) with 
> the updates, the latest version (1.1.3) does not appear to be showing on the 
> dev page, which leads me to believe it is not the version being disseminated 
> with biocLite()
> 
> http://bioconductor.org/packages/3.5/bioc/html/LOBSTAHS.html 
>  
>  >
> 
> Perhaps this is because I cherry-pick all my commits when committing from git 
> to the Bioc svn? Or because of the error message?
> 
> Thanks in advance!
> 
> Jamie Collins
> 
> 
> [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel 
> 

[[alternative HTML version deleted]]

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

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

2017-01-26 Thread Henrik Bengtsson

On a related note, the storage mode should try to match ans[[1]] (or
unlist:ed and) when allocating 'ansmat' to avoid coercion and hence a full
copy.

Henrik


On Jan 26, 2017 07:50, "William Dunlap via R-devel" 
wrote:

It would be cool if the default for tapply's init.value could be
FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for
FUN=all, -Inf for FUN=max, etc.  But that would take time and would
break code for which FUN did not work on length-0 objects.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Jan 26, 2017 at 2:42 AM, Martin Maechler
 wrote:
> Last week, we've talked here about "xtabs(), factors and NAs",
>  ->  https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html
>
> In the mean time, I've spent several hours on the issue
> and also committed changes to R-devel "in two iterations".
>
> In the case there is a *Left* hand side part to xtabs() formula,
> see the help page example using 'esoph',
> it uses  tapply(...,  FUN = sum)   and
> I now think there is a missing feature in tapply() there, which
> I am proposing to change.
>
> Look at a small example:
>
>> D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]),
N=3)[-c(1,5), ]; xtabs(~., D2)
> , , N = 3
>
>L
> n   A B C D E F
>   1 1 2 0 0 0 0
>   2 0 0 1 2 0 0
>   3 0 0 0 0 2 2
>
>> DN <- D2; DN[1,"N"] <- NA; DN
>n L  N
> 2  1 A NA
> 3  1 B  3
> 4  1 B  3
> 6  2 C  3
> 7  2 D  3
> 8  2 D  3
> 9  3 E  3
> 10 3 E  3
> 11 3 F  3
> 12 3 F  3
>> with(DN, tapply(N, list(n,L), FUN=sum))
>A  B  C  D  E  F
> 1 NA  6 NA NA NA NA
> 2 NA NA  3  6 NA NA
> 3 NA NA NA NA  6  6
>>
>
> and as you can see, the resulting matrix has NAs, all the same
> NA_real_, but semantically of two different kinds:
>
> 1) at ["1", "A"], the  NA  comes from the NA in 'N'
> 2) all other NAs come from the fact that there is no such factor
combination
>*and* from the fact that tapply() uses
>
>array(dim = .., dimnames = ...)
>
> i.e., initializes the array with NAs  (see definition of 'array').
>
> My proposition is the following patch to  tapply(), adding a new
> option 'init.value':
>
> 
-
>
> -tapply <- function (X, INDEX, FUN = NULL, ..., simplify = TRUE)
> +tapply <- function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify
= TRUE)
>  {
>  FUN <- if (!is.null(FUN)) match.fun(FUN)
>  if (!is.list(INDEX)) INDEX <- list(INDEX)
> @@ -44,7 +44,7 @@
>  index <- as.logical(lengths(ans))  # equivalently, lengths(ans) > 0L
>  ans <- lapply(X = ans[index], FUN = FUN, ...)
>  if (simplify && all(lengths(ans) == 1L)) {
> -   ansmat <- array(dim = extent, dimnames = namelist)
> +   ansmat <- array(init.value, dim = extent, dimnames = namelist)
> ans <- unlist(ans, recursive = FALSE)
>  } else {
> ansmat <- array(vector("list", prod(extent)),
>
> 
-
>
> With that, I can set the initial value to '0' instead of array's
> default of NA :
>
>> with(DN, tapply(N, list(n,L), FUN=sum, init.value=0))
>A B C D E F
> 1 NA 6 0 0 0 0
> 2  0 0 3 6 0 0
> 3  0 0 0 0 6 6
>>
>
> which now has 0 counts and NA  as is desirable to be used inside
> xtabs().
>
> All fine... and would not be worth a posting to R-devel,
> except for this:
>
> The change will not be 100% back compatible -- by necessity: any new
argument for
> tapply() will make that argument name not available to be
> specified (via '...') for 'FUN'.  The new function would be
>
>> str(tapply)
> function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = TRUE)
>
> where the '...' are passed FUN(),  and with the new signature,
> 'init.value' then won't be passed to FUN  "anymore" (compared to
> R <= 3.3.x).
>
> For that reason, we could use   'INIT.VALUE' instead (possibly decreasing
> the probability the arg name is used in other functions).
>
>
> Opinions?
>
> Thank you in advance,
> Martin
>
> __
> 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

[Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

2017-01-26 Thread James Collins

Hi all:

Two questions regarding the LOBSTAHS package:

1. Dev build seems to be failing (“error”) on toluca2 after I pushed some 
updates from our git repository to Bioc svn. Error is:
* installing to library 
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’
ERROR: dependencies ‘xcms’, ‘CAMERA’ are not available for package ‘LOBSTAHS’
* removing 
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/LOBSTAHS’
However, seems to build fine on oaxaca. Any ideas why this is happening? xcms 
and CAMERA should be available for the package, correct?

2. After bumping the version number (from 1.1.1 to 1.1.2 and then 1.1.3) with 
the updates, the latest version (1.1.3) does not appear to be showing on the 
dev page, which leads me to believe it is not the version being disseminated 
with biocLite()

http://bioconductor.org/packages/3.5/bioc/html/LOBSTAHS.html 


Perhaps this is because I cherry-pick all my commits when committing from git 
to the Bioc svn? Or because of the error message?

Thanks in advance!

Jamie Collins


[[alternative HTML version deleted]]

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

Re: [Rd] Undefined behavior of head() and tail() with n = 0

2017-01-26 Thread William Dunlap via R-devel

In addition, signed zeroes only exist for floating point numbers - the
bit patterns for as.integer(0) and as.integer(-0) are identical.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Jan 26, 2017 at 1:53 AM, Martin Maechler
 wrote:
>> Florent Angly 
>> on Wed, 25 Jan 2017 16:31:45 +0100 writes:
>
> > Hi all,
> > The documentation for head() and tail() describes the behavior of
> > these generic functions when n is strictly positive (n > 0) and
> > strictly negative (n < 0). How these functions work when given a zero
> > value is not defined.
>
> > Both GNU command-line utilities head and tail behave differently with 
> +0 and -0:
> > http://man7.org/linux/man-pages/man1/head.1.html
> > http://man7.org/linux/man-pages/man1/tail.1.html
>
> > Since R supports signed zeros (1/+0 != 1/-0)
>
> whoa, whoa, .. slow down --  The above is misleading!
>
> Rather read in  ?Arithmetic (*the* reference to consult for such issues),
> where the 2nd part of the following section
>
>  || Implementation limits:
>  ||
>  ||  [..]
>  ||
>  ||  Another potential issue is signed zeroes: on IEC 60659 platforms
>  ||  there are two zeroes with internal representations differing by
>  ||  sign.  Where possible R treats them as the same, but for example
>  ||  direct output from C code often does not do so and may output
>  ||  ‘-0.0’ (and on Windows whether it does so or not depends on the
>  ||  version of Windows).  One place in R where the difference might be
>  ||  seen is in division by zero: ‘1/x’ is ‘Inf’ or ‘-Inf’ depending on
>  ||  the sign of zero ‘x’.  Another place is ‘identical(0, -0, num.eq =
>  ||  FALSE)’.
>
> says the *contrary* ( __Where possible R treats them as the same__ ):
> We do _not_ want to distinguish -0 and +0,
> but there are cases where it is inavoidable
>
> And there are good reasons (mathematics !!) for this.
>
> I'm pretty sure that it would be quite a mistake to start
> differentiating it here...  but of course we can continue
> discussing here if you like.
>
> Martin Maechler
> ETH Zurich and R Core
>
>
> > and the R head() and tail() functions are modeled after
> > their GNU counterparts, I would expect the R functions to
> > distinguish between +0 and -0
>
> >> tail(1:5, n=0)
> > integer(0)
> >> tail(1:5, n=1)
> > [1] 5
> >> tail(1:5, n=2)
> > [1] 4 5
>
> >> tail(1:5, n=-2)
> > [1] 3 4 5
> >> tail(1:5, n=-1)
> > [1] 2 3 4 5
> >> tail(1:5, n=-0)
> > integer(0)  # expected 1:5
>
> >> head(1:5, n=0)
> > integer(0)
> >> head(1:5, n=1)
> > [1] 1
> >> head(1:5, n=2)
> > [1] 1 2
>
> >> head(1:5, n=-2)
> > [1] 1 2 3
> >> head(1:5, n=-1)
> > [1] 1 2 3 4
> >> head(1:5, n=-0)
> > integer(0)  # expected 1:5
>
> > For both head() and tail(), I expected 1:5 as output but got
> > integer(0). I obtained similar results using a data.frame and a
> > function as x argument.
>
> > An easy fix would be to explicitly state in the documentation what n =
> > 0 does, and that there is no practical difference between -0 and +0.
> > However, in my eyes, the better approach would be implement support
> > for -0 and document it. What do you think?
>
> > Best,
>
> > Florent
>
>
> > PS/ My sessionInfo() gives:
> > R version 3.3.2 (2016-10-31)
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > Running under: Windows 7 x64 (build 7601) Service Pack 1
>
> > locale:
> > [1] LC_COLLATE=German_Switzerland.1252
> > LC_CTYPE=German_Switzerland.1252
> > LC_MONETARY=German_Switzerland.1252 LC_NUMERIC=C
> > LC_TIME=German_Switzerland.1252
>
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

2017-01-26 Thread William Dunlap via R-devel

It would be cool if the default for tapply's init.value could be
FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for
FUN=all, -Inf for FUN=max, etc.  But that would take time and would
break code for which FUN did not work on length-0 objects.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Thu, Jan 26, 2017 at 2:42 AM, Martin Maechler
 wrote:
> Last week, we've talked here about "xtabs(), factors and NAs",
>  ->  https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html
>
> In the mean time, I've spent several hours on the issue
> and also committed changes to R-devel "in two iterations".
>
> In the case there is a *Left* hand side part to xtabs() formula,
> see the help page example using 'esoph',
> it uses  tapply(...,  FUN = sum)   and
> I now think there is a missing feature in tapply() there, which
> I am proposing to change.
>
> Look at a small example:
>
>> D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), 
>> N=3)[-c(1,5), ]; xtabs(~., D2)
> , , N = 3
>
>L
> n   A B C D E F
>   1 1 2 0 0 0 0
>   2 0 0 1 2 0 0
>   3 0 0 0 0 2 2
>
>> DN <- D2; DN[1,"N"] <- NA; DN
>n L  N
> 2  1 A NA
> 3  1 B  3
> 4  1 B  3
> 6  2 C  3
> 7  2 D  3
> 8  2 D  3
> 9  3 E  3
> 10 3 E  3
> 11 3 F  3
> 12 3 F  3
>> with(DN, tapply(N, list(n,L), FUN=sum))
>A  B  C  D  E  F
> 1 NA  6 NA NA NA NA
> 2 NA NA  3  6 NA NA
> 3 NA NA NA NA  6  6
>>
>
> and as you can see, the resulting matrix has NAs, all the same
> NA_real_, but semantically of two different kinds:
>
> 1) at ["1", "A"], the  NA  comes from the NA in 'N'
> 2) all other NAs come from the fact that there is no such factor combination
>*and* from the fact that tapply() uses
>
>array(dim = .., dimnames = ...)
>
> i.e., initializes the array with NAs  (see definition of 'array').
>
> My proposition is the following patch to  tapply(), adding a new
> option 'init.value':
>
> -
>
> -tapply <- function (X, INDEX, FUN = NULL, ..., simplify = TRUE)
> +tapply <- function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = 
> TRUE)
>  {
>  FUN <- if (!is.null(FUN)) match.fun(FUN)
>  if (!is.list(INDEX)) INDEX <- list(INDEX)
> @@ -44,7 +44,7 @@
>  index <- as.logical(lengths(ans))  # equivalently, lengths(ans) > 0L
>  ans <- lapply(X = ans[index], FUN = FUN, ...)
>  if (simplify && all(lengths(ans) == 1L)) {
> -   ansmat <- array(dim = extent, dimnames = namelist)
> +   ansmat <- array(init.value, dim = extent, dimnames = namelist)
> ans <- unlist(ans, recursive = FALSE)
>  } else {
> ansmat <- array(vector("list", prod(extent)),
>
> -
>
> With that, I can set the initial value to '0' instead of array's
> default of NA :
>
>> with(DN, tapply(N, list(n,L), FUN=sum, init.value=0))
>A B C D E F
> 1 NA 6 0 0 0 0
> 2  0 0 3 6 0 0
> 3  0 0 0 0 6 6
>>
>
> which now has 0 counts and NA  as is desirable to be used inside
> xtabs().
>
> All fine... and would not be worth a posting to R-devel,
> except for this:
>
> The change will not be 100% back compatible -- by necessity: any new argument 
> for
> tapply() will make that argument name not available to be
> specified (via '...') for 'FUN'.  The new function would be
>
>> str(tapply)
> function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = TRUE)
>
> where the '...' are passed FUN(),  and with the new signature,
> 'init.value' then won't be passed to FUN  "anymore" (compared to
> R <= 3.3.x).
>
> For that reason, we could use   'INIT.VALUE' instead (possibly decreasing
> the probability the arg name is used in other functions).
>
>
> Opinions?
>
> Thank you in advance,
> Martin
>
> __
> 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] plotPCA in affycoretools not working

2017-01-26 Thread Vojtech Kulvait

When using this code

WEHAsum = read.csv("/tmp/wehasum.csv", check.names = FALSE, as.is=TRUE)
plotPCA(as.matrix(WEHAsum[,-1][,sort(colnames(WEHAsum[,-1]))]),
x.coord=-20, y.coord=20)

I get

Error in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function 'plotPCA' for signature
'"matrix"'
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] : strptime bug

2017-01-26 Thread Georgi Boshnakov

Hi,

You don't give the time zone but this is probably due to the clock jumping by 
one hour when switching to summer time. In UK this happens at 1am and on that 
day there is no such thing as 01:05, etc.,  see eg 
https://www.timeanddate.com/time/change/uk/london
In your time zone this probably happens at 2am.

Georgi Boshnakov

--

Message: 7
Date: Thu, 26 Jan 2017 11:02:06 +0100
From: rob vech 
To: r-devel@r-project.org
Subject: [Rd] strptime bug
Message-ID: <70325e6b-6d54-8172-3915-bbfc8d5cd...@gmail.com>
Content-Type: text/plain; charset="UTF-8"

Dear developer list,
I want to submit the following problem that seems like a bug, as confirmed by 
an other user [1], related to date-time parsing:
Here a simple script:

# that works:
as.numeric(as.POSIXlt(strptime('2016-03-27 01:05:50', format='%Y-%m-%d
%H:%M:%S')))

# that not (it returns NA):
as.numeric(as.POSIXlt(strptime('2016-03-27 02:05:50', format='%Y-%m-%d
%H:%M:%S')))

# it works again
as.numeric(as.POSIXlt(strptime('2016-03-27 03:05:50', format='%Y-%m-%d
%H:%M:%S')))

I made several test and the problem seems to be related to the couple 
"2016-03-27" as date and "2" as hour. It seems not to be related to the 
datetime format.

There is a similar bug on bugzilla [2] but in my case I cannot replicate it.

My OS is Win 7 and R v3.3.2.

Thank you

rob


[1] https://stat.ethz.ch/pipermail/r-help/2017-January/68.html

[2] https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16764


[[alternative HTML version deleted]]



--

Subject: Digest Footer

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

--

End of R-devel Digest, Vol 167, Issue 23

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

[Rd] strptime bug

2017-01-26 Thread rob vech

Dear developer list,
I want to submit the following problem that seems like a bug, as 
confirmed by an other user [1], related to date-time parsing:
Here a simple script:

# that works:
as.numeric(as.POSIXlt(strptime('2016-03-27 01:05:50', format='%Y-%m-%d 
%H:%M:%S')))

# that not (it returns NA):
as.numeric(as.POSIXlt(strptime('2016-03-27 02:05:50', format='%Y-%m-%d 
%H:%M:%S')))

# it works again
as.numeric(as.POSIXlt(strptime('2016-03-27 03:05:50', format='%Y-%m-%d 
%H:%M:%S')))

I made several test and the problem seems to be related to the couple 
"2016-03-27" as date and "2" as hour. It seems not to be related to the 
datetime format.

There is a similar bug on bugzilla [2] but in my case I cannot replicate it.

My OS is Win 7 and R v3.3.2.

Thank you

rob


[1] https://stat.ethz.ch/pipermail/r-help/2017-January/68.html

[2] https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16764


[[alternative HTML version deleted]]

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

[Rd] RFC: tapply(*, ..., init.value = NA)

2017-01-26 Thread Martin Maechler

Last week, we've talked here about "xtabs(), factors and NAs",
 ->  https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html

In the mean time, I've spent several hours on the issue
and also committed changes to R-devel "in two iterations".

In the case there is a *Left* hand side part to xtabs() formula,
see the help page example using 'esoph',
it uses  tapply(...,  FUN = sum)   and
I now think there is a missing feature in tapply() there, which
I am proposing to change. 

Look at a small example:

> D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), N=3)[-c(1,5), 
> ]; xtabs(~., D2)
, , N = 3

   L
n   A B C D E F
  1 1 2 0 0 0 0
  2 0 0 1 2 0 0
  3 0 0 0 0 2 2

> DN <- D2; DN[1,"N"] <- NA; DN
   n L  N
2  1 A NA
3  1 B  3
4  1 B  3
6  2 C  3
7  2 D  3
8  2 D  3
9  3 E  3
10 3 E  3
11 3 F  3
12 3 F  3
> with(DN, tapply(N, list(n,L), FUN=sum))
   A  B  C  D  E  F
1 NA  6 NA NA NA NA
2 NA NA  3  6 NA NA
3 NA NA NA NA  6  6
>  

and as you can see, the resulting matrix has NAs, all the same
NA_real_, but semantically of two different kinds:

1) at ["1", "A"], the  NA  comes from the NA in 'N'
2) all other NAs come from the fact that there is no such factor combination
   *and* from the fact that tapply() uses

   array(dim = .., dimnames = ...)

i.e., initializes the array with NAs  (see definition of 'array').

My proposition is the following patch to  tapply(), adding a new
option 'init.value':

-
 
-tapply <- function (X, INDEX, FUN = NULL, ..., simplify = TRUE)
+tapply <- function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = 
TRUE)
 {
 FUN <- if (!is.null(FUN)) match.fun(FUN)
 if (!is.list(INDEX)) INDEX <- list(INDEX)
@@ -44,7 +44,7 @@
 index <- as.logical(lengths(ans))  # equivalently, lengths(ans) > 0L
 ans <- lapply(X = ans[index], FUN = FUN, ...)
 if (simplify && all(lengths(ans) == 1L)) {
-   ansmat <- array(dim = extent, dimnames = namelist)
+   ansmat <- array(init.value, dim = extent, dimnames = namelist)
ans <- unlist(ans, recursive = FALSE)
 } else {
ansmat <- array(vector("list", prod(extent)),

-

With that, I can set the initial value to '0' instead of array's
default of NA :

> with(DN, tapply(N, list(n,L), FUN=sum, init.value=0))
   A B C D E F
1 NA 6 0 0 0 0
2  0 0 3 6 0 0
3  0 0 0 0 6 6
> 

which now has 0 counts and NA  as is desirable to be used inside
xtabs().

All fine... and would not be worth a posting to R-devel,
except for this:

The change will not be 100% back compatible -- by necessity: any new argument 
for
tapply() will make that argument name not available to be
specified (via '...') for 'FUN'.  The new function would be

> str(tapply)
function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = TRUE)  

where the '...' are passed FUN(),  and with the new signature,
'init.value' then won't be passed to FUN  "anymore" (compared to
R <= 3.3.x).

For that reason, we could use   'INIT.VALUE' instead (possibly decreasing
the probability the arg name is used in other functions).


Opinions?

Thank you in advance,
Martin

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

Re: [R-pkg-devel] Process for building vignettes during a CRAN package submission

2017-01-26 Thread Uwe Ligges




On 25.01.2017 19:17, Anderson,Brooke wrote:

I am creating a package with a 'Suggests' dependency on a second package hosted in a drat 
repository on GitHub. I have listed the second package in 'Suggests' of the DESCRIPTION 
file for the first package and listed the drat repository in 'Additional_repositories'. I 
have made all code in the vignette and examples conditional on the availability of the 
second repository using `requireNamespace`, with the `quietly` option set to TRUE, so 
code is skipped if the package is built on a system that does not have the second package 
loaded. This package is passing all CRAN checks on my computer and only gets a single 
NOTE on win-builder about "Suggests or Enhances not in mainstream 
repositories", so I'm happy with the package set-up in terms of passing checks.


My one concern is what the vignette that users who install the package from 
CRAN will look like. If I build the vignette on my computer, with the second 
package installed, the vignette looks as I would like it to for users, since 
all the examples are run. However, if the vignette is built on a system without 
the second package installed, the vignette is pretty boring since most examples 
are skipped. I have a question about the CRAN submission process related to 
vignette building that will help me clarify this concern.


Based on reading through "Writing R Extensions", this is what I think happens 
with a vignette and its code during the CRAN submission process:


1. Before submitting the package to CRAN, the package maintainer builds and 
checks the package locally. When the package is built locally, any vignettes 
are built in pdf and / or html files. These files are stored in the package's 
`\inst\doc` directory. This directory (`inst\doc`) is packaged with other 
package elements else in the .tar.gz file. Everything in .tar.gz is sent to 
CRAN.

2. When the package is sent to CRAN, CRAN tries running all of the code in the 
examples and vignette. However, CRAN does not rebuild the vignette.

3. Once the package is on CRAN, CRAN regularly checks the package. To do this, 
CRAN tries running all of the code in the examples and vignette. However, 
again, CRAN does not rebuild the vignette. Instead, the vignette that is sent 
out to users continues to be the one built by the package maintainer when he or 
she first submitted the package .tar.gz to CRAN.


Have I understood this process, particularly #2, correctly? Or will CRAN 
rebuild the vignette during the submission process and replace the .html or 
.pdf version of the vignette that is passed to users who install the package 
from CRAN?



Correct, the vignette that is shipped is the one you built locally.
CRAN tests if it can be rebuilt.

Best,
Uwe Ligges




[[alternative HTML version deleted]]

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



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

Re: [Rd] Undefined behavior of head() and tail() with n = 0

2017-01-26 Thread Martin Maechler

> Florent Angly 
> on Wed, 25 Jan 2017 16:31:45 +0100 writes:

> Hi all,
> The documentation for head() and tail() describes the behavior of
> these generic functions when n is strictly positive (n > 0) and
> strictly negative (n < 0). How these functions work when given a zero
> value is not defined.

> Both GNU command-line utilities head and tail behave differently with +0 
and -0:
> http://man7.org/linux/man-pages/man1/head.1.html
> http://man7.org/linux/man-pages/man1/tail.1.html

> Since R supports signed zeros (1/+0 != 1/-0) 

whoa, whoa, .. slow down --  The above is misleading!

Rather read in  ?Arithmetic (*the* reference to consult for such issues),
where the 2nd part of the following section

 || Implementation limits:
 || 
 ||  [..]
 || 
 ||  Another potential issue is signed zeroes: on IEC 60659 platforms
 ||  there are two zeroes with internal representations differing by
 ||  sign.  Where possible R treats them as the same, but for example
 ||  direct output from C code often does not do so and may output
 ||  ‘-0.0’ (and on Windows whether it does so or not depends on the
 ||  version of Windows).  One place in R where the difference might be
 ||  seen is in division by zero: ‘1/x’ is ‘Inf’ or ‘-Inf’ depending on
 ||  the sign of zero ‘x’.  Another place is ‘identical(0, -0, num.eq =
 ||  FALSE)’.

says the *contrary* ( __Where possible R treats them as the same__ ):
We do _not_ want to distinguish -0 and +0,
but there are cases where it is inavoidable

And there are good reasons (mathematics !!) for this.

I'm pretty sure that it would be quite a mistake to start
differentiating it here...  but of course we can continue
discussing here if you like.

Martin Maechler
ETH Zurich and R Core


> and the R head() and tail() functions are modeled after
> their GNU counterparts, I would expect the R functions to
> distinguish between +0 and -0

>> tail(1:5, n=0)
> integer(0)
>> tail(1:5, n=1)
> [1] 5
>> tail(1:5, n=2)
> [1] 4 5

>> tail(1:5, n=-2)
> [1] 3 4 5
>> tail(1:5, n=-1)
> [1] 2 3 4 5
>> tail(1:5, n=-0)
> integer(0)  # expected 1:5

>> head(1:5, n=0)
> integer(0)
>> head(1:5, n=1)
> [1] 1
>> head(1:5, n=2)
> [1] 1 2

>> head(1:5, n=-2)
> [1] 1 2 3
>> head(1:5, n=-1)
> [1] 1 2 3 4
>> head(1:5, n=-0)
> integer(0)  # expected 1:5

> For both head() and tail(), I expected 1:5 as output but got
> integer(0). I obtained similar results using a data.frame and a
> function as x argument.

> An easy fix would be to explicitly state in the documentation what n =
> 0 does, and that there is no practical difference between -0 and +0.
> However, in my eyes, the better approach would be implement support
> for -0 and document it. What do you think?

> Best,

> Florent


> PS/ My sessionInfo() gives:
> R version 3.3.2 (2016-10-31)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1

> locale:
> [1] LC_COLLATE=German_Switzerland.1252
> LC_CTYPE=German_Switzerland.1252
> LC_MONETARY=German_Switzerland.1252 LC_NUMERIC=C
> LC_TIME=German_Switzerland.1252

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

> __
> 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: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

[Bioc-devel] Recent changes in xcms

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

Re: [Bioc-devel] rtracklayer

Re: [Rd] : strptime bug [no more!]

[Bioc-devel] xps build problem on toluca2

Re: [Bioc-devel] plotPCA in affycoretools not working

[Bioc-devel] rtracklayer

Re: [Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

[Bioc-devel] LOBSTAHS dev build failing on toluca2; version does not update in devel

Re: [Rd] Undefined behavior of head() and tail() with n = 0

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

[Bioc-devel] plotPCA in affycoretools not working

Re: [Rd] : strptime bug

[Rd] strptime bug

[Rd] RFC: tapply(*, ..., init.value = NA)

Re: [R-pkg-devel] Process for building vignettes during a CRAN package submission

Re: [Rd] Undefined behavior of head() and tail() with n = 0

21 matches

Site Navigation

Mail list logo

Footer information