HTSeq: union or intersection-empty or intersection-strict

[syintel87]

While running HTSeq, which option is recommended to use among -m union, -m intersection-empty, and -m intersection-strict?

The below is one of the results I've got. Would you please give me a tip about with which data I will have to analyze in the next step? I am thinking of adopting DESeq or EdgeR.

CASE1: -m union
no_feature 4152
ambiguous 391
too_low_aQual 0
not_aligned 0
alignment_not_unique 4110

CASE2: -m intersectioin-nonempty
no_feature 4223
ambiguous 249
too_low_aQual 0
not_aligned 0
alignment_not_unique 4110

CASE3: -m intersection-strict
no_feature 7797
ambiguous 221
too_low_aQual 0
not_aligned 0
alignment_not_unique 4110

[Simon Anders]

I haven't used anything else than "union" since long, and, admittedly, I would find it hard to now come up with good examples where the intersection modes would be preferable in practice. (When I wrote htseq-count two years ago, that was not so clear yet, of course.)

[syintel87]

I haven't used anything else than "union" since long, and, admittedly, I would find it hard to now come up with good examples where the intersection modes would be preferable in practice. (When I wrote htseq-count two years ago, that was not so clear yet, of course.)

Thank you!

I have one more question.
An option "-s no" seems more conservative, since this means the strandedness is not certain. (Is this right?)

Then, when the truth is "-s no", what if is "-s yes" chosen in running htseq-count?
Also, when the truth is "-s yes", what if is "-s no" chosen in running htseq-count?
What are expected results? How much would the result be biased?

Thank you in advance!