Your feature table has several classes (should be only one)! and Features for dataset No. 1 contains non-integer values!

[sophieleech]

Hi,

Perhaps I am missing an obvious solution but I am currently going around in circles between these two errors.

All values in my dataset are integers. And I know this for certain because I used the round() function.

However I was getting this error: Features for dataset No. 1 contains non-integer values!

After digging here I realised this was because of this test typeof(feat.temp) != 'integer'

So I converted using feat.table.integer <- apply(feat.table, 2, function(x) as.integer(as.character(x)))

However this results in

> class(feat.table.integer)
[1] "matrix" "array" 

Which I believe is due to this
So then this error occurs: "Your feature table has several classes (should be only one)!" because of this test length(c.feat) != 1

So to try to get around this I try converting to a data frame using
feat.table.integer <- as.data.frame(feat.table)

But while this fixes the multiple classes error, now

> typeof(feat.table.integer)
[1] "list"

Please help!

Thank you.

[jakob-wirbel]

Dear @sophieleech

Thanks for your interest in the package!

Hmmm, that is a bit harder to figure out.
How do you create your feature table?

In principle, it should be a matrix of integer values. So you could use the as.matrix function in R to transform your data.frame (which is stored internally as a list) into a matrix-object.

[sophieleech]

Thanks for the speedy reply! The feature table and metadata file was originally a phyloseq object which I extracted the OTU table from:

feat.table <- data.frame(t(round(ps_object@otu_table, digits = 0)))
colnames(feat.table) <- str_remove_all(colnames(feat.table),"X")
meta.table <- data.frame(ps_object@sam_data)

feat.table.integer <- apply(feat.table, 2, function(x) as.integer(as.character(x)))
rownames(feat.table.integer) <- rownames(feat.table)
colnames(feat.table.integer) <- colnames(feat.table)
feat.table.integer <- as.matrix(feat.table.integer)

Unfortunately using as.matrix results in the same issue.

> feat.table.integer <- as.matrix(feat.table.integer)
> class(feat.table.integer)
[1] "matrix" "array" 

Just to confirm there wasn't something weird happening due to the phyloseq object origin, I also did the below and the "matrix" "array" class persists.

##test 
> df.test <- data.frame(1, 2, 3, 4)
> df.test.matrix <- as.matrix(df.test)
> class(df.test.matrix)
[1] "matrix" "array" 
> matrix.test <- matrix(1, 2, 3, 4)
> class(matrix.test)
[1] "matrix" "array" 

What version of R was this originally written in? I can see on the main page it says 4.0.0 but in the R 4.0.0 updates it states:
'matrix objects now also inherit from class "array", so e.g., class(diag(1)) is c("matrix", "array"). This invalidates code incorrectly assuming that class(matrix_obj)) has length one.'

I am using R 4.4.1 so I think this bit of code in helper_clean.R, line 57:

c.feat <- class(feat)
  if (length(c.feat) != 1){
    stop('Your feature table has several classes (should be only one)!')
  }

is the issue.

While I am not sure on the implications for the rest of the code but could this check just be removed? The next check could be modified so it still can check if it's a list, matrix, dataframe etc e.g.

if (!c.feat[1] %in% c('list', 'matrix', 'data.frame')){
    stop('Your feature input should be either a matrix, a data.frame',
         ', or a list!')
  }

Thanks again for the quick reply.

Cheers!

[sophieleech]

I should also add however that I can run this with the provided toy_example (toy.feat and toy.meta) despite class(toy.feat) = "data.frame" and typeof(toy.feat) = "list". While in my data I cannot run while typeof(feat.table) = "list" due to the errors discussed above. I have no idea why.

[sophieleech]

Nevermind, I know why. I have got it working by
feat.table.integer <- as.data.frame(apply(feat.table, 2, function(x) as.integer(as.character(x))))

The problem I discussed above for matrix input is still an issue, but will work with a data frame input.

[jakob-wirbel]

oh, very interesting! That is good to know and great catch regarding the R update...
Yeah, unfortunately the package was developed a while ago with a frozen environment and hasn't real been updated since then.
Thanks for digging into it!