normalize.shared and beta diversity calcs

Hi,

While performing normalize.shared, the wiki mentions that the OTU is rounded off to nearest integer. Is there a way to bypass this rounding off? This will likely artificially lower or increase the abundance of certain OTU, granted this will be more critical for low abundance OTU’s.

Also, I generated pCOA plots for different betadiversity calculators for both norm.shared.dist and dist.shared and noticed that community structure (thetayc, morisitahorn) based metrics were less sensitive to the normalizing as compared to community membership (jest, braycurtis). Could this be an effect of rounding off during normalizing? If so, are membership based metrics valid for either normalized or non-normalized data while comparing communities?

Thanks.

While performing normalize.shared, the wiki mentions that the OTU is rounded off to nearest integer. Is there a way to bypass this rounding off? This will likely artificially lower or increase the abundance of certain OTU, granted this will be more critical for low abundance OTU’s.

This is the downside to normalizing, an alternative would be the subsampling function.

Also, I generated pCOA plots for different betadiversity calculators for both norm.shared.dist and dist.shared and noticed that community structure (thetayc, morisitahorn) based metrics were less sensitive to the normalizing as compared to community membership (jest, braycurtis). Could this be an effect of rounding off during normalizing? If so, are membership based metrics valid for either normalized or non-normalized data while comparing communities?

The difference you are noting is actually between those based on relative abundance (morisita-horn, thetayc) and those based on counts (bray-curtis). But is also true that membership based (jclass, jest) are also sensitive to uneven sampling.