<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
FYI<br>
<br>
On Friday I discovered that the original BDFReader has a flaw that
causes ~0.4% of the float range to be read incorrectly. The code
attempts to read the float value from the binary sections of the BDF
file into a Java float as BigEndian. It then checks the BDFHeader to
see if the byte-order is actually LittleEndian and if it is (which is
always is), it reverses the bytes and creates a new float.<br>
<br>
The problem arises because there are "illegal" bit patterns for a float
in Java. Per the Java 6 JavaDocs, "If the argument is any value in the
range <code>0x7f800001</code> through <code>0x7fffffff</code> or in
the range <code>0xff800001</code> through <code>0xffffffff</code>,
the result is a NaN." Reversing the byte-order of Float.NAN results in
6.9055E-41 which is the number the BDFReader returned for any floats in
the "illegal" ranges. If the bytes had be read as LittleEndian in the
first place this would never happen and the code now does this.<br>
<br>
As far as TelCal is concerned (which is the only user of the BDFReader
that I'm aware of), this bug existed until June 15, when I deployed a
new version of TelCal (1.5.14) that used the new bdfReader2 code.<br>
<br>
More analysis would be needed to see how much of our pre-June15 data
mapped to the "illegal" ranges.<br>
<br>
It should be noted that the June 15 deployment of TelCal also adjusted
the flagged integration range so that flags apply to integrations
before and after the integration the flag occurred during, without
crossing subscan boundaries. This flagging change plus the BigEndian
fix should result in higher quality data since June 15, all else being
equal.<br>
<br>
-Keith<br>
</body>
</html>