Floating-point issues in data compression using optimal predictors

Viewed 85

Does anyone have recommendations on ensuring the repeatability of floating-point operations across platforms for data compression using optimal predictors?

I have a Java implementation of data compression for terrestrial elevation and ocean depth information using the technique proposed by Smith and Lewis, 1994. The technique uses Lagrange Multipliers to find the coefficients for a predictor function that can be integrated into a lossless data compression operation. The results are pretty good. For SRTM elevation data, I am seeing average rates of 1.9 bits per value (more or less depending on local terrain). Implementation details are available at Lossless Compression for Raster Data using Optimal Predictors

I am porting my code to C/C++, but I am concerned about numerical precision issues. The method absolutely depends on the ability to get the same results for floating-point calculations when the data is stored and when the data is recovered. The key computation (there’s only one of them) is shown below (u and z variables are all IEEE-754 single-precision floats):

                float p
                = u1 * z1
                + (u2 * z2
                + (u3 * z3
                + (u4 * z4
                + (u5 * z5
                + (u6 * z6
                + (u7 * z7
                + (u8 * z8
                + (u9 * z9
                + (u10 * z10
                + (u11 * z11 + u12 * z12))))))))));
            int estimate = StrictMath.round(p); // this is the key result

The computation has a lot of extra parentheses because I wanted to avoid cases where a compiler might change associativity as part of its optimization.

I have run C-language tests processing millions of data points under Windows and Linux and, so far, I haven’t seen a single problem… Of course, I’ve been working on similar hardware and the same compiler (gcc) and a few hundred million points don’t really prove anything.

Would it be sufficient to include a compiler directive such as

#pragma float_control(precise, on)

Are there particular environments out there that will be problematic? Also, I have the source code for Java’s StrictMath.round method (it works directly on bits). Do I need to implement an explicit C version or are there stock C/C++ functions I can rely on to work the same way?

0 Answers
Related