gnuplot-beta — Developers and beta testers of new gnuplot code

Re: [PATCH] Unit tests don't use the local user's .gnuplot file

[Hans-Bernhard B. <HBB...@t-...>]

On 20.10.2012 19:20, sfeam (Ethan Merritt) wrote:

> I like the idea of providing a way to suppress reading ~/.gnuplot.

Well, one could always just brush the file under the carpet, e.g.:

	env HOME=/some/where/else gnuplot

Look, Ma --- no need for a special option!

>> This is done primarily so that unit tests test the stock configuration

> For simple doesn't-crash sanity checks after applying a patch,
> I usually add any relevant options to ~/.gnuplot and run
> "make check".

I'm afraid that achieves rather a lot less than it's meant to.  Settings 
from ~/.gnuplot don't survive the first "reset" (at the end of simple.dem).

Re: [PATCH] x11 terminal respects the requested aspect ratio

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 20 October 2012, Daniel J Sebald wrote:
> > Scenario: one might think that a series of points connected
> > by lines could be drawn as
> >    P(x1,y1) V(x2,y2) P(x2,y2) V(x3,y3) ...
> > But that doesn't work because P(x1,y1) doesn't leave the current
> > position at (x1,y1).  So instead one needs to do
> >    P(x1,y1) M(x1,y1) V(x2,y2) P(x2,y2) M(x2,y2) V(x3,y3) ...
> > My point is that all the M commands may seem redundant but they are not.
> > [NB: This is not the ordering produced by "with linespoints"]
> 
> Might it pay to add another symbol that means both P (draw point) and M 
> (move)?  

No. If you wanted to make P(x,y) leave the current position at (x,y)
you'd modify the point drawing code in gnuplot_x11.  But then you pay
the price, admittedly a very small price, of executing an extra move
that is unnecessary in virtually all cases.

> I'd guess for some plots with many points, the data stream 
> consists mainly of P/M commands.  

If the plot contains only points then no move commands are necessary,
since the term->point(x, y, pointtype) already contains the coordinates.

From what I've seen in working on other terminal types, the most
common types of redundancy in order of frequency are

(1) successive set_color or linetype commands that do nothing.
    This happens when the core routines loop over some set of
    objects expecting each one to require a new lt or color, but then 
    some of them are not actually drawn (out of range, blank text label,
    both linetype and color are given but the latter supercedes the
    former, ...) So you get
       set color for point 1
       (oops, no point 1)
       set color for point 2
       (oops, no point 2)
       set color for point 3
       (oops, point 3 has its own color spec)
       set _real_ color for point 3
       draw point 3

(2) a sequence of vector() commands that are effectively duplicates
    due to the coarse screen resolution.

(3) a sequence of line segments drawn independently but nevertheless
    arranged head-to-tail:  M(x1,y1) V(x2,y2),  M(x2,y2) V(x3,y3),  ...
 
(4) a sequence of move() commands, of which only the last one is needed


I suspect only (1) and (2) are worth worrying about in practice,
although you could probably construct some pathological examples
of other redundancy.

Re: [PATCH] Unit tests don't use the local user's .gnuplot file

[Daniel J S. <dan...@ie...>]

On 10/20/2012 12:20 PM, sfeam (Ethan Merritt) wrote:
> On Saturday, 20 October 2012, Dima Kogan wrote:
>> I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
>> .gnuplot and gnuplotrc files.
>
> I like the idea of providing a way to suppress reading ~/.gnuplot.
>
> Minor quibble: Isn't "-q" usually short for "--quiet" and interpreted
> as a request to suppress output rather than input?

Yes, save "-q" for "--quiet".


> Not that I have a better letter of the alphabet to suggest....

Tossing out some ideas:

   -n, --nostartup
   -s, --skip
   -f, --factory

No great ones there.  Any others?

Dan

PS:  I just noticed on the help output that there is a comma missing for 
the "-p" entry:

Usage: gnuplot [OPTION]... [FILE]
for X11 options see 'help X11->command-line-options'
   -V, --version
   -h, --help
   -p  --persist
   -e  "command1; command2; ..."

>
>> This is done primarily so that unit tests test the stock configuration
>
> Hmm. I usually want the opposite.
> E.g. if I want to make sure that "set someoption obscure" doesn't
> trigger memory leaks, I put it in ~/.gnuplot and then run the
> unit tests under valgrind.
> For simple doesn't-crash sanity checks after applying a patch,
> I usually add any relevant options to ~/.gnuplot and run
> "make check".
>
> 	Ethan
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Daniel J S. <dan...@ie...>]

