[Octave-bug-tracker] [bug #32692] incorrect tick values when using fltk, fix is suggested

[anonymous]

URL:
  <http://savannah.gnu.org/bugs/?32692>

                 Summary: incorrect tick values when using fltk, fix is
suggested
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Sun 06 Mar 2011 05:12:09 PM UTC
                Category: Plotting
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: Jim O'Brien
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 3.4.0
        Operating System: GNU/Linux

    _______________________________________________________

Details:

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.







    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?32692>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/