Re: [Bioc-devel] updates on support.bioconductor.org

[Obenchain, Valerie]

Updates are complete. The support site is up and functioning normally.

Valerie

On 08/03/2017 08:58 AM, Obenchain, Valerie wrote:

Updates are scheduled for support.bioconductor.org today August 3, at 5pm EST.  
If all goes as expected this should take < 15 minutes. The support site may be 
slow or briefly unavailable during this time.

Valerie


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





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

[Bioc-devel] Initial List of Deprecated Packages for Bioc3.6

[Shepherd, Lori]

The Bioconductor Team is starting to identify packages that will be deprecated 
in the next release to allow the Bioconductor community to respond accordingly. 
 This list will be updated monthly leading up to the release.  The initial list 
of deprecated packages is as follow:


Unresponsive/not-maintained packages:


EWCW

MAIT

stepwiseCM



Maintainer requested deprecation:

oneChannelGUI




Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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] rnorm is not truly random used in the lm function

[Victor Tian]

I did it purely based on the intuition I built from elsewhere and maybe in
R as well.

To summarise, it's basically a matter of evaluation ordering issue.

It looks like the model.matrix() function has a higher precedence over
rnorm(100), i.e., outside in rather than inside out in this specific case?
If the inner parts are evaluated first, as in most of the cases, the two
norm(100) expressions will no longer be the same.

I guess it's because they appear the same to model.matrix()? This would
raise another question, how does model.matrix() judges if two variables are
the same on both sides of the ~ sign? By the input literal?

Please clarify.

Thanks,
Victor


On Thu, Aug 3, 2017 at 12:11 PM, Martin Maechler  wrote:

> > Victor Tian 
> > on Thu, 3 Aug 2017 09:49:57 -0400 writes:
>
> > To whom it may concern,
> > I happened to run the following R code just to check the layout of
> the
> > output, but found that the code doesn't work the way I thought it
> should
> > work.
>
> yes, your expectations were wrong.
>
> >> lm(rnorm(100) ~ rnorm(100))
>
> > Call:
> > lm(formula = rnorm(100) ~ rnorm(100))
>
> > Coefficients:
> > (Intercept)
> > -0.07966
>
> > Warning messages:
> > 1: In model.matrix.default(mt, mf, contrasts) :
> > the response appeared on the right-hand side and was dropped
> > 2: In model.matrix.default(mt, mf, contrasts) :
> > problem with term 1 in model.matrix: no columns are assigned
>
>
> > It appears that rnorm(100) produces the same array of numbers on
> both sides
> > of the ~ sign.
>
> Indeed.  And all this has nothing to do with lm()  but rather with
> how formulas in R have been treated probably "forever".
> [I assume not only in R, but rather since the time formulas
>  where introduced into the S language (for "S version 3") a few
>  years before R was born. But I can no longer verify or disprove
>  this assumption.]
>
> Even more revealing may be this:
>
> > f <- rnorm(9) ~ rnorm(9)
> > str(f)
> Class 'formula'  language rnorm(9) ~ rnorm(9)
>   ..- attr(*, ".Environment")=
> > (mm <- model.matrix(f))
>   (Intercept)
> 1   1
> 2   1
> 3   1
> 4   1
> 5   1
> 6   1
> 7   1
> 8   1
> 9   1
> attr(,"assign")
> [1] 0
> Warning messages:
> 1: In model.matrix.default(f) :
>   the response appeared on the right-hand side and was dropped
> 2: In model.matrix.default(f) :
>   problem with term 1 in model.matrix: no columns are assigned
> >
> -
>
> BTW: One of the goals of formulas,  notably in R since they got an
> environment attached, is a clean way to deal with non-standard
> evaluation (=: NSE).
> [ Some of us would claim it is the only clean way to deal with NSE in R,
>   and all new functionality using NSE should use formulas,
>   but recently tidyverse-scholars have claimed to be able to deal
>   with it cleanly w/o the use of formulas, but via "tidy evaluation" ]
>
> Using random expressions in a formula is therefore typically not
> a good idea, because you don't realy know when the terms in the
> formula will be evaluated.
> For lm() and all other good formula-based statistical modeling
> functions, the evaluation happens via model.matrix().
>
> As you've noticed from that warning, model.matrix() tries to
> help the user by checking terms and eliminating those that
> appear on both sides of the '~'.
> This has been documented on the help page [ ?model.matrix ] for
> (almost exactly 14) years, the "Details:" section ending with
>
>  _> By convention, if the response variable also appears on the
>  _> right-hand side of the formula it is dropped (with a warning),
>  _> although interactions involving the term are retained.
>
>
> I hope this explains the issue.
> And yes:  Do *not* use rnorm() in formulas.
>
> Martin
>
> --
> Martin Mächler
> Seminar für Statistik, ETH Zürich //  R Core Team
>