On 10/20/2012 11:41 AM, sfeam (Ethan Merritt) wrote:
> On Friday, 19 October 2012, Dima Kogan wrote:
>>> On Wed, 3 Oct 2012 10:21:19 -0700
>>> Ethan A Merritt<sf...@us...>  wrote:
>>>
>>> On Wednesday, October 03, 2012 01:39:08 am Dima Kogan wrote:
>>>>> On Sat, 29 Sep 2012 17:07:51 -0700
>>>>> Ethan Merritt<merritt@u.washington.edu>  wrote:
>>>>>
>>>>>> 6. Removing duplicate messages (such as duplicate consecutive V commands) sounds
>>>>>>     great. We should do it
>>>>>    OK. Low priority because it's relatively rare for normal plots.
>>>>
>>>> I did a first pass at this. Patch attached. Good news is that as expected, the
>>>> traffic drops dramatically. Inboard timing drops from about 0.9s to about 0.45s.
>>>> The outboard, however, drops from 0.85s to 0.01s! The reason the inboard didn't
>>>> drop as much is that it still has to parse the original huge data file. I have
>>>> some lingering concerns about the patch I'm attaching.
>>>
>>>> I use ftell() to check to see that the V commands are indeed consecutive.
>>>> This might have a non-negligible cost, so I'd check before committing this.
>>>
>>> That's clever, but I agree that there is potential cost.
>>> Other terminal drivers do the same job without resorting to ftell().
>>> The trick is that any command that potentially affects the current
>>> active position must either update or invalidate the inboard copy
>>> of x_last and y_last.   For example,  term->put_text() would set
>>>    x_last = y_last = INVALID;           /* #define INVALID -1 */
>>> before leaving.
>>>
>>> The down side is that unlike your ftell() version this approach requires
>>> finding all the places that might affect current position.  I've attached a
>>> first-pass patch that catches most of them, but I probably missed some.
>>> Other terminal drivers can serve as a model.
>>>
>>>
>>>> At this point, my test case is clearly broken since we've been able to optimize
>>>> away all its complexity.
>>>
>>> Right.  I modified your original data generation script to produce longer
>>> vectors and some gaps, so the the plot would contain move commands as well
>>> as vector commands.  This gives a more realistic mix of commands:
>>>
>>> perl -e 'for(0..2000000) \
>>>   { print "$_ " . sin($_/1000) . "\n"; print "\n" if $_ % 100 == 0; }' \
>>>   >  breaks.ascii
>>>
>>> With this test data the reduction in size from removing redundant commands
>>> is less than 10%.  I tested using the "uniq" command rather than patching
>>> the driver source code.  10% max didn't seem very significant to me,
>>> which was why I said it was low priority.
>>>
>>>> Is the same optimization valid for P commands?
>>>
>>> I don't think so.  But it does apply to M commands.
>>>
>>>> I'm thinking of just generating a bunch of discrete points, and sending
>>>> them over as P commands. That sounds good, right?
>>>
>>> I don't think that the active position after drawing a point symbol is
>>> guaranteed to be at the center of the point.  So in the sequence
>>>    Move(x,y);  Point(x,y);  Move(x,y); Vector(x1,y1);
>>> the second Move is not redundant.
>>>
>>> Of course, we could change the code so that Point(x,y) it _is_ guaranteed
>>> to leave the active position at (x,y).
>>
>>
>> OK. I revisited this (duplication suppression). Patch attached. I believe this
>> optimization is equally applicable to P, M, and V. Note that this is all purely
>> inboard, so there's no active position at all; that's an outboard concept. So
>> for instance, a duplicated P command would normally draw the same point glyph
>> multiple times in the same exact position, thus removing the duplication doesn't
>> change the output. Tell me if I'm misunderstanding.
>
> I think you are not unstanding what I was trying to say.  The issue is not whether
> repeated P commands are redundant, the question is whether or not a M command is
> needed after the P.  Scenario: one might think that a series of points connected
> by lines could be drawn as
>    P(x1,y1) V(x2,y2) P(x2,y2) V(x3,y3) ...
> But that doesn't work because P(x1,y1) doesn't leave the current position
> at (x1,y1).  So instead one needs to do
>    P(x1,y1) M(x1,y1) V(x2,y2) P(x2,y2) M(x2,y2) V(x3,y3) ...
> My point is that all the M commands may seem redundant but they are not.
> [NB: This is not the ordering produced by "with linespoints"]

Might it pay to add another symbol that means both P (draw point) and M 
(move)?  I'd guess for some plots with many points, the data stream 
consists mainly of P/M commands.  Then again, it has to be encoded so 
that point/vector are done at the same time.  If gnuplot first draws the 
line connecting points, then draws the series of points, a combination 
P/M command doesn't help any.

Dan

Re: [PATCH] Unit tests don't use the local user's .gnuplot file

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 20 October 2012, Dima Kogan wrote:
> I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
> .gnuplot and gnuplotrc files. 

I like the idea of providing a way to suppress reading ~/.gnuplot.

Minor quibble: Isn't "-q" usually short for "--quiet" and interpreted
as a request to suppress output rather than input?
Not that I have a better letter of the alphabet to suggest....

> This is done primarily so that unit tests test the stock configuration

Hmm. I usually want the opposite.
E.g. if I want to make sure that "set someoption obscure" doesn't
trigger memory leaks, I put it in ~/.gnuplot and then run the
unit tests under valgrind.
For simple doesn't-crash sanity checks after applying a patch,
I usually add any relevant options to ~/.gnuplot and run
"make check".

	Ethan

Re: [PATCH] x11 terminal respects the requested aspect ratio

[sfeam (E. Merritt) <eam...@gm...>]

On Friday, 19 October 2012, Dima Kogan wrote:
> > On Wed, 3 Oct 2012 10:21:19 -0700
> > Ethan A Merritt <sf...@us...> wrote:
> >
> > On Wednesday, October 03, 2012 01:39:08 am Dima Kogan wrote:
> > > > On Sat, 29 Sep 2012 17:07:51 -0700
> > > > Ethan Merritt <merritt@u.washington.edu> wrote:
> > > >
> > > > > 6. Removing duplicate messages (such as duplicate consecutive V commands) sounds
> > > > >    great. We should do it
> > > >   OK. Low priority because it's relatively rare for normal plots.
> > > 
> > > I did a first pass at this. Patch attached. Good news is that as expected, the
> > > traffic drops dramatically. Inboard timing drops from about 0.9s to about 0.45s.
> > > The outboard, however, drops from 0.85s to 0.01s! The reason the inboard didn't
> > > drop as much is that it still has to parse the original huge data file. I have
> > > some lingering concerns about the patch I'm attaching. 
> > 
> > > I use ftell() to check to see that the V commands are indeed consecutive.
> > > This might have a non-negligible cost, so I'd check before committing this.
> > 
> > That's clever, but I agree that there is potential cost.
> > Other terminal drivers do the same job without resorting to ftell().
> > The trick is that any command that potentially affects the current
> > active position must either update or invalidate the inboard copy
> > of x_last and y_last.   For example,  term->put_text() would set
> >   x_last = y_last = INVALID;           /* #define INVALID -1 */
> > before leaving.
> > 
> > The down side is that unlike your ftell() version this approach requires
> > finding all the places that might affect current position.  I've attached a 
> > first-pass patch that catches most of them, but I probably missed some.
> > Other terminal drivers can serve as a model.
> > 
> >  
> > > At this point, my test case is clearly broken since we've been able to optimize
> > > away all its complexity.
> > 
> > Right.  I modified your original data generation script to produce longer
> > vectors and some gaps, so the the plot would contain move commands as well
> > as vector commands.  This gives a more realistic mix of commands:
> > 
> > perl -e 'for(0..2000000) \
> >  { print "$_ " . sin($_/1000) . "\n"; print "\n" if $_ % 100 == 0; }' \
> >  > breaks.ascii
> > 
> > With this test data the reduction in size from removing redundant commands
> > is less than 10%.  I tested using the "uniq" command rather than patching 
> > the driver source code.  10% max didn't seem very significant to me,
> > which was why I said it was low priority.
> > 
> > > Is the same optimization valid for P commands? 
> > 
> > I don't think so.  But it does apply to M commands.
> > 
> > > I'm thinking of just generating a bunch of discrete points, and sending 
> > > them over as P commands. That sounds good, right?
> > 
> > I don't think that the active position after drawing a point symbol is 
> > guaranteed to be at the center of the point.  So in the sequence
> >   Move(x,y);  Point(x,y);  Move(x,y); Vector(x1,y1);
> > the second Move is not redundant.
> > 
> > Of course, we could change the code so that Point(x,y) it _is_ guaranteed
> > to leave the active position at (x,y).  
> 
> 
> OK. I revisited this (duplication suppression). Patch attached. I believe this
> optimization is equally applicable to P, M, and V. Note that this is all purely
> inboard, so there's no active position at all; that's an outboard concept. So
> for instance, a duplicated P command would normally draw the same point glyph
> multiple times in the same exact position, thus removing the duplication doesn't
> change the output. Tell me if I'm misunderstanding.

