File: htslib_fix_float_precision

package info (click to toggle)
genomicsdb 1.5.5-1
  • links: PTS, VCS
  • area: main
  • in suites: forky
  • size: 25,312 kB
  • sloc: cpp: 68,637; ansic: 58,281; java: 8,230; python: 2,315; sh: 2,115; perl: 1,621; makefile: 499; xml: 496
file content (34 lines) | stat: -rw-r--r-- 1,412 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
From: Gustavo Romero <gromero@linux.vnet.ibm.com>
Subject: ppc64el float handling fix

I dug a bit further and it looks like that sam_parse1() is actually
generating a different value for the floats in question, so when they are
loaded back for the comparison they are already screwed up

because strtod() is used in float_to_le() and so also in u32_to_le(), which are
inlined and float_to_le() takes a float and not a double as the first argument
the use strtof() instead of strtod() in there looks the best, avoiding a
truncation from double to float, which might cause precision issues, specially
between different archs (like casts) plus optimization. So the following
change fixed the issue for me.

--- a/genomicsdb-htslib/sam.c
+++ b/genomicsdb-htslib/sam.c
@@ -1858,7 +1858,7 @@
         }
     } else if (type == 'f') {
         while (q < r) {
-            float_to_le(strtod(q + 1, &q), b->data + b->l_data);
+            float_to_le(strtof(q + 1, &q), b->data + b->l_data);
             b->l_data += 4;
             skip_to_comma_(q);
         }
@@ -2156,7 +2156,7 @@
             }
         } else if (type == 'f') {
             b->data[b->l_data++] = 'f';
-            float_to_le(strtod(q, &q), b->data + b->l_data);
+            float_to_le(strtof(q, &q), b->data + b->l_data);
             b->l_data += sizeof(float);
         } else if (type == 'd') {
             b->data[b->l_data++] = 'd';