Closed topepo closed 5 years ago
yes, I wanted to make another release very soon, I was waiting for the R journal manuscript to be published, to include it as a vignette, but then I did not really find time to actually do it.
I just tried to submit version 0.2.0 to CRAN, but it gets stuck with recipes in the reverse dependencies check:
Recipes does not install, what should I tell the CRAN maintainers?
I assume that this means that, with the new version of dimRed
, the CRAN version of recipes
will not install. I'll look into it today (which will mostly be spent trying to to get pcaL1
installed from source).
I think that we need more information from the CRAN folks. win-builder
only shows:
Results:
Check status summary:
ERROR OK
Source packages 0 1
Reverse depends 1 0
Check results summary:
dimRed ... OK
rdepends_recipes ... ERROR
* checking whether package ‘recipes’ can be installed ... [3s/3s] ERROR
Check results changes:
Package: recipes
Check: whether package can be installed
New result: ERROR
I don't see a file or directory that has the details.
There are no baseline issues with recipes
.
I also tried using revdepcheck
and had no errors:
> library(revdepcheck)
> revdep_check()
── INIT ─────────────────────────────────────────────────── Computing revdeps ──
── INSTALL ─────────────────────────────────────────────────────── 2 versions ──
Installing CRAN version of dimRed
Installing DEV version of dimRed
Installing 4 packages: CVST, doParallel, iterators, kernlab
── CHECK ───────────────────────────────────────────────────────── 1 packages ──
✔ recipes 0.1.3 ── E: 0 | W: 2 | N: 0
OK: 1
BROKEN: 0
Total time: 3 min
── REPORT ──────────────────────────────────────────────────────────────────────
Writing summary to 'revdep/README.md'
Writing problems to 'revdep/problems.md'
> sessioninfo::session_info()
─ Session info ───────────────────────────────────────────────────────────────────────────────────────────────────────
setting value
version R version 3.5.0 (2018-04-23)
os macOS High Sierra 10.13.6
system x86_64, darwin15.6.0
ui X11
language (EN)
collate en_US.UTF-8
ctype en_US.UTF-8
tz America/New_York
date 2018-10-12
─ Packages ───────────────────────────────────────────────────────────────────────────────────────────────────────────
! package * version date lib source
assertthat 0.2.0 2017-04-11 [1] CRAN (R 3.5.0)
backports 1.1.2 2017-12-13 [1] CRAN (R 3.5.0)
base64enc 0.1-3 2015-07-28 [1] CRAN (R 3.5.0)
bit 1.1-14 2018-05-29 [1] CRAN (R 3.5.0)
bit64 0.9-7 2017-05-08 [1] CRAN (R 3.5.0)
blob 1.1.1 2018-03-25 [1] CRAN (R 3.5.0)
V callr 3.0.0.9000 2018-10-12 [1] Github (r-lib/callr@d0ea2b6)
V cli 1.0.1 2018-10-12 [1] Github (r-lib/cli@56538e3)
clisymbols 1.2.0 2017-05-21 [1] CRAN (R 3.5.0)
crancache 0.0.0.9000 2018-06-25 [1] Github (r-lib/crancache@e2185c7)
cranlike 1.0.1.9001 2018-06-25 [1] Github (r-hub/cranlike@3c72c14)
crayon 1.3.4 2017-09-16 [1] CRAN (R 3.5.0)
curl 3.2 2018-03-28 [1] CRAN (R 3.5.0)
DBI 1.0.0 2018-05-02 [1] CRAN (R 3.5.0)
debugme 1.1.0 2017-10-22 [1] CRAN (R 3.5.0)
desc 1.2.0 2018-10-12 [1] Github (r-lib/desc@7c12d36)
V digest 0.6.17 2018-10-10 [1] CRAN (R 3.5.0)
glue 1.3.0 2018-10-09 [1] Github (tidyverse/glue@4e74901)
gmailr 0.7.1 2016-04-12 [1] CRAN (R 3.5.0)
highr 0.7 2018-06-09 [1] CRAN (R 3.5.0)
hms 0.4.2 2018-03-10 [1] CRAN (R 3.5.0)
httr 1.3.1 2017-08-20 [1] CRAN (R 3.5.0)
jsonlite 1.5 2017-06-01 [1] CRAN (R 3.5.0)
knitr 1.20 2018-02-20 [1] CRAN (R 3.5.0)
magrittr 1.5 2014-11-22 [1] CRAN (R 3.5.0)
memoise 1.1.0 2017-04-21 [1] CRAN (R 3.5.0)
parsedate 1.1.3 2017-03-02 [1] CRAN (R 3.5.0)
pkgbuild 1.0.1.9000 2018-10-12 [1] Github (r-lib/pkgbuild@446d70c)
pkgconfig 2.0.2 2018-08-16 [1] CRAN (R 3.5.0)
prettyunits 1.0.2 2015-07-13 [1] CRAN (R 3.5.0)
processx 3.2.0.9000 2018-10-07 [1] Github (r-lib/processx@8374340)
progress 1.2.0.9000 2018-10-12 [1] Github (gaborcsardi/progress@54a14f5)
ps 1.1.0 2018-08-10 [1] CRAN (R 3.5.0)
R6 2.3.0 2018-10-04 [1] CRAN (R 3.5.0)
rappdirs 0.3.1 2016-03-28 [1] CRAN (R 3.5.0)
rcmdcheck 1.3.0.9000 2018-10-12 [1] Github (r-lib/rcmdcheck@6a3afa2)
Rcpp 0.12.19.2 2018-10-08 [1] Github (RcppCore/Rcpp@b7dc5f1)
remotes 2.0.0.9000 2018-10-12 [1] Github (r-lib/remotes@15e515b)
revdepcheck * 1.0.0.9000 2018-10-12 [1] Github (r-lib/revdepcheck@1a43564)
rlang 0.2.99.0000 2018-10-12 [1] Github (r-lib/rlang@30d6671)
rprojroot 1.3-2 2018-01-03 [1] CRAN (R 3.5.0)
RSQLite 2.1.1 2018-05-06 [1] CRAN (R 3.5.0)
sessioninfo 1.1.0 2018-09-25 [1] CRAN (R 3.5.0)
whoami 1.2.0 2018-09-11 [1] CRAN (R 3.5.0)
withr 2.1.2 2018-03-15 [1] CRAN (R 3.5.0)
xopen 1.0.0 2018-09-17 [1] CRAN (R 3.5.0)
yaml 2.2.0 2018-07-25 [1] CRAN (R 3.5.0)
[1] /Library/Frameworks/R.framework/Versions/3.5/Resources/library
V ── Loaded and on-disk version mismatch.
It seems that there are timeout issues with my package I have to solve first. CRAN only lets the package build for 10 minutes before aborting. The new vignette I added added an extra 250s to build time :-)
I don't know if you want to got this route, but I like to have real examples that take longer to run. tidyposterior
has an overall flag for running the file. See this (CRAN) versus [this]() (pkgdown
site).
Do you know if the vignette published on CRAN is the one I send, or the one that is rebuilt during testing? Then I could simply cheat CRAN into building a dummy.
They publish what we give them but run the code for testing (I had to look it up):
Note that since you build vignettes locally, CRAN only receives the html/pdf and the source code. However, CRAN does not re-build the vignette. It only checks that the code is runnable (by running it). This means that any packages used by the vignette must be declared in the
DESCRIPTION
. But this also means that you can use Rmarkdown (which uses pandoc) even though CRAN doesn’t have pandoc installed.
This is really frustrating: I cut down a lot of test time and did a bad hack to avoid rebuilding of the vignette, but winbuilder time went from 600s up to 750s, even though the timings for tests went down, maybe I have to resubmit at midnight (or wait until the next full moon) when there is less congestion on the server.
What branch are you working from?
the version I sent to CRAN is on develop---minus the version number increase.
I get the same problem with
test_dimRedData.R:32: failure: misc functions
nrow(Iris) not equal to 150.
target is NULL, current is numeric
Not sure what to do there.
I suggest using skip_on_cran()
for the high level function, AutoEncoder, and NNMF tests to solve the time problem.
win-builder takes 350s, this has to be enough, it used to take 1000s.
Sorry for the delay, but this was really frustrating and I had some other stuff to do besides jumping through CRAN-hoops. dimRed just passed the pretests on CRAN, but the reverse dependency check for recipes fails again:
https://win-builder.r-project.org/incoming_pretest/dimRed_0.2.0_20181106_212055/
I cannot find any useful information in the logs.
EDIT: I just installed recipes master without any problems, some of the tests fail:
OK: 1149
Failed: 5
Warnings: 9
Skipped: 0
I would email cran-submissions@r-project.org
(or post to R-devel) and ask for advice. Was this an issue from a CRAN submission (or just from pre-testing)?
edit: changed email
CRAN submission and it's the reverse dependency check that fails. I just wrote to the CRAN maintainers, let's see if they have any suggestions.
Can you try adding this version requirement to the description file: Matrix (>= 1.2-15)
and try win-builder again?
you mean resubmit? Win-builder worked just fine.
I was thinking to test with. I'm starting to think that this issue is stringi
; it has never really built on the same specific architecture that dimRed
fails on.
Finally on CRAN! Sorry for the delay. I will reopen in case CRAN catches fire due to dimRed.
Did CRAN catch fire? I see 0.2.1
from today on there, and a Biobase
dependency? But I don't see that anywhere in the github code. Is that new? Additionally, when I try and install:
> install.packages("dimRed")
Warning in install.packages :
dependency ‘Biobase’ is not available
Travis can't seem to find it either 😢 https://travis-ci.org/tidymodels/recipes/jobs/452987202#L3350
Did ripley repackage your package and reupload? I downloaded the tar.gz
of 0.2.1
and this is the DESCRIPTION file. Note the "Packaged" line near the bottom. The 0.2.0
release says your name.
(Maybe because NMF
suggests them?)
Package: dimRed
Title: A Framework for Dimensionality Reduction
Version: 0.2.1
Authors@R: c(
person("Guido", "Kraemer",
email = "gkraemer@bgc-jena.mpg.de",
role = c("aut", "cre"))
)
Description: A collection of dimensionality reduction
techniques from R packages and a common
interface for calling the methods.
Depends: R (>= 3.0.0), DRR
Imports: NMF, magrittr, methods, bigmemory, Biobase
Suggests: cccd, MASS, Matrix, RANN, RSpectra, Rtsne, coRanking,
diffusionMap, energy, fastICA, ggplot2, graphics, igraph,
keras, kernlab, knitr, lle, loe, optimx, pcaL1, pcaPP,
reticulate, rgl, scales, scatterplot3d, stats, tensorflow,
testthat, tidyr, tinytex, umap, vegan
VignetteBuilder: knitr
License: GPL-3 | file LICENSE
URL: https://github.com/gdkrmr/dimRed
LazyData: true
Encoding: UTF-8
Collate: 'dimRedMethod-class.R' 'misc.R' 'dimRedData-class.R'
'dimRedResult-class.R' 'autoencoder.R' 'dataSets.R' 'diffmap.R'
'dimRed.R' 'drr.R' 'embed.R' 'fastica.R' 'get_info.R'
'graph_embed.R' 'hlle.R' 'isomap.R' 'kpca.R' 'l1pca.R' 'leim.R'
'lle.R' 'loe.R' 'mds.R' 'mixColorSpaces.R' 'nmds.R' 'nnmf.R'
'pca.R' 'plot.R' 'quality.R' 'rotate.R' 'soe.R' 'tsne.R'
'umap.R'
RoxygenNote: 6.1.0
NeedsCompilation: yes
Packaged: 2018-11-09 11:51:39 UTC; ripley
Author: Guido Kraemer [aut, cre]
Maintainer: Guido Kraemer <gkraemer@bgc-jena.mpg.de>
Repository: CRAN
Date/Publication: 2018-11-09 16:03:21 UTC
Having an import of Biobase
is a big potential problem for recipes
. We've have to give additional code for people to get that package before installing recipes
since install.packages
won't install it.
Was that discussed anywhere?
Yes, CRAN caught fire.
Yes, Brian Ripley did a hack to fix this and bumped the version number to 0.2.1
Yes, I am really not happy about importing bigmemory
and Biobase
. I would really like to fix this. The main problem is that I have not found a way to reproduce this on my machine or travis so I am flying blind.
My current working hypothesis is that dimRed
does not call setGeneric("nrow")
, which never was a problem until (through NMF) it depended somehow on BiocGenerics
which does that call to setGeneric("nrow")
.
I don't understand how I can make this reproducible on my ubuntu machine.
Here is the relevant part of Brian Ripleys mail:
See https://cran.r-project.org/web/checks/check_results_dimRed.html The crux is
** testing if installed package can be loaded Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Error: package or namespace load failed for ‘dimRed’: Function found when exporting methods from the namespace ‘dimRed’ which is not S4 generic: ‘nrow’ Error: loading failed Execution halted ERROR: loading failed
The failures come from checking with _R_CHECK_INSTALLDEPENDS=true, part of --as-cran. It appears that you intended to use the nrow() generic from bigmemory, but did not import it. And something else in the package depends on the Biobase namespace. (These are put on the search path by NMF, but you cannot rely on that.)
I tried Brian Ripley's suggestion and v0.2.0 keeps passing on my machine and on travis.
What about:
library("NMF")
/require("NMF")
There's a pretty standard way to do that I think. It uses requireNamespace()
. Here's an example https://github.com/DavisVaughan/nodegraph/blob/master/R/plot.R
(I don't yet put the package in Suggests but you should for NMF)
I am usually doing exactly this, see here, but there was a problem with NMF
so it had to be moved to Depends
, see here.
@topepo on current develop I have moved NMF
back to suggests and everything seems to work fine on my computer, on travis, and winbuilder (except oldrelease which gives an unrelated error), can you please check.
I have a recipes
branch that has your develop
branch in its remotes and has no trace of bigmemory
or Biobase
in the travis file. You current devel version doesn't have a direct Biobase
dependency (although NMF
has it as suggests).
Despite that, travis failed prior to running R CMD check
with:
$ Rscript -e 'deps <- devtools::dev_package_deps(dependencies = NA);devtools::install_deps(dependencies = TRUE);if (!all(deps$package %in% installed.packages())) { message("missing: ", paste(setdiff(deps$package, installed.packages()), collapse=", ")); q(status = 1, save = "no")}'
abind (NA -> 1.4-5 ) [CRAN]
BH (NA -> 1.66.0-1 ) [CRAN]
bigmemory (NA -> 4.5.33 ) [CRAN]
bigmemory... (NA -> 0.1.3 ) [CRAN]
bindr (NA -> 0.1.1 ) [CRAN]
bindrcpp (NA -> 0.2.2 ) [CRAN]
broom (NA -> 0.5.0 ) [CRAN]
covr (NA -> 3.2.1 ) [CRAN]
CVST (NA -> 0.2-2 ) [CRAN]
ddalpha (NA -> 1.3.4 ) [CRAN]
DEoptimR (NA -> 1.0-8 ) [CRAN]
dplyr (NA -> 0.7.8 ) [CRAN]
DRR (NA -> 0.0.3 ) [CRAN]
evaluate (NA -> 0.12 ) [CRAN]
generics (NA -> 0.0.1 ) [CRAN]
geometry (NA -> 0.3-6 ) [CRAN]
gower (NA -> 0.1.2 ) [CRAN]
highr (NA -> 0.7 ) [CRAN]
htmltools (NA -> 0.3.6 ) [CRAN]
igraph (NA -> 1.2.2 ) [CRAN]
kernlab (NA -> 0.9-27 ) [CRAN]
knitr (NA -> 1.20 ) [CRAN]
lubridate (NA -> 1.7.4 ) [CRAN]
magic (NA -> 1.5-9 ) [CRAN]
markdown (NA -> 0.8 ) [CRAN]
pkgconfig (NA -> 2.0.2 ) [CRAN]
plogr (NA -> 0.2.0 ) [CRAN]
pls (NA -> 2.7-0 ) [CRAN]
praise (NA -> 1.0.0 ) [CRAN]
purrr (NA -> 0.2.5 ) [CRAN]
recipes (NA -> 0.1.3 ) [CRAN]
rex (NA -> 1.1.2 ) [CRAN]
rmarkdown (NA -> 1.10 ) [CRAN]
robustbase (NA -> 0.93-3 ) [CRAN]
sfsmisc (NA -> 1.1-2 ) [CRAN]
testthat (NA -> 2.0.1 ) [CRAN]
tidyr (NA -> 0.8.2 ) [CRAN]
tidyselect (NA -> 0.2.5 ) [CRAN]
timeDate (NA -> 3043.102 ) [CRAN]
tinytex (NA -> 0.9 ) [CRAN]
xfun (NA -> 0.4 ) [CRAN]
yaml (NA -> 2.2.0 ) [CRAN]
rsample (NA -> 7dda4194a...) [GitHub]
dimRed (NA -> 7c27038e7...) [GitHub]
Skipping 1 packages not available: Biobase
Installing 43 packages: abind, BH, bigmemory, bigmemory.sri, bindr, bindrcpp, Biobase, broom, covr, CVST, ddalpha, DEoptimR, dplyr, DRR, evaluate, generics, geometry, gower, highr, htmltools, igraph, kernlab, knitr, lubridate, magic, markdown, pkgconfig, plogr, pls, praise, purrr, recipes, rex, rmarkdown, robustbase, sfsmisc, testthat, tidyr, tidyselect, timeDate, tinytex, xfun, yaml
Installing packages into `/usr/local/lib/R/site-library`
(as `lib` is unspecified)
Error: (converted from warning) package `Biobase` is not available (for R version 3.5.1)
Execution halted
I can add it as a package that travis should install (and that will most likely work) but I'm not sure what that means for CRAN. One of the main issues here is the difference between official CRAN checks and what we have available to us.
Although its results are not very stable, can you try running it on r-hub
(via devtools::check_rhub
)?
on current develop I have moved
NMF
back to suggests and everything seems to work fine on my computer, on travis, and winbuilder (except oldrelease which gives an unrelated error), can you please check.
Your develop
branch works for me (with neither Biobase
or bigmemory
installed).
I'd send an email to the CRAN folks and tell them the evidence that you have for this new version working and see if you can resubmit. For me, adding Biobase
as an imports (instead of suggests) is the major issue. You would think that NMF
having Biobase
and bigmemory
in its suggests would be fine but travis failed to install those too.
Sorry that this has been such a hassle. As a potential fallback, a different NMF package could be used (I think that we first looked at NNLM
but my recollection is that it wasn't that great) or we could use reticulate
to invoke the python method in sklearn
. I think that you do that for a different method in dimRed
IIRC.
[edit]
An expert within our group looked at this and commented that
I am basically 100% confident that both that the issue is
dimRed
not importing generics it is using and also that it is possible to do so conditionally without a hard dependency
I will try to submit what is currently in the develop
branch as 0.2.2 with an explanatory note. Current develop
fails on win-builder oldrelease, I think due to some stringi
issue, but there are more failures which I am not sure are caused by stringi
.
I have already some python dependencies, namely tensorflow
, keras
, and umap-learn
. There are already some possible traps with the virtual environments that are created by tensorflow::install_tensorflow
/keras
and umap-learn
. I would like to avoid adding more python dependencies if possible, on the other hand these traps are already set.
Do you have any idea what changed with NMF
? I did not work before and there were no new NMF
releases. Also on my computer it works now with R-3.4.4 which is the same version I tried it with last time.
Do you have any idea what changed with
NMF
? I did not work before and there were no newNMF
releases. Also on my computer it works now with R-3.4.4 which is the same version I tried it with last time.
No idea.
We can go with another implementation. A friend just sent me a pretty lightweight NMF implementation that just uses base R if you want to try that.
How big is the difference in features and performance? The inverse is a trivial matrix multiplication, but for the forward calculation you have to solve a linear equation system without producing negative numbers.
It's pretty bare bones in terms of features. For the weights, they are set to zero if negative. Given how prevalent zeros are in the loading matrices, I think that it is pretty common.
nmf = function(x, k, maxit=10, tol=1e-2, u=x[, 1:k], v=x[1:k, ]) {
j = 1
eps = Inf
pinv = function (x, eps=1e-12) { # helper function
i = x > eps
x[i] = 1 / x[i]
x[! i] = 0
x
}
while(j <= maxit && eps > tol)
{
s = svd(v)
u = tcrossprod(x, v) %*% s$u %*% (pinv(s$d)^2 * t(s$u))
u[u < 0] = 0
s = svd(u)
v = s$v %*% (pinv(s$d)^2 * t(s$v)) %*% crossprod(u, x)
v[v < 0] = 0
j = j + 1
eps = norm(x - u %*% v, "F")
}
list(u=u, v=v, eps=eps, iterations=j-1, tol=tol)
}
I would change the convergence criterion and a few other things (but would leave the core intact).
There's always NNLM
too. That only has Rcpp dependencies.
Is NNLM maintained? I don't have a lot of time for the rest of the year, I will try to simply submit dimRed with NMF
in Suggests
if this still fails badly we will have to think of something. I have never dug into implementations for nnmf, so I cannot really give an opinion about your code, maybe I will do it if I find some free time. I really would like to have a forward
function.
Is NNLM maintained?
Not sure. The user hasn't been on GH much from what I can see (public repos, that is).
if this still fails badly we will have to think of something.
If that happens, can you send in a version without NMF? I've gotten emails in the last day about caret
install issues (since it depends on recipes
).
What you mean without NMF? No non-negative matrix factorization or a non-NMF version of non-negative matrix factorization?
Sorry, I meant a version without the NMF
package, even if that means no code for non-negative matrix factorization (if we have no good alternative).
v0.2.2 is on its way to CRAN, let's see if it will work this time.
I had a few of our people with 1000x more expertise than mine take a look and that think that it should be fine.
The interesting question to me is what changed, since we tried it the first time.
The OSX builds are still failing. 1) I forgot to check for the pcaL1
package in the examples and 2) The tests fail without a useful error message.
Can you point me to the failures? Anything that we can do to help?
https://cran.r-project.org/web/checks/check_results_dimRed.html
The OSX examples fail, because I do not check for the presence of pcaL1
, there is no useful information about the failing tests as far as I can see, maybe they fix themselves after fixing the example.
The main problem is that CRAN won't build OSX binaries, is it possible to install dimRed
anyway on a mac without going through too much trouble?
The OSX examples fail, because I do not check for the presence of pcaL1, there is no useful information about the failing tests as far as I can see, maybe they fix themselves after fixing the example.
That's easy to fix with one of testthat
's skip functions.
The main problem is that CRAN won't build OSX binaries, is it possible to install dimRed anyway on a mac without going through too much trouble?
I had a ton of trouble getting pcaL1
installed due to its external dependency. I couldn't find it on homebrew
then someone pointed me to
brew tap coin-or-tools/coinor
brew install clp
It might help to make of note of this in the readme file or on that man page.
Where do things stand now? Any comments back from CRAN on this version?
See: https://cran.r-project.org/web/checks/check_results_dimRed.html
0.2.2 is on CRAN and working great, except for OSX, because I had to make some stuff conditional on the presence of the pcaL1
package, this should be fixed in current develop
. Therefore dimRed
for OSX on CRAN is still version 0.1.0
, if that is a problem.
I have never had a Mac so you are probably better suited to describe this, could you please add this to the documentation of the PCA_L1
class or give me a paragraph that I can add.
We should also write the CRAN maintainers and ask them to install coinor
on the OSX machines.
have never had a Mac so you are probably better suited to describe this, could you please add this to the documentation of the
PCA_L1
class or give me a paragraph that I can add.
I'll put in a PR.
0.2.2 is on CRAN and working great
Ok. I thought that we were still waiting on that for approval. I've got a deluge for packages headed for CRAN then.
Thanks!
So there is no hurry for fixing the osx fails?
When do you think that you'll do another release? I have a recipes version going to CRAN before the end of the year and I wasn't sure if I could include the NNMF or autoencoder features from
dimRed
in that version.