I think you are not unstanding what I was trying to say.  The issue is not whether
repeated P commands are redundant, the question is whether or not a M command is
needed after the P.  Scenario: one might think that a series of points connected
by lines could be drawn as
  P(x1,y1) V(x2,y2) P(x2,y2) V(x3,y3) ...
But that doesn't work because P(x1,y1) doesn't leave the current position
at (x1,y1).  So instead one needs to do
  P(x1,y1) M(x1,y1) V(x2,y2) P(x2,y2) M(x2,y2) V(x3,y3) ...
My point is that all the M commands may seem redundant but they are not.
[NB: This is not the ordering produced by "with linespoints"]
  
> Conclusions:
> 
> 1. ftell() is way too slow
> 2. the code with the attached patch is significantly faster than before in the
>    best case, and about the same in the worst case

I've been too busy to have a serious look at your non-redundancy patch,
but at first glance it looks more complicated than necessary.
Do you really need to set X11_IPC_LASTDATARUN_NONE for every single
command that doesn't change the current position?  
Other terminal drivers manage just fine without this.  
If the small set of commands that _do_ change the position (M, V, P, T, ??)
track the current position then no one else needs to care.

	Ethan

> Next, I'm going to look into binary communication again.
> 
> dima
> 

Re: [PATCH] better citizen gnuplot emacs mode

[Jon O. <jon...@gm...>]

I did some more work on the devel branch of gnuplot-mode and I think it
is in a good state to be tested for a new release, if Bruce agrees.

Most importantly, it's now backward-compatible with GNU Emacs 22 (from
2007) and XEmacs 21 (the latest version, from 2003).  I can't fully
check XEmacs compatibility because it segfaults when running on an X
display on my mac, but it does work in a terminal.  I would guess that
in this case working with XEmacs 21 also implies working with GNU Emacs
21, but I haven't been able to install any pre-22 GNU Emacs to try it
out.

I'm still not sure of the best way to get people to test a new version.
It's tempting to simply put a new release on Marmalade[1] and MELPA[2]
and wait for bug reports to come in.  MELPA just packages up whatever is
in github master branches anyway, so I think people are accustomed to
running the latest development versions of Emacs plugins.  The newer
version could then be incorporated in the gnuplot repository after a few
months, if there are no major issues reported.

Thoughts?

Jon



Footnotes: 
[1]  http://marmalade-repo.org/

[2]  http://melpa.milkbox.net/

[PATCH] Unit tests don't use the local user's .gnuplot file

[Dima K. <gn...@di...>]

I'm attaching a patch to add a "-q" option to gnuplot to suppress parsing of
.gnuplot and gnuplotrc files. This is done primarily so that unit tests test the
stock configuration

dima

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Ethan M. <merritt@u.washington.edu>]

On Friday, 19 October 2012, Dima Kogan wrote:
> > On Sun, 7 Oct 2012 12:14:51 -0700
> > Dima Kogan <gn...@di...> wrote:
> >
> > > On Sat, 29 Sep 2012 17:07:51 -0700
> > > Ethan Merritt <merritt@u.washington.edu> wrote:
> > >
> > > On Saturday, 29 September 2012, Dima Kogan wrote:
> > > >
> > > > 5. Adding default window size to the inboard x11 driver so that the 'terminal
> > > >    xlib' produces plots that have decent defaults when sent to the outboard
> > > >    driver manually. I'll do this.
> > >
> > >   OK.  It's not just xlib, however.  I think (not 100% sure) that the same 
> > >   problem arises whenever (ipc_back_fd == IPC_BACK_UNUSABLE), e.g. x11 output
> > >   from a script run non-interactively.
> > 
> > Attached is a patch to address this.
> 
> This wasn't merged yet. Is there something wrong with this patch, or did it just
> fall through the cracks?

Sitting somewhere in my in-box. Sorry.
Applied now.

	Ethan

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Dima K. <gn...@di...>]

> On Wed, 3 Oct 2012 10:21:19 -0700
> Ethan A Merritt <sf...@us...> wrote:
>
> On Wednesday, October 03, 2012 01:39:08 am Dima Kogan wrote:
> > > On Sat, 29 Sep 2012 17:07:51 -0700
> > > Ethan Merritt <merritt@u.washington.edu> wrote:
> > >
> > > > 6. Removing duplicate messages (such as duplicate consecutive V commands) sounds
> > > >    great. We should do it
> > >   OK. Low priority because it's relatively rare for normal plots.
> > 
> > I did a first pass at this. Patch attached. Good news is that as expected, the
> > traffic drops dramatically. Inboard timing drops from about 0.9s to about 0.45s.
> > The outboard, however, drops from 0.85s to 0.01s! The reason the inboard didn't
> > drop as much is that it still has to parse the original huge data file. I have
> > some lingering concerns about the patch I'm attaching. 
> 
> > I use ftell() to check to see that the V commands are indeed consecutive.
> > This might have a non-negligible cost, so I'd check before committing this.
> 
> That's clever, but I agree that there is potential cost.
> Other terminal drivers do the same job without resorting to ftell().
> The trick is that any command that potentially affects the current
> active position must either update or invalidate the inboard copy
> of x_last and y_last.   For example,  term->put_text() would set
>   x_last = y_last = INVALID;           /* #define INVALID -1 */
> before leaving.
> 
> The down side is that unlike your ftell() version this approach requires
> finding all the places that might affect current position.  I've attached a 
> first-pass patch that catches most of them, but I probably missed some.
> Other terminal drivers can serve as a model.
> 
>  
> > At this point, my test case is clearly broken since we've been able to optimize
> > away all its complexity.
> 
> Right.  I modified your original data generation script to produce longer
> vectors and some gaps, so the the plot would contain move commands as well
> as vector commands.  This gives a more realistic mix of commands:
> 
> perl -e 'for(0..2000000) \
>  { print "$_ " . sin($_/1000) . "\n"; print "\n" if $_ % 100 == 0; }' \
>  > breaks.ascii
> 
> With this test data the reduction in size from removing redundant commands
> is less than 10%.  I tested using the "uniq" command rather than patching 
> the driver source code.  10% max didn't seem very significant to me,
> which was why I said it was low priority.
> 
> > Is the same optimization valid for P commands? 
> 
> I don't think so.  But it does apply to M commands.
> 
> > I'm thinking of just generating a bunch of discrete points, and sending 
> > them over as P commands. That sounds good, right?
> 
> I don't think that the active position after drawing a point symbol is 
> guaranteed to be at the center of the point.  So in the sequence
>   Move(x,y);  Point(x,y);  Move(x,y); Vector(x1,y1);
> the second Move is not redundant.
> 
> Of course, we could change the code so that Point(x,y) it _is_ guaranteed
> to leave the active position at (x,y).  


