<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 8/19/2010 8:14 AM, Marc MERLIN wrote:
    <blockquote cite="mid:20100819151414.GB1579@merlins.org" type="cite">
      <pre wrap="">On Thu, Aug 19, 2010 at 07:52:06AM -0700, Philip Peake wrote:
</pre>
      <blockquote type="cite">
        <pre wrap=""> Yes ... I am actually measuring two parameters.
One of them has fairly high numbers (in the 100's), the interpolation
(or whatever you want to call it) is ok there. The actual number
displayed is not too important as long as its something like right.

The second set of samples are more like:

    0 0 0 0 0 0 1 0 0 0 1 1 0 0 2 0 5 0 0 0 0 3 0 0 1 0 0 0 0 0 1

They are integer values. Displaying them as (for example) 0.666732134 is
meaningless.
</pre>
      </blockquote>
      <pre wrap="">
So if you don't have a workaround, at this point the fix is to give Tobias a
patch that doesn't break the common case.

Marc
</pre>
    </blockquote>
    I *think* that's fairly easy. But I only spent about 5 minutes last
    night looking at the source.<br>
    <br>
    I would start by adding a new command line option (<i>--dont_screw_with_gauge_data</i>
    or similar), and change this line:<br>
    <blockquote>&nbsp;<big><tt>rate = pdp_new[ds_idx] / interval;</tt></big><br>
    </blockquote>
    To look more like:<br>
    <blockquote><big><tt>if (dont_screw_with_gauge_data) {</tt></big><br>
      &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <tt>r<big>ate = pgp_new[ds_idx];<br>
          } else {<br>
          &nbsp;&nbsp; rate = pdp_new[ds_idx] / interval;<br>
          }<br>
        </big></tt></blockquote>
    Now your case, as I understand it (I didn't go back and look in the
    archives to fully understand what you wanted to do) is to store a
    set of bits. If that's true, that is a bit more work because it
    looks (in my 5 minutes of digging) that the values are stored as
    floating point values, not integer, so that would require a lot more
    digging to see how to do that. Its probably a quite pervasive change
    ....<br>
    <br>
    Rather than storing as a bit pattern, assuming you can avoid
    interpolation (with something like the above, or as Simon suggested,
    forcing the time to boundaries) you can use powers of ten:<br>
    <br>
    00001 -&gt; 10<br>
    00010 -&gt; 100<br>
    00100 -&gt; 1000<br>
    01000 -&gt; 10000<br>
    etc,<br>
    <br>
    adding up the total and storing that. floating point conversion is
    not going to lose that much precision.<br>
    To recover your bit pattern you start with the highest "bit" value,
    see if division by that is &gt; 1 (so bit is present), subtract that
    power of ten, repeat for the next lower power of ten etc.<br>
    <br>
    I *think* this would work ... you would need to play around with it
    ...<br>
    <blockquote><br>
    </blockquote>
  </body>
</html>