[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #32692] incorrect tick values when using fltk,
From: |
anonymous |
Subject: |
[Octave-bug-tracker] [bug #32692] incorrect tick values when using fltk, fix is suggested |
Date: |
Sun, 06 Mar 2011 17:12:09 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100403 Fedora/3.6.3-4.fc13 Firefox/3.6.3 |
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/
- [Octave-bug-tracker] [bug #32692] incorrect tick values when using fltk, fix is suggested,
anonymous <=