OK. I revisited this (duplication suppression). Patch attached. I believe this
optimization is equally applicable to P, M, and V. Note that this is all purely
inboard, so there's no active position at all; that's an outboard concept. So
for instance, a duplicated P command would normally draw the same point glyph
multiple times in the same exact position, thus removing the duplication doesn't
change the output. Tell me if I'm misunderstanding.

I took your suggestion to keep track of pipe accesses myself, instead of using
ftell. I'm troubled by the manual maintenance this requires, but the performance
difference looks significant.

The data file you generated in your post had fewer duplicates because it was a
much higher frequency sinusoid, so it was aliasing heavily. I took measurements
from a highly redundant sinusoid and a highly aliased one:


No suppression at all:

|      | /1e6 (1% uniq) | /500 dataset (90% uniq) |
|------+----------------+-------------------------|
| user |           0.91 |                    0.92 |
| sys  |           0.20 |                    0.21 |


Suppression with attached patch:

|      | /1e6 (1% uniq) | /500 dataset (90% uniq) |
|------+----------------+-------------------------|
| user |           0.40 |                    0.89 |
| sys  |           0.14 |                    0.19 |


Suppression with ftell:

|      | /1e6 (1% uniq) | /500 dataset (90% uniq) |
|------+----------------+-------------------------|
| user |           0.46 |                    1.75 |
| sys  |           0.21 |                     4.3 |



Conclusions:

1. ftell() is way too slow
2. the code with the attached patch is significantly faster than before in the
   best case, and about the same in the worst case

Next, I'm going to look into binary communication again.

dima

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Dima K. <gn...@di...>]

> On Sun, 7 Oct 2012 12:14:51 -0700
> Dima Kogan <gn...@di...> wrote:
>
> > On Sat, 29 Sep 2012 17:07:51 -0700
> > Ethan Merritt <merritt@u.washington.edu> wrote:
> >
> > On Saturday, 29 September 2012, Dima Kogan wrote:
> > >
> > > 5. Adding default window size to the inboard x11 driver so that the 'terminal
> > >    xlib' produces plots that have decent defaults when sent to the outboard
> > >    driver manually. I'll do this.
> >
> >   OK.  It's not just xlib, however.  I think (not 100% sure) that the same 
> >   problem arises whenever (ipc_back_fd == IPC_BACK_UNUSABLE), e.g. x11 output
> >   from a script run non-interactively.
> 
> Attached is a patch to address this.

This wasn't merged yet. Is there something wrong with this patch, or did it just
fall through the cracks?

Thanks
dima

Re: excluding NaN from fit

[<pl...@pi...>]

On 10/17/12 23:07, Ethan A Merritt wrote:
> On Wednesday, October 17, 2012 01:29:46 pm pl...@pi... wrote:
>> Hi,
>>
>> I was just trying to do a fit command on some data but excluding  a
>> certain range where the data is perturbed by something else.
>>
>> I ttied an analogous method to using NaN in plot where points evaluating
>> to NaN get ignored.  However it seems that with fit they are counted
>> which basically screws things up entirely.
>
> The plot commands and the fit command use exactly the same data input
> routine df_readline(), and I can see in the source that fit.c skips any
> points that return DF_UNDEFINED from df_readline().
> So there must be more to it than that.
>
> On the other hand, there were indeed a few changes in the development
> version related to how NaN values are handled on input.
> Is it possible for you to check whether you get the same result in
> 4.6.0 and current CVS?
>
> 	Ethan
>
>>
>>
>>    fit [:2001] ts_model(x) datafile using 1:2 via x1,a1,p1, x2,a2,p2,a3,p3,x3
>>
>>
>> After 1 iterations the fit converged.
>> final sum of squares of residuals : nan
>> abs. change during last iteration : nan
>>
>> degrees of freedom    (FIT_NDF)                        : 169
>> rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : nan
>> variance of residuals (reduced chisquare) = WSSR/ndf   : nan
>>
>> Final set of parameters            Asymptotic Standard Error
>> =======================            ==========================
>>
>> x1              = nan              +/- nan          (nan%)
>> a1              = 0.01             +/- nan          (nan%)
>> p1              = 3                +/- nan          (nan%)
>> x2              = nan              +/- nan          (nan%)
>> a2              = 0.01             +/- nan          (nan%)
>> p2              = 20               +/- nan          (nan%)
>> a3              = 0.01             +/- nan          (nan%)
>> p3              = 60               +/- nan          (nan%)
>> x3              = 2006.12          +/- nan          (nan%)
>>
>>
>> correlation matrix of the fit parameters:
>>
>>                  x1     a1     p1     x2     a2     p2     a3     p3
>> x3
>> x1                nan
>> a1                nan    nan
>> p1                nan    nan    nan
>> x2                nan    nan    nan    nan
>> a2                nan    nan    nan    nan    nan
>> p2                nan    nan    nan    nan    nan    nan
>> a3                nan    nan    nan    nan    nan    nan    nan
>> p3                nan    nan    nan    nan    nan    nan    nan    nan
>> x3                nan    nan    nan    nan    nan    nan    nan    nan
>>     nan
>> gnuplot> fit [:2001] ts_model(x) datafile using
>> 1:((($1<1980)&&($1>1984))?$2:NaN) via x1,a1,p1, x2,a2,p2,a3,p3,x3
>>
>>
>>
>>
>> Now I can see how this would be happening but I wonder if it has any use
>> at all as a result.
>>
>> In practice this means that any dataset that contains even one NaN
>> coordinate or one point where 'using' evaluates to NaN, cannot be used
>> with the fit command.
>>
>> Now since plot and fit generally try to work in a parallel fashion, I
>> was expecting fit to _exclude_ from its calculations the points that I
>> had made evaluate to NaN.
>>
>> If this worked , it would be fundamentally useful. Is there any reason
>> why the current behaviour is useful or essential.
>>
>> Would it be preferable to simply skip data points with a NaN in a
>> similar way to what plot does?
>>
>> best regards, Peter.
>>

