Error in is.na.A[[q]] : index out of range'

From email from Jaehyun

Dear mixOmics team,

Thank you for your response (by Dr. Florian Rohart) for the last feedback. I am glad to hear that the error will be fixed in the next time.

I modified the part personally and tried using the function tune.block.splsda again. However, I faced another problem while using the function. I am sending this e-mail to ask about the probable error in the function.

The screenshot of the traceback of the error is attached to the mail. (The error message written in Korean means 'Error in is.na.Aq : index out of range') and the problem occurred in the 118th line of a function internal_mint.block.

I tried to run each function with the same data, and I suppose that the possible problem occurred while giving arguments for the function internal_wrapper.mint.block.

c(is.na.A.train, Y = NULL) is given as an argument for a parameter is.na.A of the function internal_wrapper.mint.block, and in the function, X and Y is concatenated and stored in an object A by a function Check.entry.wrapper.mint.block. A and is.na.A is input to internal_mint.block, and A is processed and stored again in an object R.

Under is the code from line 117 to 119 of the function,

        R = lapply(1:J, function(q) {
            replace(R[[q]], is.na.A[[q]], 0)
        })

where J is length(A).

I found that the length of is.na.A, or c(is.na.A.train, Y = NULL), is same with the number of blocks in X, while Y = NULL seems not to add another slot of the list. The length of A (or R) is the number of blocks plus one, since A is the concatenation of X and Y.

As I do not fully understand the actual workflow of each function, I am careful to point out the actual cause of the problem, but I conjecture that fixing c(is.na.A.train, Y = NULL) to have one more additional slot or running lapply from 1 to (J-1) might solve the problem.

I will appreciate if you check the screenshot and codes and consider dealing with the problem.

I hope that this mail will be a help to the program.

Comments (1)