<p>Hi Andreas,</p>
<p>You're looking at a comparison between two FASTQ reads:</p>
<pre><code>@Rec1
GCATGATATATACAAC
+
012345'FBcEFGHIJ
</code></pre>
<p>and</p>
<pre><code>@Rec1
GCATGATATATACAAC
+
012345(FBcEFGHIJ
</code></pre>
<p>The format is roughly</p>
<pre><code>@[name]
[N * Nucleotides]
+
[N * Phred quality scores]
</code></pre>
<p>So the difference is that the quality score for the 7th base (a 'T') is "'" instead of "(", corresponding to a Phred quality score of 6 instead of 7 (calculated as ASCII value - 33). It is merely a coincidence that this happened between numerical and non-numerical values.</p>
<p>During the collapse step, in which two overlapping reads are merged, updated quality scores are calculated as a product of the scores for the two copies of the overlapping base-pair. This will either result in a higher quality score being assigned (for identical positions) or a lower quality score being assigned (for mismatching positions).</p>
<p>The calculation to determine the updated quality score makes use of std::log10, which appears to produce slightly different results on i386 vs amd64, resulting in a small number of updated quality scores being off by one on i386 compared to amd64. I determined this simply by printing every single intermediate result for this calculation for binaries built with and without -m32.</p>
<p>The solution I am taking is to simply pre-calculate the lookup table and include a hardcoded copy of that, instead populating the table when it is first used. It is not the prettiest solution, but it ensures that results can be reproduced regardless of the architecture.</p>
<p>I realize that my last comment was rather vague, but I hope that this makes it clear what the issue was.</p>
<p>See <a href="https://en.wikipedia.org/wiki/FASTQ_format" rel="nofollow">https://en.wikipedia.org/wiki/FASTQ_format</a> for a detailed description of the format.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you authored the thread.<br />Reply to this email directly, <a href="https://github.com/MikkelSchubert/adapterremoval/issues/35#issuecomment-471948966">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJAqA0joOOpeqBFjalJYast017sd_STaks5vV4TvgaJpZM4beQb-">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJAqA45VXWftJbG4MFTZoxy7wuAXplemks5vV4TvgaJpZM4beQb-.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/MikkelSchubert/adapterremoval","title":"MikkelSchubert/adapterremoval","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/MikkelSchubert/adapterremoval"}},"updates":{"snippets":[{"icon":"PERSON","message":"@MikkelSchubert in #35: Hi Andreas,\r\n\r\nYou're looking at a comparison between two FASTQ reads:\r\n\r\n    @Rec1\r\n    GCATGATATATACAAC\r\n    +\r\n    012345'FBcEFGHIJ\r\n\r\nand\r\n\r\n    @Rec1\r\n    GCATGATATATACAAC\r\n    +\r\n    012345(FBcEFGHIJ\r\n\r\n\r\nThe format is roughly\r\n  \r\n    @[name]\r\n    [N * Nucleotides]\r\n    +\r\n    [N * Phred quality scores]\r\n\r\n\r\nSo the difference is that the quality score for the 7th base (a 'T') is \"'\" instead of \"(\", corresponding to a Phred quality score of 6 instead of 7 (calculated as ASCII value - 33). It is merely a coincidence that this happened between numerical and non-numerical values.\r\n\r\nDuring the collapse step, in which two overlapping reads are merged, updated quality scores are calculated as a product of the scores for the two copies of the overlapping base-pair. This will either result in a higher quality score being assigned (for identical positions) or a lower quality score being assigned (for mismatching positions). \r\n\r\nThe calculation to determine the updated quality score makes use of std::log10, which appears to produce slightly different results on i386 vs amd64, resulting in a small number of updated quality scores being off by one on i386 compared to amd64. I determined this simply by printing every single intermediate result for this calculation for binaries built with and without -m32.\r\n\r\nThe solution I am taking is to simply pre-calculate the lookup table and include a hardcoded copy of that, instead populating the table when it is first used. It is not the prettiest solution, but it ensures that results can be reproduced regardless of the architecture.\r\n\r\nI realize that my last comment was rather vague, but I hope that this makes it clear what the issue was.\r\n\r\nSee https://en.wikipedia.org/wiki/FASTQ_format for a detailed description of the format."}],"action":{"name":"View Issue","url":"https://github.com/MikkelSchubert/adapterremoval/issues/35#issuecomment-471948966"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/MikkelSchubert/adapterremoval/issues/35#issuecomment-471948966",
"url": "https://github.com/MikkelSchubert/adapterremoval/issues/35#issuecomment-471948966",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>