-- 
*Xu Tian*

[[alternative HTML version deleted]]

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

Re: [Rd] rnorm is not truly random used in the lm function

[Martin Maechler]

> Victor Tian 
> on Thu, 3 Aug 2017 09:49:57 -0400 writes:

> To whom it may concern,
> I happened to run the following R code just to check the layout of the
> output, but found that the code doesn't work the way I thought it should
> work.

yes, your expectations were wrong.

>> lm(rnorm(100) ~ rnorm(100))

> Call:
> lm(formula = rnorm(100) ~ rnorm(100))

> Coefficients:
> (Intercept)
> -0.07966

> Warning messages:
> 1: In model.matrix.default(mt, mf, contrasts) :
> the response appeared on the right-hand side and was dropped
> 2: In model.matrix.default(mt, mf, contrasts) :
> problem with term 1 in model.matrix: no columns are assigned


> It appears that rnorm(100) produces the same array of numbers on both 
sides
> of the ~ sign.

Indeed.  And all this has nothing to do with lm()  but rather with
how formulas in R have been treated probably "forever".
[I assume not only in R, but rather since the time formulas
 where introduced into the S language (for "S version 3") a few
 years before R was born. But I can no longer verify or disprove
 this assumption.] 

Even more revealing may be this:

> f <- rnorm(9) ~ rnorm(9)
> str(f)
Class 'formula'  language rnorm(9) ~ rnorm(9)
  ..- attr(*, ".Environment")= 
> (mm <- model.matrix(f))
  (Intercept)
1   1
2   1
3   1
4   1
5   1
6   1
7   1
8   1
9   1
attr(,"assign")
[1] 0
Warning messages:
1: In model.matrix.default(f) :
  the response appeared on the right-hand side and was dropped
2: In model.matrix.default(f) :
  problem with term 1 in model.matrix: no columns are assigned
> 
-

BTW: One of the goals of formulas,  notably in R since they got an
environment attached, is a clean way to deal with non-standard
evaluation (=: NSE).
[ Some of us would claim it is the only clean way to deal with NSE in R,
  and all new functionality using NSE should use formulas,
  but recently tidyverse-scholars have claimed to be able to deal
  with it cleanly w/o the use of formulas, but via "tidy evaluation" ]

Using random expressions in a formula is therefore typically not
a good idea, because you don't realy know when the terms in the
formula will be evaluated.
For lm() and all other good formula-based statistical modeling
functions, the evaluation happens via model.matrix().

As you've noticed from that warning, model.matrix() tries to
help the user by checking terms and eliminating those that
appear on both sides of the '~'.
This has been documented on the help page [ ?model.matrix ] for
(almost exactly 14) years, the "Details:" section ending with

 _> By convention, if the response variable also appears on the
 _> right-hand side of the formula it is dropped (with a warning),
 _> although interactions involving the term are retained.


I hope this explains the issue.
And yes:  Do *not* use rnorm() in formulas.

Martin

--
Martin Mächler 
Seminar für Statistik, ETH Zürich //  R Core Team

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

[Rd] rnorm is not truly random used in the lm function

[Victor Tian]

To whom it may concern,

I happened to run the following R code just to check the layout of the
output, but found that the code doesn't work the way I thought it should
work.

''
> lm(rnorm(100) ~ rnorm(100))

Call:
lm(formula = rnorm(100) ~ rnorm(100))

Coefficients:
(Intercept)
   -0.07966

Warning messages:
1: In model.matrix.default(mt, mf, contrasts) :
  the response appeared on the right-hand side and was dropped
2: In model.matrix.default(mt, mf, contrasts) :
  problem with term 1 in model.matrix: no columns are assigned
"

It appears that rnorm(100) produces the same array of numbers on both sides
of the ~ sign.