Hi Ethan,

this was found on the following CVS build:

   G N U P L O T
         Version 4.7 patchlevel 0    last modified 2012-03-02
         Build System: Linux i686


I've trimmed it down to a test case that throws the error, without the 
conditional in the using clause it works as expected.

One thing that seems odd is:
 > After 1 iterations the fit converged.
 > final sum of squares of residuals : nan

Firstly what is "nan" ?! Second , why did it return a result that it 
converged when the presence of NaN (or nan)  would be expected to be a 
non result rather than convergence?

Is nan perhaps zero !

Does that help?

/Peter




gnuplot> fit  a*cos(x) "-" using 1:(($1>3)?$2:NaN)  via a
input data ('e' ends) > 1 1
input data ('e' ends) > 2 2
input data ('e' ends) > 3 1
input data ('e' ends) > 4 4
input data ('e' ends) > e



  Iteration 0
  WSSR        : nan               delta(WSSR)/WSSR   : 0
  delta(WSSR) : nan               limit for stopping : 1e-05
  lambda   : 0.684186

initial set of free parameter values

a               = -0.887069
*********************
After 1 iterations the fit converged.
final sum of squares of residuals : nan
abs. change during last iteration : nan

degrees of freedom    (FIT_NDF)                        : 3
rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : nan
variance of residuals (reduced chisquare) = WSSR/ndf   : nan

Final set of parameters            Asymptotic Standard Error
=======================            ==========================

a               = -0.887069        +/- nan          (nan%)


correlation matrix of the fit parameters:

                a
a               1.000

Re: excluding NaN from fit

[Ethan A M. <sf...@us...>]

On Wednesday, October 17, 2012 01:29:46 pm pl...@pi... wrote:
> Hi,
> 
> I was just trying to do a fit command on some data but excluding  a 
> certain range where the data is perturbed by something else.
> 
> I ttied an analogous method to using NaN in plot where points evaluating 
> to NaN get ignored.  However it seems that with fit they are counted 
> which basically screws things up entirely.

The plot commands and the fit command use exactly the same data input
routine df_readline(), and I can see in the source that fit.c skips any
points that return DF_UNDEFINED from df_readline(). 
So there must be more to it than that.

On the other hand, there were indeed a few changes in the development
version related to how NaN values are handled on input.  
Is it possible for you to check whether you get the same result in 
4.6.0 and current CVS?

	Ethan

> 
> 
>   fit [:2001] ts_model(x) datafile using 1:2 via x1,a1,p1, x2,a2,p2,a3,p3,x3
> 
> 
> After 1 iterations the fit converged.
> final sum of squares of residuals : nan
> abs. change during last iteration : nan
> 
> degrees of freedom    (FIT_NDF)                        : 169
> rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : nan
> variance of residuals (reduced chisquare) = WSSR/ndf   : nan
> 
> Final set of parameters            Asymptotic Standard Error
> =======================            ==========================
> 
> x1              = nan              +/- nan          (nan%)
> a1              = 0.01             +/- nan          (nan%)
> p1              = 3                +/- nan          (nan%)
> x2              = nan              +/- nan          (nan%)
> a2              = 0.01             +/- nan          (nan%)
> p2              = 20               +/- nan          (nan%)
> a3              = 0.01             +/- nan          (nan%)
> p3              = 60               +/- nan          (nan%)
> x3              = 2006.12          +/- nan          (nan%)
> 
> 
> correlation matrix of the fit parameters:
> 
>                 x1     a1     p1     x2     a2     p2     a3     p3 
> x3
> x1                nan
> a1                nan    nan
> p1                nan    nan    nan
> x2                nan    nan    nan    nan
> a2                nan    nan    nan    nan    nan
> p2                nan    nan    nan    nan    nan    nan
> a3                nan    nan    nan    nan    nan    nan    nan
> p3                nan    nan    nan    nan    nan    nan    nan    nan
> x3                nan    nan    nan    nan    nan    nan    nan    nan 
>    nan
> gnuplot> fit [:2001] ts_model(x) datafile using 
> 1:((($1<1980)&&($1>1984))?$2:NaN) via x1,a1,p1, x2,a2,p2,a3,p3,x3
> 
> 
> 
> 
> Now I can see how this would be happening but I wonder if it has any use 
> at all as a result.
> 
> In practice this means that any dataset that contains even one NaN 
> coordinate or one point where 'using' evaluates to NaN, cannot be used 
> with the fit command.
> 
> Now since plot and fit generally try to work in a parallel fashion, I 
> was expecting fit to _exclude_ from its calculations the points that I 
> had made evaluate to NaN.
> 
> If this worked , it would be fundamentally useful. Is there any reason 
> why the current behaviour is useful or essential.
> 
> Would it be preferable to simply skip data points with a NaN in a 
> similar way to what plot does?
> 
> best regards, Peter.
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

excluding NaN from fit

[<pl...@pi...>]

Hi,

I was just trying to do a fit command on some data but excluding  a 
certain range where the data is perturbed by something else.

I ttied an analogous method to using NaN in plot where points evaluating 
to NaN get ignored.  However it seems that with fit they are counted 
which basically screws things up entirely.


  fit [:2001] ts_model(x) datafile using 1:2 via x1,a1,p1, x2,a2,p2,a3,p3,x3


After 1 iterations the fit converged.
final sum of squares of residuals : nan
abs. change during last iteration : nan

degrees of freedom    (FIT_NDF)                        : 169
rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : nan
variance of residuals (reduced chisquare) = WSSR/ndf   : nan

Final set of parameters            Asymptotic Standard Error
=======================            ==========================

x1              = nan              +/- nan          (nan%)
a1              = 0.01             +/- nan          (nan%)
p1              = 3                +/- nan          (nan%)
x2              = nan              +/- nan          (nan%)
a2              = 0.01             +/- nan          (nan%)
p2              = 20               +/- nan          (nan%)
a3              = 0.01             +/- nan          (nan%)
p3              = 60               +/- nan          (nan%)
x3              = 2006.12          +/- nan          (nan%)


