gnuplot-beta

accumulated patches

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

There are a number of patches on SourceForge ready for consideration in CVS.  If
someone wants to review them they can.  Or, if you want me to move them in, give
me a password (or temporary password if S.F. has such a thing).


[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
[ gnuplot-Bugs-1525665 ] help has problems with

Fixes issues such as a help line longer than the space reserved in memory for a 
command line.


[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()

I think it is correct, others may not.  It appears to work on Linux and Mac and 
I'm fairly confident it won't cause any problems.


[ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute

This is an outright bug fix.  Should have gone in 4.2.


[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions

Full implementation of mouse/clipboard behavior consistent with the vast
majority of X applications.


[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border

Do something like

if (i_tic == i_end) {
   if (last_tic < end_range)
     draw_tic;
}

instead of

while (first_tic + delta_tic + delta_tic + ... + delta_tic < end_range)
   draw_tic;

The second approach is susceptible to rounding, the first isn't.


[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
window

Works as far as I know.  X11 has an issue whereby two resources both
controlling the mouse in a window will cause an error.  Will X ever change this? 
  I doubt it.  The most I could offer is to somehow check if the outside 
application has relenquished the mouse and if not issue an error.


[ gnuplot-Patches-1531560 ] recursive history warning instead of error

Issue a warning rather than an error so that the rest of the line may be 
executed, e.g.,

gnuplot> history !his; show style;
^
warning: ignoring recursive history command
Data are plotted with points...


[ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]

Allows multiple palettes on a multiplot X11 window, a long desired fix.


[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation

Fixes a bug reported on SourceForge.  Very big patch.  No noticable change in 
speed.  If someone wants to fix the bug another way, feel free.


[ 1727198 ] Hidden lines: Degenerate polygons creating problems

Fixes a bug reported on SourceForge.  User reported hidden lines appearing on a 
globe.  The lines were part of the north pole in which four sided polygons were 
degenerate as triangles.  Hence internally triangles with two sides the same 
were the problem spot.  The patch simply tosses out such polygons.


[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure

Replace an assertion statement in the QUADTREE version with a simple range 
limit.  Hidden line removal slows down if user pushes surface out past the plot 
view, but that is a minor consequence.  (Better than your program quitting on you.)


[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"

This one isn't ready to go, but we should address this at some point.  An 
interesting side note is that Octave considered storing its stem plot data as a 
series of data for which a "missing" value is used to create a discontinuous 
space.  That is, there is three ways of doing this:

1) Use gnuplot's "stem".
2) Draw a bunch of individual lines with "plot" for each line.
3) Draw a series of data with every third entry "missing" thus leaving the third 
line blank.

Turns out that 3 sort of fits the way Octave stores data.


Dan

Re: accumulated patches

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

On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
> [ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
> [ gnuplot-Bugs-1525665 ] help has problems with
> [ gnuplot-Patches-1531560 ] recursive history warning instead of error

I agree these are relatively high priority.
They almost went into 4.2, but were held out because bugs
turned up at the last minute.  IOW they are not quite working yet.
I would very much like to see them cleaned up, thoroughly tested,
and added to CVS.

Please combine them into a single patch set against current source
and let's give them a workout to shake out any remaining bugs.

> [ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
> 
> I think it is correct, others may not.  It appears to work on Linux and Mac and 
> I'm fairly confident it won't cause any problems.

It was never broken on linux, and I believe it is no longer needed
on OSX either.  So the risk of breaking some minor platform seems larger
than the benefit to any known system.  Please correct me if I'm wrong.

> [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute 
> This is an outright bug fix.  Should have gone in 4.2.

Do you want to take this one Petr?
You had said earlier you would move it into CVS.
 
> [ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
> 
> Full implementation of mouse/clipboard behavior consistent with the vast
> majority of X applications.

???  Not as seen here.  I have had no problems with the current implementation.
That doesn't make your fix wrong, but I don't understand what problem is fixing.
 
> [ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border

I think this is a non-issue, and we should drop this one entirely.

> [ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
> window
> 
> Works as far as I know.

Doesn't work here.  I'd like it if it *did* work, but it doesn't.
My recollection is that it tripped over some contradictory requirements
for window management by Tk/Tcl, GTK, etc.

> [ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]
> Allows multiple palettes on a multiplot X11 window, a long desired fix.

Sorry, I haven't had time to look at this one yet.

> [ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
> [ 1727198 ] Hidden lines: Degenerate polygons creating problems
> [ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure

I'll leave these to Hans-Bernhard, since he's far more familiar
with the code.  I will comment that gnuplat's hidden-line removal
plots have very different properties than solid rendering.  When you
render solids, omitting a facet is just about the worst thing you can do.
The missing facet is far more jarring than a mis-aligned edge.
But in the case of gnuplot, it is exactly the mis-aligned edges that
are noticeable.  We don't care if a facet is dropped.  So although
I have not delved into the code, I suspect that the most useful fix
is simply to increase the slop margin, and deliberately omit any
edges that are in the slop area.  

> [ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"

Veto.
There are more reasonable options.
1) Clean up your data files
2) Run it through general string handling:
    filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
    plot "foo" using 1:(filter($2))
3) Clean up your data files

Consider the case where you have multiple data files,
each with its own idea of what is or is not a missing data flag.
You want the fix to be per-file, not global.

-- 
Ethan A Merritt 

Re: accumulated patches

[Petr M. <mi...@ph...>]

> > [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute 
> > This is an outright bug fix.  Should have gone in 4.2.
> 
> Do you want to take this one Petr?
> You had said earlier you would move it into CVS.

Yes, the patch works fine.

---
PM

Re: accumulated patches

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

Ethan Merritt wrote:
> On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> 
>>[ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
>>[ gnuplot-Bugs-1525665 ] help has problems with
>>[ gnuplot-Patches-1531560 ] recursive history warning instead of error
> 
> 
> I agree these are relatively high priority.
> They almost went into 4.2, but were held out because bugs
> turned up at the last minute.  IOW they are not quite working yet.
> I would very much like to see them cleaned up, thoroughly tested,
> and added to CVS.
> 
> Please combine them into a single patch set against current source
> and let's give them a workout to shake out any remaining bugs.

Will do.


>>[ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA()
>>
>>I think it is correct, others may not.  It appears to work on Linux and Mac and 
>>I'm fairly confident it won't cause any problems.
> 
> 
> It was never broken on linux, and I believe it is no longer needed
> on OSX either.  So the risk of breaking some minor platform seems larger
> than the benefit to any known system.  Please correct me if I'm wrong.

I'm not familiar with OSX other than that user said it works correctly when it 
was needed at the time.  Have to ask the OSX user who had a problem on this one.


>>[ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions
>>
>>Full implementation of mouse/clipboard behavior consistent with the vast
>>majority of X applications.
> 
> 
> ???  Not as seen here.  I have had no problems with the current implementation.
> That doesn't make your fix wrong, but I don't understand what problem is fixing.

It's added features for the most part.  But still I think the existing 
implementation doesn't really place a plot in the X clipboard, and furthermore 
it doesn't properly handle Atom translation.  The existing "clipboard" was a 
hastily constructed version that was made to work for one app and assumed to be 
a full and proper implementation.  The documentation currently states that the 
plot automatically goes into the clipboard.  But try doing a cntrl-V inside 
something like oowriter or your favorite word processor.  Nothing happens. 
There are actually two different entities, clipboard and "selection".  Those 
both have to be handled in the proper X implementation.  There needs to be 
communication about what file formats gnuplot_x11 can provide to the application 
and then gnuplot_x11 has to respond with the proper file format when requested.

The only think is that I didn't know it was possible to interpret cntrl-? keys, 
so 'c' is what puts a plot into the clipboard.  I'll see if I can fix that up to 
the cntrl-c (copy)/cntrl-v (paste) convention.


>>[ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
> 
> 
> I think this is a non-issue, and we should drop this one entirely.

It's still there.  This originated from Octave computing its axis limits with a 
bit of round off.  Try

set xrange [0:1.99805]
set grid
plot sin(x)
set xrange [0:2]
replot
set xrange [0:1.99805]
replot

and look to the right edge of the plot.  Basically, it addresses this FIXME in 
the code:

/* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
* begging for rounding errors to strike us. */
/* HBB 20010410: ... and strike they did :-( */


>>[ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
>>window
>>
>>Works as far as I know.
> 
> 
> Doesn't work here.  I'd like it if it *did* work, but it doesn't.
> My recollection is that it tripped over some contradictory requirements
> for window management by Tk/Tcl, GTK, etc.

I'll have another look and see if there are any problems.


>>[ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
>>[ 1727198 ] Hidden lines: Degenerate polygons creating problems
>>[ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure
> 
> 
> I'll leave these to Hans-Bernhard, since he's far more familiar
> with the code.  I will comment that gnuplat's hidden-line removal
> plots have very different properties than solid rendering.  When you
> render solids, omitting a facet is just about the worst thing you can do.
> The missing facet is far more jarring than a mis-aligned edge.
> But in the case of gnuplot, it is exactly the mis-aligned edges that
> are noticeable.  We don't care if a facet is dropped.  So although
> I have not delved into the code, I suspect that the most useful fix
> is simply to increase the slop margin, and deliberately omit any
> edges that are in the slop area.

Increasing the slop margin will probably make things worse.  There are two 
issues here that should be kept separate.  The alternate hidden3d issue (i.e., 
the bits and pieces) and the degenerate polygons.

The alternate hidden3d patch doesn't alter the EPSILON setting, and in fact, I 
avoid those EPSILON tests when they have no effect.  (I've noted in the code 
where they don't make a difference.)  Even the existing bug in the CVS code I 
doubt has anything to do with slop margin.  There appears to be a pattern 
whereby what bits and pieces (i.e., edge segments) that are left intersect 
precisely with one of the polygon vertices, but I'm not sure but I've offered a 
patch that works so I'm not inclined to figure it out.

The detailed explanation of the degenerate polygons is that sometimes the 4 
sided polygons turn out to be a triangle (or even share more similar vetices). 
In that case, some of the triangles making up that quadrangle are "degenerate", 
meaning that if v1, v2 and v3 are the triangles vertices, v1=v2 or v2=v3 or 
v3=v1.  But that is an infinitely thin slice and hence has no consequence if it 
is simply discarded.  However, if such a degenerate case is left, the existing 
code will try an create a plane equation describing the plane for such a 
degenerate triangle, but there is no unique, meaningful plane equation for two 
points.  Hence the orientation (probably random) incorrectly chooses the 
direction the plane faces and picks the wrong color for the line.  (The patches 
have some PNG examples attached.)


>>[ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"
> 
> 
> Veto.
> There are more reasonable options.
> 1) Clean up your data files
> 2) Run it through general string handling:
>     filter(x) =   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
>     plot "foo" using 1:(filter($2))
> 3) Clean up your data files
> 
> Consider the case where you have multiple data files,
> each with its own idea of what is or is not a missing data flag.
> You want the fix to be per-file, not global.

I'm fine with only one missing symbol.  However, there is still the issue of 
defining exactly how these behave in the code.  I included some demo plots in 
the patch to illustrate behavior for the two classes of points.  I think 
originally behavior was sort of left to the wind.

Dan