parameter values about libbigwig

[dpryan79]

• 7 is reasonable, 10 is the default inherited from Kent's tools. 0 is problematic since IGV and a few other tools will completely break.
• I think that's the only trade off.
• The FromFull version will calculate the stats on the intervals themselves, as opposed to plain bwStats which will use the zoom levels. The latter will better match what Kent's tools will do or what you'd eye ball in IGV/IGB and be faster, the former is more formally correct but a bit slower.
• Truth be told that's how I end up making most bigWig files (in deepTools we basically make a bunch of little bedGraphs and then add each entry line-by-line to the bigWig). It will be notably faster to use an array of values, but that's often just awkward to code and the performance is often still "good enough".

[brentp]

great. thanks for the replies. I have stubbed out a function to add a list of intervals that
adds the first with bwAddIntervals and all other intervals with bwAppendIntervals, largely since the latter doesn't need a chromosome for each interval. do you see any problems with that?

[dpryan79]

That's exactly what the python wrapper does :)

[brentp]

cheers.

[brentp]

fyi, I now have a fairly complete wrapper here: https://github.com/brentp/libbigwig-nim
this was quite easy thanks to the nice API that you have.

[dpryan79]

Great! I've been thinking about which language to pick up next and had been considering Rust or Go. Would you suggest Nim instead?

[brentp]

I would. But Go and Rust are both reasonable alternatives. You can't beat nim for the combination of brevity and performance.

[brentp]

Hi Devon,
is there a practical limit on the number of values to add with e.g. bwAppendIntervals?
For example if I add a million intervals spanning a total of 100 million bases, would it be better for later query performance to break those up or does the internal implementation/data structure make this a non-concern?