Transformations non consistent

[antagomir]

The natural log (log) in transformAssay behaves differently from log2 and log10:

# Example data
library(mia)
data(peerj13075)
tse <- peerj13075

# List log transformations
trans <- list(log2=log2, log10=log10, log=log)

for (i in names(trans)) {
  f <- trans[[i]]
  tse <- transformAssay(tse, assay.type = "counts", method = i, pseudocount=1)
  # Use check sum to verify if transformAssay gives same result than manual version
  # 0 indicates match
  print(paste(i, sum(assay(tse, i) - f(assay(tse, "counts") + 1))))

}

Reason seesm to be that log uses vegan::decostand, which has different treatment for count data.

This is confusing.

Suggestion:

• change the default behavior of log to align with log2 and log10
• consider providing vegan::decostand version separately, for instance through method="log.decostand"
• even better, support providing functions in the method argument (i.e. method=log2 instead of method="log2"); then one could use vegan functions or any other functions directly here.

This could be justified since pseudocount is not intended to be used as a general transformation.

[antagomir]

# ensure that counts2 assay is strictly positive
assay(tse, "counts2") <- assay(tse, "counts") +1
# transform with pseudocount
transformAssay(tse, assay.type = "counts2", method = "log2", pseudocount=1)

This results in warning message:
"The assay contains only positive values. Applying a pseudocount may be unnecessary. "

Suggestion:
adding pseudocount is not recommended when signals are strictly positive; consider throwing error instead of warning.

Reasoning:

• A warning may go unnoticed (code passes with warning but no pseudocount is added even when pseudocount=TRUE); this can be confusing for the user and the problem may go undetected
• The error could suggest that one can override this by modifying the assay directly in whatever way the user wants.

[TuomasBorman]

# ensure that counts2 assay is strictly positive
assay(tse, "counts2") <- assay(tse, "counts") +1
# transform with pseudocount
transformAssay(tse, assay.type = "counts2", method = "log2", pseudocount=1)

This results in warning message: "The assay contains only positive values. Applying a pseudocount may be unnecessary. "

The idea of giving just a warning was to not restrict users too much. They should know what they are doing.

--> Although, it might be justified to give error instead

* A warning may go unnoticed (code passes with warning but no pseudocount is added even when pseudocount=TRUE); this can be confusing for the user and the problem may go undetected

pseudocount=TRUE is different from pseudocount=1. TRUE means that user says that the function should add justified pseudocount.

The idea of supporting TRUE was to allow automated pipeline (some datasets need pseudocount, some don't). That is why only warning is given.

---

I tend to think that we should force user to be explicit (here and elsewhere). For instance, I would remove the TRUE/FALSE support. The message could say what pseudocount is jusitfied and suggest user to specify it.

Sometimes this automated "half of minimum value" might not be optimal pseudocount. For instance, some of the datasets might include only zeroes and large values which are probably caused by deep sequencing --> pseudocount=1, might be better option.

[antagomir]

Error can be informative and instruct what to do. If error is used.

Option pseudocount=TRUE was added to make it easier (faster) to do the standard choice. We could remove this, or we could have another function to suggest pseudocounts.. but both of these will cause more work for those users who know what they are doing.

A related question is should pseudocount be added (as in x + 1), or should zeroes be replaced by pseudocount and other values kept intact. For instance with count data, x+1 is naturally leading to case where pseudocount is half of the minimum value, whereas x + 1/2 (now default?) does not. And when pseudocount is applied to non-zero values this is affecting the data more than just replacing zeroes.. these choices should be mainly left for users but convenience is also desirable.

No clear view on this, maybe I could vote for:

• Throw informative error when trying to add pseudocount where it is not conventionally needed (all values are already positive); and suggest that the user adds it manually instead if they need to
• pseudocount=TRUE either keep as is, and/or add informative warning/message that suggest possibly even different possible pseudocounts and that the user should specify it explicitly; alternative provide a separate function for that (I'm not very much in favor of a separate function, though)