train.kknn() fails on this data set about kknn

[kenahoo]

Hi @KlausVigo , any thoughts on this?

[KlausVigo]

Hi @kenahoo ,
you are right, this looks like an underflow or overflow problem. What system are you using, maybe you can send me the output of sessionInfo() ?

On my machine your code is working, so I can't really reproduce your problem.

...
 kmax = 3L, kernel = "rectangular")

Type of response variable: continuous
minimal mean absolute error: 0.10675
Minimal mean squared error: 0.02878625
Best kernel: rectangular
Best k: 1

Regards,
Klaus

[kenahoo]

Hi Klaus,

Actually, it seems to be non-deterministic. Here are a few runs in a row:

> do.call(train.kknn, args)
Error in cl[C] : only 0's may be mixed with negative subscripts
> do.call(train.kknn, args)
Error in best[1, 2] : subscript out of bounds
> do.call(train.kknn, args)
Error in best[1, 2] : subscript out of bounds
> do.call(train.kknn, args)
Error in cl[C] : only 0's may be mixed with negative subscripts
> do.call(train.kknn, args)
Error in best[1, 2] : subscript out of bounds
> do.call(train.kknn, args)

Call:
(function (formula, data, kmax = 11, ks = NULL, distance = 2,     kernel = "optimal", ykernel = NULL, scale = TRUE, contrasts = c(unordered = "contr.dummy",         ordered = "contr.ordinal"), ...) {    if (is.null(ykernel))         ykernel = 0    weight.y = function(l = 1, diff = 0) {        k = diff + 1        result = matrix(0, l, l)  
# ... (that one was successful)

My session info:

> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-apple-darwin17.7.0 (64-bit)
Running under: macOS High Sierra 10.13.6

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.5/lib/libopenblasp-r0.3.5.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] kknn_1.3.1

loaded via a namespace (and not attached):
[1] compiler_3.5.2  magrittr_1.5    Matrix_1.2-15   igraph_1.2.2   
[5] grid_3.5.2      pkgconfig_2.0.2 lattice_0.20-38

[kenahoo]

I took R (mostly) out of the chain, and it looks like it's non-deterministic at the C level. Stepping through with the lldb debugger, I see this:

(lldb) p dmEuclid(mm_data, mm_data, &m, &p, &q, dm, cl, &k, we)
(lldb) p cl
(int [20]) $2 = {
  [0] = 0
  [1] = 1
  [2] = 2
  [3] = 3
  [4] = 2
  [5] = 0
  [6] = 0
  [7] = 2
  [8] = 3
  [9] = 2
  [10] = 3
  [11] = 0
  [12] = 1
  [13] = 3
  [14] = 1
  [15] = 1
  [16] = 0
  [17] = 1
  [18] = 3
  [19] = 1
}
(lldb) p dmEuclid(mm_data, mm_data, &m, &p, &q, dm, cl, &k, we)
(lldb) p cl
(int [20]) $3 = {
  [0] = 0
  [1] = 1
  [2] = 2
  [3] = 3
  [4] = 2
  [5] = 0
  [6] = 0
  [7] = 2
  [8] = 3
  [9] = 2
  [10] = 3
  [11] = 0
  [12] = 1
  [13] = 3
  [14] = 1
  [15] = 1
  [16] = -1610612736
  [17] = 1
  [18] = 3
  [19] = 1
}

I also noticed some mismatches between the order of argument names that train.kknn is passing, and what dmEuclid accepts:

.C("dmEuclid",
   as.double(mm.data),
   as.double(mm.data), 
   as.integer(m),  <---- different order
   as.integer(p),  <---- different order
   as.integer(q),  <---- different order
   dm = double((kmax + 2L) * p),
   cl = integer((kmax + 2L) * p), 
   k = as.integer(kmax + 2),
   as.double(we),
   PACKAGE = "kknn")

void dmEuclid(double *learn,
              double *valid,
              int *n,   <---- different order
              int *m,   <---- different order
              int *p,   <---- different order
              double *dm,
              int *cl,
              int *k,
              double *weights)

Any chance this is the issue?

[KlausVigo]

Hi @kenahoo,
I should rename the parameters to correspond in the R and C code.
I think I finally figured it out. I kind of assumed that kmax + 2 is smaller the number of observations.
It should be now to work if kmax + 1 is equal to the number of observations and decreases kmax otherwise.
Can you check if my last commit fixes your problem?

[kenahoo]

Hi @KlausVigo , I think that fixes the problem indeed.

Curiously, I could only get this problem to manifest when running R interactively, not through Rscript. Maybe memory initialization is different in that case or something.

Thanks.