使用线性内核调整 SVM 时，R 插入符号异常缓慢

Question

在使用 caret 调整 SVM 参数时，我观察到了一个非常奇怪的行为。 .在没有调优的情况下训练单个模型时，径向基核的 SVM 比线性核的 SVM 花费更多的时间，这是预期的。然而，当在相同的惩罚网格上调整带有两个内核的 SVM 时，带有线性内核的 SVM 比带有径向基内核的 SVM 花费更多的时间。使用 R 3.2 和 caret 在 Windows 和 Linux 中可以轻松重现此行为。 6.0-47。有谁知道为什么调整线性 SVM 比径向基核 SVM 花费更多的时间？

SVM linear
   user  system elapsed 
   0.51    0.00    0.52 

SVM radial
   user  system elapsed 
   0.85    0.00    0.84 

SVM linear tuning
   user  system elapsed 
 129.98    0.02  130.08 

SVM radial tuning
   user  system elapsed 
   2.44    0.05    2.48 

玩具示例代码如下:

library(data.table)
library(kernlab)
library(caret)

n <- 1000
p <- 10

dat <- data.table(y = as.factor(sample(c('p', 'n'), n, replace = T)))
dat[, (paste0('x', 1:p)) := lapply(1:p, function(x) rnorm(n, 0, 1))]
dat <- as.data.frame(dat)

sigmas <- sigest(as.matrix(dat[, -1]), na.action = na.omit, scaled = TRUE)
sigma  <- mean(as.vector(sigmas[-2]))

cat('\nSVM linear\n')
print(system.time(fit1 <- train(y ~ ., data = dat, method = 'svmLinear', tuneLength = 1,
                                 trControl = trainControl(method = 'cv', number = 3))))

cat('\nSVM radial\n')
print(system.time(fit2 <- train(y ~ ., data = dat, method = 'svmRadial', tuneLength = 1,
                                 trControl = trainControl(method = 'cv', number = 3))))

cat('\nSVM linear tuning\n')
print(system.time(fit3 <- train(y ~ ., data = dat, method = 'svmLinear',
                                 tuneGrid = expand.grid(C = 2 ^ seq(-5, 15, 5)),
                                 trControl = trainControl(method = 'cv', number = 3))))

cat('\nSVM radial tuning\n')
print(system.time(fit4 <- train(y ~ ., data = dat, method = 'svmRadial',
                                 tuneGrid = expand.grid(C = 2 ^ seq(-5, 15, 5), sigma = sigma),
                                 trControl = trainControl(method = 'cv', number = 3))))

Answer 1

看了一看，我不相信问题出在 caret ，而是在幕后(落后)发生的事情 kernlab .
正如在堆栈溢出的其他地方所述 SVM本身就是一个密集型算法。 SVM的时间复杂度是 O(n*n)。现在这并没有说明 SVM 之间的差异调用。似乎正在发生的事情是在通过以 SVM > .Local > .call. 结尾的非常深的堆栈调用已编译的 C 代码之后。 ( .call 是对已编译的 c 代码的调用，并且超出了我的知识库)。大多数情况下，您会看到意外的缓慢时间从 R 移动至 C因为事情是如何通过的。由于您拉入矩阵，这进一步有助于假设命名或尺寸问题会导致另一端的一些额外工作。
如果我们看看这段代码是如何分析的，瓶颈就变得很清楚了。
对字体大小表示歉意——它是一个很深的堆栈，我认为整体形状比单个功能更能说明故事。随意发送垃圾邮件 Ctrl + 下面。nSVM_linear看起来像一个健康的配置文件和许多友好的 R 函数。
nSVM radial 同样的优惠

现在，一旦我们开始“径向调谐”，我们就会开始看到 try-call 的扁平结构。堆栈开始倾斜，但一切似乎都在快速执行。

哇。完全不同的线性调谐结构C在某些情况下，通话时间超过 100 秒。

话虽如此，看起来您的瓶颈在编译的 C 中。来自 kernlab 的代码.由于包正在连接到 libsvm这似乎非常有效，我无法想象正在调用的代码存在实际问题。实际上确定如何(基于安全的功能或来自 R 的输入问题)以及为什么在从一个移动到另一个时出现问题是比我更好的人的工作。