Open patrickjdanaher opened 1 year ago
Suggestion for #2:
Check the eigenvalues of the conditionon matrix. If one is too small, then use lm() machinery to find the variables that we can report on.
... or maybe it had something to do with too few neighbors / use of a small radius?
... can I just replace conditionon with its PCs, stopping for PCs with eigenvalues < 10^-4?
Suggestion for #1:
use syntax that's compatible with data.table. OR, just use as.data.frame() on conditionon early in the workflow.
@patrickjdanaher , the data.table error can be fixed by importing the data.table functions.
for example, include this in a file R/imports.R and rerun devtools::document()
#' @importFrom data.table .N .I ':=' copy uniqueN
NULL
1: an error that was fixed by forcing the conditionon argument to be a data frame, not a data table:
Error in
[.data.table
(df, , i) : j (the 2nd argument inside [...]) is a single symbol but column name 'i' is not found. Perhaps you intended DT[, ..i]. This difference to data.frame is deliberate and explained in FAQ 1.1.2: "Error in solve.default(cov_bb): system is computationally singluar." ... the matrix coming out of the build_conditionon function had an eigenvalue ~= 0. This shouldn't be happening. The existing countermeasures must not have caught an edge case. Unclear what the edge case is. (Using bigger neighborhoods, from radius = 0.1 to K = 50, solved this.)
Warning about misaligned row names: part comes as a warning, the rest as a message. Make into one warning.
The vignette used a radius-based default - change it to K-nearest?