Forthcoming uwot release will add output UMAP row names
Closed this issue · 4 comments
Hello, at some point I hope to release a new version of uwot (a dependency of this package) and it looks like it will cause some breakage here.
A new feature/bug fix (for jlmelville/uwot#81) means that any row names of the input data are now retained as the output embedding matrix row names. This has caused all UMAP-related unit tests to fail: based on my testing, the direct_* matrix outputs will have row names associated with them, but those from calling bake and step_umap will not. Currently there is no critical bug fix or other time-sensitive issue driving the release, but I am not sure how to proceed to minimize the disruption to this package.
FWIW the relevant output of testthat (with the current development release of uwot) is below.
══ Failed tests ════════════════════════════════════════════════════════════════
── Failure (test_umap.R:41:3): factor outcome ──────────────────────────────────
direct_mod$embedding not equal to supervised$steps[[1]]$object$embedding.
Attributes: < Names: 1 string mismatch >
Attributes: < Length mismatch: comparison on first 2 components >
Attributes: < Component 2: Modes: list, numeric >
Attributes: < Component 2: Component 1: Modes: character, numeric >
Attributes: < Component 2: Component 1: Lengths: 133, 1 >
Attributes: < Component 2: Component 1: target is character, current is numeric >
Attributes: < Component 2: Component 2: target is NULL, current is numeric >
── Failure (test_umap.R:51:3): factor outcome ──────────────────────────────────
`direct_pred` not equal to bake(supervised, new_data = te, composition = "matrix", all_predictors()).
Attributes: < Component "dimnames": Component 1: Modes: character, NULL >
Attributes: < Component "dimnames": Component 1: Lengths: 17, 0 >
Attributes: < Component "dimnames": Component 1: target is character, current is NULL >
── Failure (test_umap.R:84:3): numeric outcome ─────────────────────────────────
direct_mod$embedding not equal to supervised$steps[[1]]$object$embedding.
Attributes: < Names: 1 string mismatch >
Attributes: < Length mismatch: comparison on first 2 components >
Attributes: < Component 2: Modes: list, numeric >
Attributes: < Component 2: Component 1: Modes: character, numeric >
Attributes: < Component 2: Component 1: Lengths: 133, 1 >
Attributes: < Component 2: Component 1: target is character, current is numeric >
Attributes: < Component 2: Component 2: target is NULL, current is numeric >
── Failure (test_umap.R:94:3): numeric outcome ─────────────────────────────────
`direct_pred` not equal to bake(...).
Attributes: < Component "dimnames": Component 1: Modes: character, NULL >
Attributes: < Component "dimnames": Component 1: Lengths: 17, 0 >
Attributes: < Component "dimnames": Component 1: target is character, current is NULL >
── Failure (test_umap.R:125:3): no outcome ─────────────────────────────────────
direct_mod$embedding not equal to unsupervised$steps[[1]]$object$embedding.
Attributes: < Names: 1 string mismatch >
Attributes: < Length mismatch: comparison on first 2 components >
Attributes: < Component 2: Modes: list, numeric >
Attributes: < Component 2: Length mismatch: comparison on first 2 components >
Attributes: < Component 2: Component 1: Modes: character, numeric >
Attributes: < Component 2: Component 1: Lengths: 133, 1 >
Attributes: < Component 2: Component 1: target is character, current is numeric >
Attributes: < Component 2: Component 2: target is NULL, current is numeric >
── Failure (test_umap.R:135:3): no outcome ─────────────────────────────────────
`direct_pred` not equal to bake(...).
Attributes: < Component "dimnames": Component 1: Modes: character, NULL >
Attributes: < Component "dimnames": Component 1: Lengths: 17, 0 >
Attributes: < Component "dimnames": Component 1: target is character, current is NULL >
[ FAIL 6 | WARN 1 | SKIP 13 | PASS 191 ]
Error: Test failures
Execution halted
1 error ✖ | 4 warnings ✖ | 4 notes ✖
Thank you so much for the report @jlmelville! Our tests were being pretty strict in checking objects including those names, but the 3rd edition of testthat makes it easier to relax that testing. I tested locally using your current development version and I believe the changes in that PR should make all well.
We can do a CRAN release of embed before your next CRAN release, which will avoid problems with reverse dependency checks on CRAN. We don't have an immediate need to release embed, but could probably do one fairly soon because there is nothing blocking it, right @topepo?
Thank you for the swift action on this, much appreciated.
@jlmelville The new version of embed is now on CRAN so you should in the clear now; let us know if you see any other problems when you run revdeps again.
This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.