Closed macmanes closed 8 years ago
this is just 1 - p_good_mappings
- is it worth adding a column for it?
you have p_everythingelse
but I suppose you are right.. On the other hand, you already have like 33 columns, so what is one more...
I think for each thing we only report one way of expressing it, so e.g.
p_not_segmented
but not p_segmented
p_bases_covered
but not p_bases_uncovered
p_good
but not p_bad
etc.
I would definitely prefer to have fewer columns :). However, it might be a good idea to explicitly state in the documentation that bad
is always 1 - good
, as there is no reason people should assume that is true.
we've stripped out some columns in v1.0.3, but we've still got too many. Closing this issue as we're not planning to put in p_bad_mappings
, but we will be looking at reworking the output for clarity in the next major release.
Write
p_bad_mappings
to assemblies.csv, like you do forp_good_mappings