Expose a configurable pseudocount value for replacing zeroes in data

[fedarko]

Code for this used to be available in Qurro months ago, but I took it out because it was buggy and no one was using it.

...But now that more people are using this tool, this might actually be useful?

Thanks to Justin for discussion.

Checklist for completing this:

• add a UI element (numerical input where users can specify a pseudocount value; defaults to 0, i.e. no pseudocount; has a hard lower limit of 0, but no set max limit I guess -- or Number.MAX_SAFE_INTEGER, maybe)

• Modify getCount() to take as input a pseudocount argument. In the branch where we return 0 if a count's value is falsy, instead return the pseudocount.

  • The easiest thing to do here would be just having getCount() look at the DOM to get the pseudocount value. However: this is a bad idea in practice, since the user could theoretically change the pseudocount box halfway through Qurro computing log-ratios, ccausing inconsistent results. (Also, this'd be slow since it'd involve a lot of unnecessary DOM queries.)
  • A better solution would involve more work that just gets the pseudocount up front in updateSamplePlotSingle() or updateSamplePlotMulti(), and passes it to changeSamplePlot() (which passes it to the updateBalance func being used, which handles it accordingly when calling getCount() or calling another function that calls getCount()).

• test the following cases:

  • invalid (non-numeric or negative, ...) input entered for pseudocount value (can mostly reuse infrastructure from the numeric feature filtering functionality)
  • 0 pseudocount works normally
  • 0.01 pseudocount works
  • 0.5 pseudocount works
  • 1 pseudocount works
  • 5 pseudocount works (IDK why you would actually use this but might as well)

[fedarko]

Until this is implemented in the JS side of things, a stopgap approach might be allowing users to pass in a FeatureTable[Composition] artifact instead of a FeatureTable[Frequency] artifact. This way, users could manually set a pseudocount via qiime composition add-pseudocount -- so all log-ratios computed in the JS interface would have this pseudocount used.

@mortonjt lmk if this sounds reasonable -- I know this isn't an ideal solution but it would at least work...

[mortonjt]

I'm not sure why I didn't see this before, but yes having a pseudocount option is a great idea.

It is ok to have as input a FeatureTable[Composition] object. But having an option to specify pseudocounts in the interface would definitely be more user friendly. I don't think we want to allow for pseudocounts greater than 1.