correlation matrix of the fit parameters:

                x1     a1     p1     x2     a2     p2     a3     p3 
x3
x1                nan
a1                nan    nan
p1                nan    nan    nan
x2                nan    nan    nan    nan
a2                nan    nan    nan    nan    nan
p2                nan    nan    nan    nan    nan    nan
a3                nan    nan    nan    nan    nan    nan    nan
p3                nan    nan    nan    nan    nan    nan    nan    nan
x3                nan    nan    nan    nan    nan    nan    nan    nan 
   nan
gnuplot> fit [:2001] ts_model(x) datafile using 
1:((($1<1980)&&($1>1984))?$2:NaN) via x1,a1,p1, x2,a2,p2,a3,p3,x3




Now I can see how this would be happening but I wonder if it has any use 
at all as a result.

In practice this means that any dataset that contains even one NaN 
coordinate or one point where 'using' evaluates to NaN, cannot be used 
with the fit command.

Now since plot and fit generally try to work in a parallel fashion, I 
was expecting fit to _exclude_ from its calculations the points that I 
had made evaluate to NaN.

If this worked , it would be fundamentally useful. Is there any reason 
why the current behaviour is useful or essential.

Would it be preferable to simply skip data points with a NaN in a 
similar way to what plot does?

best regards, Peter.

Re: [PATCH] New pm3d corners2color function

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 07 October 2012, Petr Mikulik wrote:
>Ethan Merritt wrote >
> > There is an option "set pm3d interpolate <xdelta>,<ydelta>" that
> > produces smoother coloring subdividing each quadrangle into smaller
> > quadrangles with individually calculated color values.  But these
> > color values are always assign by linear interpolation.
> >
> > For color schemes c1/c2/c3/c4/mean this comes out equivalent to the
> > same overall coloring applied to a finer grid of x,y values.  The
> > finer the interpolation, the closer it comes to a true linear color
> > gradient.
> >
> > However, for color schemes using the harmonic or geometric mean,
> > the finer grid still results in a linear color gradient rather than
> > the requested geometric or harmonic color variation.  Shouldn't the
> > interpolation in these cases be some non-linear function?
> > What function would that be?
> 
> Coordinates x, y can be interpolated linearly, but the colour coords can 
> follow arithmentic, geometric or harmonic mean.

Sure, but what are the corresponding interpolation functions?
If the c1/c2/c3/c4 quadrangle is to be colored using a harmonic mean,
and interpolation 3,3 splits adds four new vertices in the interior,
what is the proper interpolated color at those new vertices?

Clement Law <the...@gm...> wrote>
> I've written up another pm3d corners2color function. It works just as
> the others, i.e.,
>   set pm3d corners2color rms
> rms4 takes the root mean square[1] of the four corners

OK.
Do you see what I'm asking about how to handle interpolation
for these non-linear coloring schemes?

	Ethan

[PATCH] Another pm3d corners2color function

[Clement L. <the...@gm...>]

Hello,

I think the previous email was swallowed by the mailing list due to
the attachment. I've written up another pm3d corners2color function.
It works just as
the others, i.e.,

set pm3d corners2color rms

rms4 takes the root mean square[1] of the four corners

The RMS has many physical interpretations [2]. Later on, I may write a
similar function for standard deviation...

My field of research is computational (statistical) physics. I make
heavy use of pm3d to represent three variable systems. As such, more
corners2color functions will come in useful.

The patch[3] I've attached here was generated as advised using diff -ur
/orig/source/tree/ /my/source/tree/

Clement Law

[1] http://en.wikipedia.org/wiki/Root_mean_square
[2] http://en.wikipedia.org/wiki/Root_mean_square#Uses
[3] http://pastebin.com/7FrVVr4p

More x11 terminal fixes

[Dima K. <gn...@di...>]

I'm starting a new thread to talk strictly about regressions in and fixes to the
patch I sent last month to get x11 aspect ratios to work right. That thread is
"[PATCH] x11 terminal respects the requested aspect ratio".

I've discovered some more issues, and addressed them in the attached patch.
These are

- with -replotonresize, two replots were happening when a window was resized:
  the initial outboard-only even-aspect-ratio one, and then the full replot. It
  was inefficient and unnecessary to do the first replot in this case, so I no
  longer do it with -replotonresize

- This replot becomes essential if the inboard driver is killed, but the plot is
  still up because of -persist. This replot is thus always done when the
  inboard-outboard pipe is broken

- When the inboard driver is killed, the mouse-over coordinates were not
  computed correctly. Fixed.

dima

Re: Variable color demo page (website)

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 13 October 2012, Tait wrote:
> > > If anyone wants to put together an equivalent interface for
> > > gnuplot demos, I'm all for it. ...
> 
> 
> Is the HTML for the demos entirely written and updated by hand? Or do
> you have some auto-generation code to create those pages? Is there a
> version-controlled repository for the HTML/generator code?

The scripts to generate the demos are in directory .../demo/html

The top-level pages (index.html) on SourceForge have been manually
tweaked a bit from the auto-generated ones, but basically doing
   make
or make -f Makefile.svg
of make -f Makefile.canvas
will recreate a local copy of the on-line demos.

	Ethan

Re: Variable color demo page (website)

[Tait <gnu...@t4...>]

> > If anyone wants to put together an equivalent interface for
> > gnuplot demos, I'm all for it. ...


Is the HTML for the demos entirely written and updated by hand? Or do
you have some auto-generation code to create those pages? Is there a
version-controlled repository for the HTML/generator code?

Re: key text placement in SVG

[Allin C. <cot...@wf...>]

On Fri, 12 Oct 2012, Ethan A Merritt wrote:

> On Friday, October 12, 2012 11:27:20 am pl...@pi... wrote:
>>> - font-size="8pt" requests an 8 point font regardless of the
>>>    display resolution or current scaling.  That's what gnuplot does.
>>>    In theory, if you view an SVG document in a viewer that allows
>>>    you to rescale the figure, the font should display as the same
>>>    size even after rescaling the plot.  That is, if you shrink the
>>>    figure the font does not shrink with it.
>>
>> Not what I am finding in practise.
>
> Right.  Me neither.  So theory and practice diverge once again.
> Nevertheless, writing the same SVG text element twice,
> once with font-size="10pt" and once with font-size="10" is
> quite informative about the substantial difference between the
> two descriptions.
>
> I think I will change the svg terminal to omit units from the
> font-size attribute, bringing it into line with what inkscape
> does.  I am left rather confused about the level of device
> dependence, but at least on typical terminal screens (90-100dpi)
> this makes gnuplot's string width estimates much more accurate.