It can be further verified by having the same error message if we do x <-
rnorm(100) and lm(x ~ x).

I would expect the two rnorm(100) functions in the lm function return two
different arrays of numbers, but am open to hear reasons from the other
side.

Thanks,

-- 
*Xu Tian*

[[alternative HTML version deleted]]

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

Re: [Rd] Problem compiling R patched and R devel on Ubuntu

[Martin Maechler]

> Berwin A Turlach 
> on Thu, 3 Aug 2017 15:27:56 +0800 writes:

> G'day all,
> since about a week my daily re-compilations of R patched and R devel
> are falling over, i.e. they stop with an error during "make
> check" (while building the 32 bit architecture) on my Ubuntu 16.04.3
> LTS machine.

Dear Berwin,

thanks a lot for the report!

>  Specifically, a test in graphics-Ex.R seems to fail and
> the last lines of graphics-ex.Rout.fail are:

>> ## Extreme outliers; the "FD" rule would take very large number of
> 'breaks': 
>> XXL <- c(1:9, c(-1,1)*1e300)
>> hh <- hist(XXL, "FD") # did not work in R <= 3.4.1; now gives
> warning 
> Warning in hist.default(XXL, "FD") :
> 'breaks = 4.44796e+299' is too large and set to 1e9
> Error in pretty.default(range(x), n = breaks, min.n = 1) : 
> cannot allocate vector of length 11
> Calls: hist -> hist.default -> pretty -> pretty.default
> Execution halted

> My R 3.4.1 installation, the last R patched version that I could
> compile (R version 3.4.1 Patched (2017-07-26 r72974)) and the last R
> devel version that I could compile (R Under development (unstable)
> (2017-07-26 r72974)) 

  ((well, well ... you could also compile later versions.  It was
"only"  'make check' that failed ..))

> give the following results (under the 32bit architecture
> and the 64bit architecture): 

>> XXL <- c(1:9, c(-1,1)*1e300)
>> hh <- hist(XXL, "FD")
> Error in pretty.default(range(x), n = breaks, min.n = 1) : 
> invalid 'n' argument
> In addition: Warning message:
> In pretty.default(range(x), n = breaks, min.n = 1) :
> NAs introduced by coercion to integer range

  [yes, that was the bug; see below]

> Not sure if this is a general problem, or only a problem on my machine.

It is not a problem on 64-bit I think.  This is related to the
bug and bugfix  for PR#17274 
   ( https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17274 )
which I had handled.

Now I see the above, I can well imagine that I had made
assumptions that only worked on my (64-bit) platform.
I'll have a look and will amend the bug fix to also work on
"smaller" platforms - hopefully today.

Martin

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

[Rd] Problem compiling R patched and R devel on Ubuntu

[Berwin A Turlach]

G'day all,

since about a week my daily re-compilations of R patched and R devel
are falling over, i.e. they stop with an error during "make
check" (while building the 32 bit architecture) on my Ubuntu 16.04.3
LTS machine.  Specifically, a test in graphics-Ex.R seems to fail and
the last lines of graphics-ex.Rout.fail are:

  > ## Extreme outliers; the "FD" rule would take very large number of
  'breaks': 
  > XXL <- c(1:9, c(-1,1)*1e300)
  > hh <- hist(XXL, "FD") # did not work in R <= 3.4.1; now gives
  warning 
  Warning in hist.default(XXL, "FD") :
'breaks = 4.44796e+299' is too large and set to 1e9
  Error in pretty.default(range(x), n = breaks, min.n = 1) : 
cannot allocate vector of length 11
  Calls: hist -> hist.default -> pretty -> pretty.default
  Execution halted

My R 3.4.1 installation, the last R patched version that I could
compile (R version 3.4.1 Patched (2017-07-26 r72974)) and the last R
devel version that I could compile (R Under development (unstable)
(2017-07-26 r72974)) give the following results (under the 32bit
architecture and the 64bit architecture):

  > XXL <- c(1:9, c(-1,1)*1e300)
  > hh <- hist(XXL, "FD")
  Error in pretty.default(range(x), n = breaks, min.n = 1) : 
invalid 'n' argument
  In addition: Warning message:
  In pretty.default(range(x), n = breaks, min.n = 1) :
NAs introduced by coercion to integer range

Not sure if this is a general problem, or only a problem on my machine.

Cheers,

Berwin

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