Tue Mar 19 15:53:57 2013, original submission:
A rounding problem occurs in gslhistogram when you try to make a histogram from pure integer data, where it is appropriate to choose a bin size of 1. I have tracked this down to the file histogram/init.c, where the array range is filled with the bin limits. There, in make_uniform one has
double f1 = ((double) (ni) / (double) n);
double f2 = ((double) i / (double) n);
range[i] = f1 * xmin + f2 * xmax;
In the case of e. g. xmin = 0.0, xmax = 60.0, n = 60, this (on my
system, gcc 4.6, standard make command from the file archive) leads to
range[31] = 31.000000000000003552713679
where it should be, without rounding error,
range[31] = 31.000000000000000000000000
This then leads to the number 31 being put into bin number 30, instead of 31. A bunch of uniformely distributed integer data would then lead to a peak of double the average height at 30, and no entry at 31. I have attached a sample list of integer data where the problem occurs (varlist.dat). As discussed in the corresponding thread [1] on the mailing list, a proposed solution is
double dx = (xmaxxmin) / (double) n;
double f1 = xmin + i*dx;
double f2 = xmax  (ni) * dx;
range[i] = (f1 + f2) * 0.5;
As I understand it, in particular after reading [2], there are certain special cases where floatingpoint arithmetic is just as accurate and errorfree as integer arithmetic. This should be fulfilled here, when xmin, xmax, n are real integer values (even though represented as doubles), and thus dx (=1), f1 and f2 are integer values as well.
[1] http://lists.gnu.org/archive/html/buggsl/201302/msg00006.html
[2] http://en.wikipedia.org/wiki/Doubleprecision_floatingpoint_format