This sounds promising.

One further thought: what about using a temporary pango layout to 
size the text, with the same font name/size specification? This 
won't necessarily work well in all cases, but I guess that in many 
cases the visual rendering of an SVG file will in the end depend on 
cairo and pango, so laying out the text via pango, in RAM, would 
give a reasonable approximation to the size as actually seen. Even 
if not always right, surely better than the current vague guess?

I haven't checked yet, but I presume this is what the pngcairo and 
pdfcairo drivers do at present, and their text placement is fine.

Allin Cottrell

Re: key text placement in SVG

[<pl...@pi...>]

On 10/12/12 17:40, sfeam (Ethan Merritt) wrote:
> pl...@pi...  wrote>
>> >The nice thing about SVG is the ability to zoom in to get more detail.
>> >Doing this on Allin's example , comparing Firefox to Opera on linux,
>> >the U of UNEMP is basically outside the plot with the second upright on
>> >the y-axis.
>> >
>> >With Opera is it perfectly coincident this the y axis, on FF it is just
>> >inside the graph with a very fine amount of white separating it from the
>> >axis.
>> >
>> >A more exacting test case could provide some useful metrics on the problem.
> But how would that help?  Aren't you illustrating that the_same file_
> produces different results when displayed by different viewing programs?

Exactly. What I found out by testing was that even on the same platform 
there are fond rendering differences. That is one thing I wanted to know.

I also established that on the face of it , it's so damn small, you need 
to blow up to x20 to see it.

What I was suggesting is that quantifying the problem like this is 
probably an essential first step to fixing it in the most effective way 
with a minimum of trial and error loops.

I think you have a much better understanding that I do of where the 
weaknesses lie but I'd expect a test case to have long key titles, be 
tested with several different types of font and include varying amounts 
of capitals, and letters like i,l,t against m,a,c,w,o

Comparison should probably be made between (wxt, qt ) and pngcairo et al 
  and svg/postscript.

This in a matrix with lin/mac/win on the other vector.

Hopefully this would find some areas that work fine and determine worst 
cases aberrations.


best regards, Peter.

Re: key text placement in SVG

[Ethan A M. <sf...@us...>]

On Friday, October 12, 2012 11:27:20 am pl...@pi... wrote:
> > - font-size="8pt" requests an 8 point font regardless of the
> >    display resolution or current scaling.  That's what gnuplot does.
> >    In theory, if you view an SVG document in a viewer that allows
> >    you to rescale the figure, the font should display as the same
> >    size even after rescaling the plot.  That is, if you shrink the
> >    figure the font does not shrink with it.
> 
> Not what I am finding in practise.

Right.  Me neither.  So theory and practice diverge once again.
Nevertheless, writing the same SVG text element twice,
once with font-size="10pt" and once with font-size="10" is
quite informative about the substantial difference between the
two descriptions.

I think I will change the svg terminal to omit units from the
font-size attribute, bringing it into line with what inkscape
does.  I am left rather confused about the level of device
dependence, but at least on typical terminal screens (90-100dpi)
this makes gnuplot's string width estimates much more accurate.

If this causes problems for someone's use case (probably when
embedding into a larger XML document) then we can consider how
to make the font-size units a driver configuration option.

	Ethan

Re: key text placement in SVG

[<pl...@pi...>]

On 10/12/12 19:34, Ethan A Merritt wrote:
> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>> I'm comparing the output of gnuplot's svg and pngcairo
>> drivers, with a thought of making greater use of SVG. But
>> there seems to be a slight problem with the placement of key
>> text in the SVG output. Here's a little test script
>>
>> set term svg font "Sans,8" size 680,400
>> set output 'test.svg'
>> set key left top
>> plot sin(x) title "PRIME" w l, cos(x) title "UNEMP" w l
>>
>> In the PNG version the key is just fine, but in SVG the "U" of
>> "UNEMP" gets tangled up with the y-axis (more or less,
>> depending on the magnification). I'm looking at the SVG using
>> librsvg, and also via the Adobe NPSVG3 library. To show what
>> I'm talking about,
>
>> I'm attaching the SVG output as converted to PNG by rsvg-convert
>> (at 96dpi).
>    ^^^^^^^^^^
>
> That dpi setting turns out to be relevant.
> I went back to the SVG spec and learned the following:
>
> - you can specify font-size in either absolute or relative units
>
> - font-size="8pt" requests an 8 point font regardless of the
>    display resolution or current scaling.  That's what gnuplot does.
>    In theory, if you view an SVG document in a viewer that allows
>    you to rescale the figure, the font should display as the same
>    size even after rescaling the plot.  That is, if you shrink the
>    figure the font does _not_ shrink with it.

Not what I am finding in practise. I have a gnuplot graph in svg which 
contains text formatted as follows:

<g transform="translate(41.3,43.7)" style="stroke:none; fill:black; 
font-family:verdana; font-size:9.00pt; text-anchor:end">

Both Opera and FF zoom both the text and graph lines with the zoom 
feature (if that is what you were referring to by rescale).

Frankly , that is what I would expect.  Like if I zoom an html document, 
the main reason would be to increase the rendition of the font size.

Maybe I misunderstood "rescale".

/Peter.



>
> - font-size="8" or font-size="8px" requests a font size relative to
>    the current display units.  It will scale up or down as the figure
>    is re-sized.
>
> - For a 95dpi display, 8pt is translated to 10px.  That is, it is
>    displayed 25% larger than gnuplot was expecting.  This is probably
>    at the heart of the problem.
>
> - You can confirm this by opening the output of your test command in
>    inkscape and then saving it to a new *.svg file.  The original gnuplot
>    output contains text marked "font-size:8pt" but inkscape converts this
>    to "font-size:10"  (no units).
>
> I don't know what is the best thing to do here.
> Being able to specify an absolute font size makes sense in many
> cases, but not in all cases.  Perhaps we need a gnuplot terminal option
> that controls whether gnuplot writes out absolute or relative units for
> the font size.  I suppose the code that estimates text length would have
> to be aware of this also.
>
> 	Ethan
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: key text placement in SVG

[Ethan A M. <sf...@us...>]

