[Rd] grDevices::convertColor and colorRamp(space='Lab') Performance Improvements
`grDevices::convertColor` performance can be improved by 30-300x with small changes to the code. `colorRamp(space='Lab')` uses `convertColor` so it too benefits from substantial performance gains. `convertColor` vectorizes explicitly over the rows of the input color matrix using `apply`. The level-1 patch [1] illustrates a possible minimal set of changes to achieve this with just R matrix and vector operations. The changes consist primarily of switching `if/else` to `ifelse`, `c` to `cbind`, `sum` to `rowSums`, etc. This results in speedups of 30-100x as shown in table 1: to fromApple RGB sRGB CIE RGB XYZ Lab Luv Apple RGBNA 38.355.8 30.3 60.2 56.3 sRGB 38.7NA55.7 36.5 62.9 52.7 CIE RGB45.2 44.4 NA 30.6 51.5 43.1 XYZ73.4 57.569.1NA 92.2 69.0 Lab46.6 56.665.4 72.0 NA 61.3 Luv73.2 107.367.3 105.8 97.8 NA ## Table 1: ## Ratios of `grDevices` to 'level-1' patch speeds for 8000 colors ## from each supported color space to all other supported color spaces. A few incremental changes as detailed in the level-2 patch [2] yield additional performance improvements: to fromApple RGB sRGB CIE RGB XYZ Lab Luv Apple RGBNA 97.1 106.2 89.0 117 83.4 sRGB 92.5NA99.4 86.4 120 76.0 CIE RGB 119.2 184.2 NA 82.2 135 83.4 XYZ 122.3 209.8 140.9NA 171 148.8 Lab 166.4 168.2 255.4 288.5 NA 265.1 Luv 141.7 173.6 279.6 310.1 195NA ## Table 2: ## Ratios of `grDevices` to level-2 patch speeds for 8000 colors ## from each supported color space to all other supported color spaces. Not shown here is that the patched versions of `convertColor` are faster with small inputs as well, though the difference is less marked. I have posted tests on github [3], along with the results of running them on my system [4]. While these tests are not proof that the patches do not change the function other than to make it faster, the tests results combined with the narrow scope of the changes hopefully provides sufficient evidence this is the case. For those wanting to run the tests, installation and testing instructions are on the github landing page for this project [5]. There are some minor (in my opinion) changes in behavior that need to be discussed: * Inputs that would previously stop with errors or work inconsistently now work consistently (e.g. zero-row inputs or inputs containing NA/NaN/Inf). * Column names are consistently set to the color space initials; these were previously inconsistently set / mangled by `c`. These are discussed at length with examples in [6]. It would be possible to preserve the existing behavior, but doing so would require some contortions that serve no other purposes than that. Additionally, in many cases the existing behavior is inconsistent across different input/output color spaces. Finally, most of the differences involve corner case inputs such as those containing NA/NaN/Inf, or zero rows. I am entirely amenable to modify the patches to preserve existing behavior in these cases if that is considered desirable. These patches should be coordinated with #17473 [7], which I found while working on this issue. --- 'level-1' patch: [1]: https://raw.githubusercontent.com/brodieG/grDevices2/level-2/extra/level-1.txt 'level-2' patch: [2]: https://raw.githubusercontent.com/brodieG/grDevices2/level-2/extra/level-2.txt Tests on github, and the result of running them: [3]: https://github.com/brodieG/grDevices2/blob/level-2/tests/convertColor.R [4]: https://raw.githubusercontent.com/brodieG/grDevices2/level-2/tests/convertColor.Rout Github landing page for this project: [5]: https://github.com/brodieG/grDevices2 Discussion of differences introduces by patches: [6]: https://htmlpreview.github.io/?https://raw.githubusercontent.com/brodieG/grDevices2/level-2/extra/differences.html Indirectly related bugzilla issue #17473: [7]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17473 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How do I set a compile flag _WIN32_WINNT=0x600 in Makevars.Win
Sorry for bothering you I am trying to build the R grpc package on windows: https://github.com/nfultz/grpc against an MSYS2 build of grpc. when running devtools::install() I am getting the following error: C:/msys64/mingw64/include/grpc/impl/codegen/port_platform.h:47:2: error: #error "Please compile grpc with _WIN32_WINNT of at least 0x600 (aka Windows Vista)" #error \ ^ Which, if I am correct asks me to set _WIN32_WINNT=0x600 My Makevars.Win looks as follows: PKG_CPPFLAGS=-IC:/msys64/mingw64/include PKG_LIBS=-LC:/msys64/mingw64/lib -lgrpc What should I do? Have a great day best regards Witek -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R grpc
:) Did you missed the "MS-Windows" in my e-mail?
On Tue, 2 Oct 2018 at 21:28, Rui Barradas wrote:
>
> Hello,
>
> Do you really need a prebuild binary? Wouldn't this do it?
>
> devtools::install_github("nfultz/grpc")
>
>
> Hope this helps,
>
> Rui Barradas
>
> Às 20:14 de 02/10/2018, Witold E Wolski escreveu:
> > Hello,
> >
> > I am looking for a prebuild - binary MS Windows version of the R grpc
> > package
> > https://github.com/nfultz/grpc
> >
> > best regards
> > Witek
> >
> >
--
Witold Eryk Wolski
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R grpc
Hello,
Do you really need a prebuild binary? Wouldn't this do it?
devtools::install_github("nfultz/grpc")
Hope this helps,
Rui Barradas
Às 20:14 de 02/10/2018, Witold E Wolski escreveu:
Hello,
I am looking for a prebuild - binary MS Windows version of the R grpc package
https://github.com/nfultz/grpc
best regards
Witek
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R grpc
Hello, I am looking for a prebuild - binary MS Windows version of the R grpc package https://github.com/nfultz/grpc best regards Witek -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] maximum matrix size
Does this help a little? https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Long-vectors One thing I seem to remember but cannot find a reference for is that long vectors can only be passed to .Call calls, not C/Fortran. I remember rewriting .C() in my WGCNA package to .Call for this very reason but perhaps the restriction has been removed. Peter On Tue, Oct 2, 2018 at 9:43 AM Therneau, Terry M., Ph.D. via R-devel wrote: > > I am now getting the occasional complaint about survival routines that are > not able to > handle big data. I looked in the manuals to try and update my understanding > of max > vector size, max matrix, max data set, etc; but it is either not there or I > missed it (the > latter more likely). Is it still .Machine$integer.max for everything? > Will that > change? Found where? > > I am going to need to go through the survival package and put specific checks > in front > some or all of my .Call() statements, in order to give a sensible message > whenever a > bounday is struck. A well meaning person just posted a suggested "bug fix" > to the github > source of one routine where my .C call allocates a scratch vector, suggesting > "resid = > double( as.double(n) *nvar)" to prevent a "NA produced by integer overflow" > message, in > the code below. A fix is obvously not quite that easy :-) > > resid <- .C(Ccoxscore, as.integer(n), > as.integer(nvar), > as.double(y), > x=as.double(x), > as.integer(newstrat), > as.double(score), > as.double(weights[ord]), > as.integer(method=='efron'), > resid= double(n*nvar), > double(2*nvar))$resid > > Terry T. > > > [[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] Problem with parseData
Thanks! Please let us know when it is in the released version of R.
Barbara
Tomas Kalibera wrote on 10/2/18 6:37 AM:
> The fix is now in R-devel, 75386. I have not ported to R-patched,
> because the fix breaks two packages which are working around this bug
> (and to my knowledge without having reported it before). So thanks
> again for the report!
>
> Best
> Tomas
>
> On 08/16/2018 10:06 AM, Tomas Kalibera wrote:
>> Dear Barbara,
>>
>> thank you for the report. This is something to be fixed in R - I am
>> now testing a patch that adds the extra node for the equality
>> assignment expression.
>>
>> Best,
>> Tomas
>>
>> On 07/30/2018 05:35 PM, Barbara Lerner wrote:
>>> Hi,
>>>
>>> I have run into a problem with parseData from the utils package. When
>>> an assignment is done with = instead of <-, the information provided by
>>> parseData does not include an entry for the assignment.
>>>
>>> For this input, stored in file "BadPosition.R":
>>>
>>> y <- 5
>>> foo = 7
>>>
>>> And running this code:
>>>
>>> parsed <- parse("BadPosition.R", keep.source=TRUE)
>>> parsedData <- utils::getParseData (parsed, includeText=TRUE)
>>> print(paste("parseData =", parsedData))
>>>
>>> I get the following output:
>>>
>>> [1] "parseData = c(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)"
>>> [2] "parseData = c(1, 1, 1, 3, 6, 6, 1, 1, 5, 7, 7)"
>>> [3] "parseData = c(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)"
>>> [4] "parseData = c(6, 1, 1, 4, 6, 6, 3, 3, 5, 7, 7)"
>>> [5] "parseData = c(7, 1, 3, 2, 4, 5, 10, 12, 11, 13, 14)"
>>> [6] "parseData = c(0, 3, 7, 7, 5, 7, 12, 0, 0, 14, 0)"
>>> [7] "parseData = c(\"expr\", \"SYMBOL\", \"expr\", \"LEFT_ASSIGN\",
>>> \"NUM_CONST\", \"expr\", \"SYMBOL\", \"expr\", \"EQ_ASSIGN\",
>>> \"NUM_CONST\", \"expr\")"
>>> [8] "parseData = c(FALSE, TRUE, FALSE, TRUE, TRUE, FALSE, TRUE, FALSE,
>>> TRUE, TRUE, FALSE)"
>>> [9] "parseData = c(\"y <- 5\", \"y\", \"y\", \"<-\", \"5\", \"5\",
>>> \"foo\", \"foo\", \"=\", \"7\", \"7\")"
>>>
>>> Notice how there is an entry for "y <- 5" beginning on line 1,
>>> column 1,
>>> ending at line 1, column 6, but there is no analogous entry for "foo
>>> = 7".
>>>
>>> I am running R 3.5.0 on a Mac running 10.12.6.
>>>
>>> Thanks for your help and please let me know if you need any further
>>> information.
>>>
>>> Barbara
>>>
>>
>
--
Barbara Lerner
Associate Professor
Computer Science Department
Mount Holyoke College
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] maximum matrix size
On Tue, Oct 2, 2018 at 9:43 AM Therneau, Terry M., Ph.D. via R-devel wrote: > > I am now getting the occasional complaint about survival routines that are > not able to > handle big data. I looked in the manuals to try and update my understanding > of max > vector size, max matrix, max data set, etc; but it is either not there or I > missed it (the > latter more likely). Is it still .Machine$integer.max for everything? > Will that > change? Found where? FWIW, this is the reference I've decided to follow for matrixStats: "* For now, keep 2^31-1 limit on matrix rows and columns." from Slide 5 in Luke Tierney's 'Some new developments for the R engine', June 24, 2012 (http://homepage.stat.uiowa.edu/~luke/talks/purdue12.pdf). /Henrik > > I am going to need to go through the survival package and put specific checks > in front > some or all of my .Call() statements, in order to give a sensible message > whenever a > bounday is struck. A well meaning person just posted a suggested "bug fix" > to the github > source of one routine where my .C call allocates a scratch vector, suggesting > "resid = > double( as.double(n) *nvar)" to prevent a "NA produced by integer overflow" > message, in > the code below. A fix is obvously not quite that easy :-) > > resid <- .C(Ccoxscore, as.integer(n), > as.integer(nvar), > as.double(y), > x=as.double(x), > as.integer(newstrat), > as.double(score), > as.double(weights[ord]), > as.integer(method=='efron'), > resid= double(n*nvar), > double(2*nvar))$resid > > Terry T. > > > [[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
[Rd] maximum matrix size
I am now getting the occasional complaint about survival routines that are not able to handle big data. I looked in the manuals to try and update my understanding of max vector size, max matrix, max data set, etc; but it is either not there or I missed it (the latter more likely). Is it still .Machine$integer.max for everything? Will that change? Found where? I am going to need to go through the survival package and put specific checks in front some or all of my .Call() statements, in order to give a sensible message whenever a bounday is struck. A well meaning person just posted a suggested "bug fix" to the github source of one routine where my .C call allocates a scratch vector, suggesting "resid = double( as.double(n) *nvar)" to prevent a "NA produced by integer overflow" message, in the code below. A fix is obvously not quite that easy :-) resid <- .C(Ccoxscore, as.integer(n), as.integer(nvar), as.double(y), x=as.double(x), as.integer(newstrat), as.double(score), as.double(weights[ord]), as.integer(method=='efron'), resid= double(n*nvar), double(2*nvar))$resid Terry T. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Relevel confusing with numeric value
In a word, no. It is behaving as documented and adding a warning would just
confuse others who have been using the feature as intended.
This belongs in the same bin as "as.integer(f) vs as.integer(as.character(f))"
and "x[f] vs. x[as.character(f)]"
-pd
> On 2 Oct 2018, at 17:18 , Emil Bode wrote:
>
> Something that bit me:
> The function relevel takes a factor, and a reference level to be promoted to
> the first place.
> If “ref” is a character this level is promoted, if it’s a numeric the
> “ref”-th level is promoted.
> Which turns out to be very confusing if you have factor with numeric values
> (e.g. when reading in a csv with some dirty numeric columns and
> stringsAsFactors TRUE)
> For example:
>
> set.seed(1)
> test <- data.frame(n=sample(c(1:100, letters[1:10]), size=90))
> test$n <- relevel(test$n, 50)
> print(levels(test$n))
>
> gives “62” as the first level.
>
> Could we make something like this an error, or at least issue a warning?
> Also because some other functions automatically coerce, factor(…,
> levels=1:100) and levels(test$n) <- 1:100 works fine.
> So this is maybe the most confusing: relevel(factor(1:10, levels = -10:20),
> 15) gives “4” as the first level
>
> For now I’ve thought of 2 possible implementations, that could be inserted in
> stats::relevel.factor(), just before is.character(ref):
>
> if(is.numeric(ref) && ref %in% lev)
>warning('Provided numeric reference, note that this will promote the ',
> ref, 'th value, not level with value "', ref, '"!')
>
> or
>
> if(is.numeric(ref) && any(!is.na(suppressWarnings(as.numeric(lev)
>warning('Provided numeric reference, note that this will promote the ',
> ref, 'th value, not level with value "', ref, '"!')
>
>
> Best regards,
> Emil Bode
>
> Data-analyst
>
> +31 6 43 83 89 33
> emil.b...@dans.knaw.nl
>
> DANS: Netherlands Institute for Permanent Access to Digital Research Resources
> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
> i...@dans.knaw.nl |
> dans.knaw.nl
> DANS is an institute of the Dutch Academy KNAW and funding
> organisation NWO
[Rd] Relevel confusing with numeric value
Something that bit me:
The function relevel takes a factor, and a reference level to be promoted to
the first place.
If “ref” is a character this level is promoted, if it’s a numeric the “ref”-th
level is promoted.
Which turns out to be very confusing if you have factor with numeric values
(e.g. when reading in a csv with some dirty numeric columns and
stringsAsFactors TRUE)
For example:
set.seed(1)
test <- data.frame(n=sample(c(1:100, letters[1:10]), size=90))
test$n <- relevel(test$n, 50)
print(levels(test$n))
gives “62” as the first level.
Could we make something like this an error, or at least issue a warning?
Also because some other functions automatically coerce, factor(…, levels=1:100)
and levels(test$n) <- 1:100 works fine.
So this is maybe the most confusing: relevel(factor(1:10, levels = -10:20), 15)
gives “4” as the first level
For now I’ve thought of 2 possible implementations, that could be inserted in
stats::relevel.factor(), just before is.character(ref):
if(is.numeric(ref) && ref %in% lev)
warning('Provided numeric reference, note that this will promote the ',
ref, 'th value, not level with value "', ref, '"!')
or
if(is.numeric(ref) && any(!is.na(suppressWarnings(as.numeric(lev)
warning('Provided numeric reference, note that this will promote the ',
ref, 'th value, not level with value "', ref, '"!')
Best regards,
Emil Bode
Data-analyst
+31 6 43 83 89 33
emil.b...@dans.knaw.nl
DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
i...@dans.knaw.nl |
dans.knaw.nl
DANS is an institute of the Dutch Academy KNAW and funding
organisation NWO
Re: [Rd] Problem with parseData
The fix is now in R-devel, 75386. I have not ported to R-patched,
because the fix breaks two packages which are working around this bug
(and to my knowledge without having reported it before). So thanks again
for the report!
Best
Tomas
On 08/16/2018 10:06 AM, Tomas Kalibera wrote:
Dear Barbara,
thank you for the report. This is something to be fixed in R - I am
now testing a patch that adds the extra node for the equality
assignment expression.
Best,
Tomas
On 07/30/2018 05:35 PM, Barbara Lerner wrote:
Hi,
I have run into a problem with parseData from the utils package. When
an assignment is done with = instead of <-, the information provided by
parseData does not include an entry for the assignment.
For this input, stored in file "BadPosition.R":
y <- 5
foo = 7
And running this code:
parsed <- parse("BadPosition.R", keep.source=TRUE)
parsedData <- utils::getParseData (parsed, includeText=TRUE)
print(paste("parseData =", parsedData))
I get the following output:
[1] "parseData = c(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)"
[2] "parseData = c(1, 1, 1, 3, 6, 6, 1, 1, 5, 7, 7)"
[3] "parseData = c(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)"
[4] "parseData = c(6, 1, 1, 4, 6, 6, 3, 3, 5, 7, 7)"
[5] "parseData = c(7, 1, 3, 2, 4, 5, 10, 12, 11, 13, 14)"
[6] "parseData = c(0, 3, 7, 7, 5, 7, 12, 0, 0, 14, 0)"
[7] "parseData = c(\"expr\", \"SYMBOL\", \"expr\", \"LEFT_ASSIGN\",
\"NUM_CONST\", \"expr\", \"SYMBOL\", \"expr\", \"EQ_ASSIGN\",
\"NUM_CONST\", \"expr\")"
[8] "parseData = c(FALSE, TRUE, FALSE, TRUE, TRUE, FALSE, TRUE, FALSE,
TRUE, TRUE, FALSE)"
[9] "parseData = c(\"y <- 5\", \"y\", \"y\", \"<-\", \"5\", \"5\",
\"foo\", \"foo\", \"=\", \"7\", \"7\")"
Notice how there is an entry for "y <- 5" beginning on line 1, column 1,
ending at line 1, column 6, but there is no analogous entry for "foo
= 7".
I am running R 3.5.0 on a Mac running 10.12.6.
Thanks for your help and please let me know if you need any further
information.
Barbara
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested Patch: Adding commas to list of packages after R CMD check
> Duncan Murdoch
> on Tue, 18 Sep 2018 16:23:47 -0400 writes:
> On 18/09/2018 2:16 PM, Marcel Ramos wrote:
> > Dear R-devs,
> >
> >
> > Scenario:
> >
> > When checking a package via `R CMD check package_tar.ball`, required /
> > suggested packages may be missing. R subsequently returns a list of
> > packages that are missing (delimited by spaces).
> >
> > Example:
> >
> > ```
> > R CMD check glmSparseNet_0.99.13.tar.gz
> > * using log directory '/home/ubuntu/Bioconductor/glmSparseNet.Rcheck'
> > * using R Under development (unstable) (2018-06-06 r74855)
> > * using platform: x86_64-pc-linux-gnu (64-bit)
> > * using session charset: UTF-8
> > * checking for file 'glmSparseNet/DESCRIPTION' ... OK
> > * checking extension type ... Package
> > * this is package 'glmSparseNet' version '0.99.13'
> > * package encoding: UTF-8
> > * checking package namespace information ... OK
> > * checking package dependencies ... ERROR
> > Packages required but not available:
> >'MultiAssayExperiment' 'glmnet' 'SummarizedExperiment' 'STRINGdb'
> >'biomaRt' 'futile.logger' 'sparsebn' 'sparsebnUtils' 'forcats'
> >'dplyr' 'readr' 'ggplot2' 'ggfortify' 'reshape2' 'rlang' 'loose.rock'
> >
> > Packages suggested but not available:
> >'testthat' 'knitr' 'rmarkdown' 'survcomp' 'pROC' 'devtools'
> >'VennDiagram' 'BiocStyle' 'curatedTCGAData'
> >
> > VignetteBuilder package required for checking but not installed: 'knitr'
> >
> > The suggested packages are required for a complete check.
> > Checking can be attempted without them by setting the environment
> > variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
> >
> > See section 'The DESCRIPTION file' in the 'Writing R Extensions'
> > manual.
> > * DONE
> >
> > Status: 1 ERROR
> > See
> >'/home/ubuntu/Bioconductor/glmSparseNet.Rcheck/00check.log'
> > for details.
> > ```
> >
> >
> > Suggested Patch:
> >
> > To return a list of missing dependencies delimited by a comma and a space
> > (", ") so to make it easier for the user to copy and paste this list.
> > This would be especially helpful when the list of missing dependencies is
> > extensive.
Your patch to *both* internal functions is small and in that
respect very nice, but it would effect really many of the R CMD
check messages.
I had been testing a modularized version of your proposed change
which only changes the defaults of pretty_format2(.) which
indeed is most often used in the context of listing package names.
In addition, I also did use regular quotes instead of the fancy
quotes there.
This has been committed to R-devel (accidentally already
together with the \Sexpr{} related bug fix) in svn rev 75378, last Friday.
> This seems like a reasonable suggestion, considering how easy it is to do.
>
> Another suggestion would be to (optionally) automatically install
> missing dependencies. I think the devtools::install_deps function will
> do that. (I don't use it, I have a homebrewed function for that purpose.)
> Duncan Murdoch
The new facilities (in R-devel only, by Luke Tierney) with NEWS entries
• Many ‘package not found’ errors are now signaled as errors of
class packageNotFoundError.
• As an experimental feature, when loadNamespace() fails because
the requested package is not available the error is initially
signaled with a retry_loadNamespace restart available. This
allows a calling handler to try to install the package and continue.
indeed should "easily" allow to go in that direction.
Thank you, Marcel and Duncan!
Martin
>
> >
> >
> > Example output:
> >
> > ```
> > R CMD check glmSparseNet_0.99.13.tar.gz
> > * using log directory '/home/ubuntu/Bioconductor/glmSparseNet.Rcheck'
> > * using R Under development (unstable) (2018-09-18 r75322)
> > * using platform: x86_64-pc-linux-gnu (64-bit)
> > * using session charset: UTF-8
> > * checking for file 'glmSparseNet/DESCRIPTION' ... OK
> > * checking extension type ... Package
> > * this is package 'glmSparseNet' version '0.99.13'
> > * package encoding: UTF-8
> > * checking package namespace information ... OK
> > * checking package dependencies ... ERROR
> > Packages required but not available:
> >'MultiAssayExperiment', 'glmnet', 'SummarizedExperiment', 'STRINGdb',
> >'biomaRt', 'futile.logger', 'sparsebn', 'sparsebnUtils', 'forcats',
> >'dplyr', 'readr', 'ggplot2', 'ggfortify', 'reshape2', 'stringr',
> >'rlang', 'loose.rock'
> >
> > Packages suggested but not available:
> >'testthat', 'knitr', 'rmarkdown', 'survcomp', 'pROC', 'devtools',
> >'roxygen2', 'VennDiagram', 'BiocStyle', 'curatedTCGAData'
> >
> > VignetteBuilder package required for checking but not installed: 'knitr'
> >
> > The suggested packages are required for a complete check.
> > Checking can be attempted without them by setting the environment
> > variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
> >
> > See section 'The DESCRIPTION file' in the 'Writing R
