Accounting for Number.MAX_SAFE_INTEGER in JavaScript visualizations?

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 Numbers 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 BigInts 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 :slight_smile:

(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…)

2 Likes

I love your snippet so much!

Another angle to look at this would be WASM, which has int64 defined as a real type, and happens to be faster for number crunching to boot. There’s been a lot of really cool development on it lately.

1 Like