Hi all!
This is super low-priority, but I've been thinking lately about eventually accounting for the maximum integer size in JavaScript. The TL;DR here is that when you start using Number
s greater than 2^{53} - 1 (or less than -(2^{53} - 1)) in JavaScript, things start getting funky:
> var x = Math.pow(2, 53) - 1;
> var ohNo = x + 1;
> var ohHeck = x + 2;
> ohNo === ohHeck;
true
The initial context in which I started thinking about this was for Qurro, in which feature table entries greater than this max value could theoretically cause problems with the computation of log-ratios. However, I imagine this could impact other QIIME 2 JavaScript visualizations, e.g. quantitative color gradients in Emperor or the sampling depth threshold in qiime feature-table summarize
.
It should be possible to use stuff like BigInt
s to account for these problems, but those have some inherent albeit surmountable tradeoffs (e.g. can't use them in Math
methods like Math.log()
).
From discussing this with @antgonza earlier today, one option that sounded reasonable to us was just raising a warning if any of the data used to create a JS visualization (e.g. feature table entries, numeric-column metadata values) fell outside of a predefined "safe" range (and maybe adding this sort of behavior to QIIME 2, so that individual plugins don't have to reinvent the wheel when dealing with this). But we thought it'd be best to open a topic here, to see if any of y'all have thought about this issue before
(I'm pretty sure people aren't going to be throwing feature tables with counts greater than 2^{53} - 1 at QIIME 2 any time in the immediate future, but I guess it's possible...)