Floating point error with high -log10 p-values?

[VasLem]

Hi, I would like to mention that there is an issue with the numerical processing of the -log10 p-values, the highest it gets is 31.38 . This causes a wrong report of the highest peaks to show up if higher peaks than this number exist.

[abought]

Thanks for the report. Can you provide an example link where you are seeing this problem?

Also, is there a typo here (should this be referring to, eg, ~300)?

General notes:

• In theory LocusZoom can handle much more extreme pvalues than what you report (example)
• In practice, how you load data to show in LocusZoom is very important. Many languages/ API servers run into numerical underflow for pvalues < ~10^-300 (some websites thus fill in fake values past that cutoff).
• Since JS is sensitive to underflow, we recommend storing -log10pvalue on ingest, rather than when sending it to the web browser- this handles a much wider range of values. Sending -log10p is how our my.locuszoom.org upload site shows extreme pvalues. (if underflow is detected, we convert it to a number via a slower and more aggressive regex procedure)

We're used in many different websites- some via tabix, others via custom backends. It's hard to say exactly where the problem is without knowing which tool you use.... but I'd start by looking at the steps where data is read and sent to the browser.

If this is for a private site, I can be reached at abought@umich.edu for any direct links that you don't want to share on a public forum.

[sir4ur0n]

My 2 cents: I agree with @abought : I also use LZ and I have values way over 31 (even over 300) and it works just fine:

[abought]

No reply from original author after ~3 weeks. I'm going to close this ticket to keep the backlog clear, but feel free to reopen if there's anything we can do to be of assistance.