sam-stats fails to properly deduce unmapped reads and snp (ins/del) rate about ea-utils HOT 6 CLOSED

Right, sam-stats currently uses the existence of a chromosome and a position to 
mean "mapped".   

The reason for that is that bwa has some odd bit-field behavior where some 
reads are "mapped" but have no position, and others are "unmapped" but have 
both (and are correct).

(In your case, the correct alignment is at position 0 with two bases of 
soft-clipping)

I will change it to require both.   It's probably better.

New version checks bits, and reports+skips zero/negative positions as "error 
reads".

Awesome! Thank you for addressing this issue. Will test drive it and let you 
know if I stumble across something else.

I have another suggestion:
How about spitting out stats separately for read1 and read2 for paired-end 
bams? That way the stats don't get averaged out and assuming we have an issue 
with just read2, we could still salvage the read1 data.

Just a thought.

-Narayanan

I usually run fastq-stats on read1 and read2 separately, and run the graphing 
tool for them as well.   After alignment, it's often too late, since some 
aligners will count very improper pairs as "unaligned" anyway... sometimes it's 
hard to tell which side is right.

if you had an extract from a bam file where 1 read was good and the other not, 
i'd like to see if that's caught by fastq-stats or whether it's something 
sam-stats is better at reporting

check the trunk version for new behavior