On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
> I'm comparing the output of gnuplot's svg and pngcairo 
> drivers, with a thought of making greater use of SVG. But 
> there seems to be a slight problem with the placement of key 
> text in the SVG output. Here's a little test script
> 
> set term svg font "Sans,8" size 680,400
> set output 'test.svg'
> set key left top
> plot sin(x) title "PRIME" w l, cos(x) title "UNEMP" w l
> 
> In the PNG version the key is just fine, but in SVG the "U" of 
> "UNEMP" gets tangled up with the y-axis (more or less, 
> depending on the magnification). I'm looking at the SVG using 
> librsvg, and also via the Adobe NPSVG3 library. To show what 
> I'm talking about, 

> I'm attaching the SVG output as converted to PNG by rsvg-convert 
> (at 96dpi).
  ^^^^^^^^^^

That dpi setting turns out to be relevant.
I went back to the SVG spec and learned the following:

- you can specify font-size in either absolute or relative units

- font-size="8pt" requests an 8 point font regardless of the
  display resolution or current scaling.  That's what gnuplot does.
  In theory, if you view an SVG document in a viewer that allows
  you to rescale the figure, the font should display as the same
  size even after rescaling the plot.  That is, if you shrink the
  figure the font does _not_ shrink with it.

- font-size="8" or font-size="8px" requests a font size relative to
  the current display units.  It will scale up or down as the figure
  is re-sized.

- For a 95dpi display, 8pt is translated to 10px.  That is, it is
  displayed 25% larger than gnuplot was expecting.  This is probably
  at the heart of the problem.    

- You can confirm this by opening the output of your test command in 
  inkscape and then saving it to a new *.svg file.  The original gnuplot 
  output contains text marked "font-size:8pt" but inkscape converts this 
  to "font-size:10"  (no units).

I don't know what is the best thing to do here.
Being able to specify an absolute font size makes sense in many
cases, but not in all cases.  Perhaps we need a gnuplot terminal option
that controls whether gnuplot writes out absolute or relative units for
the font size.  I suppose the code that estimates text length would have
to be aware of this also.

	Ethan

Re: key text placement in SVG

[<pl...@pi...>]

On 10/12/12 10:03, Daniel J Sebald wrote:
> On 10/12/2012 01:08 AM, pl...@pi... wrote:
>> On 10/12/12 01:43, Allin Cottrell wrote:
>>> On Thu, 11 Oct 2012, Ethan A Merritt wrote:
>>>
>>>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>>>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>>>>> I'm comparing the output of gnuplot's svg and pngcairo
>>>>>> drivers, with a thought of making greater use of SVG. But
>>>>>> there seems to be a slight problem with the placement of key
>>>>>> text in the SVG output. Here's a little test script
>>>>>>
>>>>>> set term svg font "Sans,8" size 680,400
>>>>>> set output 'test.svg'
>>>>>> set key left top
>>>>>> plot sin(x) title "PRIME" w l, \
>>>>>>     cos(x) title "UNEMP" w l
>>>>>> set term pngcairo font "Sans,8" size 680,400
>>>>>> set output 'test.png'
>>>>>> replot
>>>>>>
>>>>>> In the PNG version the key is just fine, but in SVG the "U" of
>>>>>> "UNEMP" gets tangled up with the y-axis (more or less,
>>>>>> depending on the magnification).
>>>>>
>>>>> The underlying issue is that for SVG, like PostScript, gnuplot has
>>>>> to guess at the font properties for a font that will not actually
>>>>> be selected until the file is later viewed in another program.
>>>>
>>>> By the way, if you turn on the "box" attribute of the key you can
>>>> see that the key box itself is properly placed.  The problem is that in
>>>> your case the width of the box is too small because the size of the
>>>> text
>>>> was underestimated.
>>>>
>>>> As a work-around, you could use "set key left Left".
>>>> That anchors the left end of the text rather than the right end,
>>>> so it is not at risk of overwriting the left plot border.
>>>> Instead the right end of the text might run into the line sample ;-)
>>>
>>> Ah, that's a nice suggestion. I can manipulate the key placement so
>>> as to try to avoid colliding with the plot lines, just so long as
>>> I'm reasonably confident it won't collide with the axes.
>>>
>>> But on the more general point, does this mean I might have better
>>> luck if a specified the font more precisely than just "Sans"?
>>>
>>> Allin Cottrell
>>>
>>
>> Yes, I have taken to specifying the font size and name explicitly and
>> using spaces to avoid this kind of over-run as Daniel suggested.
>>
>> It really would be good if some improvement could be made in this area.
>> With longer key titles, the errors can be substantial.
>>
>> It is a bit of a guessing game but it seems that the guesses are
>> always(?) rather poor.
>
> It's awful.  Working with fonts has historically been a headache.  Save
> tweaking font position for the last touch up on graphs.
>
>
>> Counting capitals would be a good first step. Since this is a once per
>> plot overhead, some detailed accounting would not have any noticeable
>> performance hit.
>
> Counting capitals goes along the lines one doesn't want to go.  The
> proper way of doing this is either to have scalable fonts, or for the
> library to have a convenient function by which the programmer can
> provide the font type/size and an ASCII string of the text to be placed
> and the routine returns the size when rendered.  Font substitution is a
> get-what-you-get sort of thing.
>
>
>> Clearly text content can not be counted on to average out on such short
>> samples, 'emmission spectrum" with not have the same average letter
>> width as " illiterate infallibility"
>>
>> Perhaps some quantitative study of real examples of which fonts render
>> poorly on which renderers would permit better guesses to be build into
>> gnuplot.
>>
>> Clearly there are thousands of fonts but maybe certain families are
>> consistently wider / narrower so more knowledge would help improve
>> built-in guesses and also help users avoid fonts that can't be estimated
>> reliably.
>>
>> There may well be some platform dependency in all this as well. That
>> would be harder to fix but probably needs assessing.  Are fonts
>> consistently rendering different widths on linux / Mac / Win. ?
>
> That should be factored into the routine that indicates rendered widths,
> if one existed.
>
> Dan
>

What you are suggesting would mean a active, self-modifying document. 
That is probably possible with SVG though I doubt whether it could be 
applied to PS.

I would imagine that kind of solution opening up a lot of possibilities 
for bugs , though in some ways seeing what you get given at render time 
is the only definitive way to get the text size spot on.

As I recall previous comments for Ethan on this problem have stated that 
absence of any call back mechanism in certain terminals is why gnuplot 
does not use this strategy in any terminal.

Maybe those than can, should when that can be determined at plotting time.

Even aside from the render time problems I find significant differences 
between live output in wxt and rendering to png , for example.

Sometimes I end up doing a screenshot of the wxt rendition and saving it 
as png :(

I think some worthwhile improvements could be made without going to the 
lengths involved in documents self-modifying  at display time.

regards, Peter.