Sun 06 Mar 2011 05:12:09 PM UTC, original submission:
A rounding error in magform routine in graphics.cc causes bad tick values for axis.
To recreate problem: using fltk, and command image(rand(25,900)*40), the x axis is labelled with about 40 or 50 scrunched numbers. For rand(25, something_else), we may see good or bad results.
I traced to routine magform, which takes a number, say 25.12345, computes its log, say 1.345678..., takes the fractional part (.345678) and subtracts from the log, to get 1.000000, but might get 0.9999999. When followed by int cast, the exponent is 0 or 1.
Here is my kludgy fix, and then a clean fix suggested:
ORIGINAL CODE:
double l = std::log10 (std::abs (x));
double r = std::fmod (l, 1.);
a = std::pow (10.0, r);
b = static_cast<int> (l-r);
if (a < 1)
{
a *= 10;
b -= 1;
}
if (x < 0)
a = -a;
KLUDGY FIX:
double l = std::log10 (std::abs (x));
double r = std::fmod (l, 1.);
a = std::pow (10.0, r);
double k = l-r; // JOB fix rounding problem, March 6, 2011
if (k < 0.0)
b = (int) (k - 0.5);
else
b = (int) (k + 0.5);
if (a < 1)
{
a *= 10;
b -= 1;
}
if (x < 0)
a = -a;
CLEAN FIX: (I've not tested, but should work fine)
b = static_cast<int> ( gnulib::floor (std::log10 (std::abs (x) ) ) );
a = x / std::pow (10.0, b);
END OF FIX (this is very short and compact solution)
Oddly, I've not seen this bug previously reported, so it may have to do with the floating point implementation on my chipset, or the use of guard bits in the fp registers ?
This routine magform, is also called with backend gnuplot. The incorrect tick values are computed, but then the plot appears correct -- perhaps gnuplot redoes the scaling on its own.
I have this version of fltk: fltk-1.1.10-1.fc13.i686
This is my first bug submission, sorry if its format turns out poor.
|