|
From: Allin C. <cot...@wf...> - 2008-12-23 03:00:08
|
Plotting the following wacky dataset (from a test for statistical programs by Leland Wilkinson)... obs y x 1 99999991 0.99999991 2 99999992 0.99999992 3 99999993 0.99999993 4 99999994 0.99999994 5 99999995 0.99999995 6 99999996 0.99999996 7 99999997 0.99999997 8 99999998 0.99999998 9 99999999 0.99999999 gnuplot does fine, except that it puts "1" for each of 11 x-axis tics, and "1e+08" for each of 6 y-axis tics, which looks a little brain-damaged. The tic marks can, of course, be improved manually, but it's a bit of a sweat, particularly since the C'ism '#' does not seem to be recognized in format strings (I mean, as in "%#.8g"). Any thoughts on whether it's worth working on making the tics look better by default for this sort of case? -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-23 03:08:26
|
On Monday 22 December 2008, Allin Cottrell wrote: > Plotting the following wacky dataset (from a test for statistical > programs by Leland Wilkinson)... > > obs y x > > 1 99999991 0.99999991 > 2 99999992 0.99999992 > 3 99999993 0.99999993 > 4 99999994 0.99999994 > 5 99999995 0.99999995 > 6 99999996 0.99999996 > 7 99999997 0.99999997 > 8 99999998 0.99999998 > 9 99999999 0.99999999 > > gnuplot does fine, except that it puts "1" for each of 11 x-axis > tics, and "1e+08" for each of 6 y-axis tics, which looks a little > brain-damaged. > > The tic marks can, of course, be improved manually, but it's a bit > of a sweat, particularly since the C'ism '#' does not seem to be > recognized in format strings (I mean, as in "%#.8g"). > > Any thoughts on whether it's worth working on making the tics look > better by default for this sort of case? There's already a feature request open for this issue: 2007285 Auto-expand number of digits for tics with small axis range But it's a surprisingly hard thing to fix. Patches welcome. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Allin C. <cot...@wf...> - 2008-12-24 21:22:59
|
On Mon, 22 Dec 2008, Ethan A Merritt wrote:
> On Monday 22 December 2008, Allin Cottrell wrote:
> > Plotting the following wacky dataset (from a test for statistical
> > programs by Leland Wilkinson)...
> >
> > obs y x
> >
> > 1 99999991 0.99999991
> > 2 99999992 0.99999992 <etc>
> >
> > gnuplot does fine, except that it puts "1" for each of 11 x-axis
> > tics, and "1e+08" for each of 6 y-axis tics, which looks a little
> > brain-damaged...
> >
> > Any thoughts on whether it's worth working on making the tics look
> > better by default for this sort of case?
>
> There's already a feature request open for this issue:
> 2007285 Auto-expand number of digits for tics with small axis range
>
> But it's a surprisingly hard thing to fix.
> Patches welcome.
I've taken a look in axis.c, but I don't yet have a good
understanding of the machinery therein. But I've found that this
heuristic hack seems to work quite nicely at the caller level and
something of the sort could perhaps be written into axis.c:
1. Write the min and max data values into strings using the
default precision for tic labels. If these strings are identical,
then compute the minimal precision required to make them differ,
add one, and write this into the <axis> format using "%% .%dg".
To get the required precision I'm doing something like:
for (d=6; d<12; d++) {
sprintf(s1, "%.*g", d, vmin);
sprintf(s2, "%.*g", d, vmax);
if (strcmp(s1, s2)) {
break;
}
}
2. Set the axis tics using start = (the min data value) and incr =
(max data value - min data value) / 4.0.
E.g., for the x-axis with the data I mentioned:
set format x "% .8g"
set xtics 0.99999991 2.00000e-08
Merry Christmas!
Allin Cottrell
|
|
From: Allin C. <cot...@wf...> - 2008-12-27 16:38:59
Attachments:
util.c.diff
|
Please find attached a little patch to util.c which supports the '#' flag for gprintf, for formats where it is supported by C's printf. Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2008-12-27 16:44:23
Attachments:
util.c.diff
|
On Sat, 27 Dec 2008, Allin Cottrell wrote: > Please find attached a little patch to util.c which supports > the '#' flag for gprintf, for formats where it is supported by > C's printf. Oof, patch came complete with bug. This should be better. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-27 20:25:17
|
On Saturday 27 December 2008, Allin Cottrell wrote:
> On Sat, 27 Dec 2008, Allin Cottrell wrote:
>
> > Please find attached a little patch to util.c which supports
> > the '#' flag for gprintf, for formats where it is supported by
> > C's printf.
Added to CVS.
NB: that test can be done more economically as
+ if (got_hash && (format == strpbrk(format,"oeEfFgG"))) {
+ reset_numeric_locale();
+ int_error(NO_CARET, "Bad format character");
+ }
--
Ethan A Merritt
|