Re: Winding down patches...

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

Ethan Merritt wrote:

>>- [ 1731160 ] min/max printout error for show Xrange
>>  fine, I propose to move it to cvs
> 
> 
> No.  I don't think the issue is well understood.
> There may be an error, but I am not so sure.
> Isn't this what the "writeback" option is supposed to handle?
> Do we have a test case for "writeback"?

I misunderstood this one when writing this patch.  I took it to mean 
GPVAL_Y_MIN, GPVAL_Y_MAX, etc.  So, there is no error from the perspective I was 
saying.

However, it does seem that the -10:10 of

set yrange [ * : * ] noreverse writeback  # (currently [-10.0000:10.0000] )

should change to reflect something.  But even the "help writeback" example 
sequence sort of makes sense:

gnuplot> set xrange [-10:10]
gnuplot> set yrange [] writeback
gnuplot> plot sin(x)
gnuplot> show yrange

         set yrange [ * : * ] noreverse writeback  # (currently [-10.0000:10.0000] )

gnuplot> set yrange restore
gnuplot> show yrange

         set yrange [ -1.00000 : 1.00000 ] noreverse writeback

gnuplot> replot x/2

I thought maybe the [-1:1] would show in the "currently [ : ]", but there is no 
reason for gnuplot to display anything different than it currently does.

I'm inclined to close this patch.  However, maybe if there is one thing to 
change it would be the word "currently" to "default", i.e.,

   set yrange [ * : * ] noreverse writeback  # (default [-10.0000:10.0000] )

(and fix the spacing in the parentheses).  The problem I have with the word 
"currently" is that if one does an autorange plot and then show yrange, the 
yrange obviously isn't [-10:10].


>>- [1004754] Tics and grid slightly outside border.
>>  is this still needed?
> 
> 
> No. Please drop this one.  There are always going to be
> corner cases where if you ask for something odd you will
> get an unexpected result.  In this case the requested
> axis range is not reasonable, and the fix belongs in the
> program that generated the unreasonable axis range.

I still think this one is fine.  It boils down to the message left by 
Hans-Bernhard in the code, about computing tics by adding delta_tic each time.

This problem is the result of a bit of sloppiness in programming and trying to 
accomplish the whole tic layout in a simple hunk of code when it can't be done. 
  Basically, the fact is we *know* the beginning and end of the ranges as 
entered.  Why toss that information away by doing x_tic = x_min + x_delta + 
x_delta + x_delta + ...?

> 
> 
>>- hidden patches
> 
> 
> My impression is that this is another case like the one
> above. There are corner cases that cause minor glitches.
> This is annoying, yes.  But the proposed wholesale
> re-working of the hidden3d code is almost certain to have
> an equal number of glitches and corner cases.  You just
> haven't found them yet.  I am inclined to say we should
> drop this whole issue.

I think these are rock solid.

The patch on degenerate polygons is a clear cut case.  There is simply no way of 
choosing a plane direction from 2 points.  Such a thin "triangle" shouldn't have 
any visual effect anyway.  Just discard those and all is fine.

The glitches (spics and specs) is not a case of tolerance (slop factor).  Take a 
look at first/second order 3D surfaces in 'image2.dem'.  In that case there are 
some very big lines that aren't hidden when they should be.  Try this patch out. 
  Step through 'all.dem' before and after and look for the hidden lines demos. 
The difference is clear.  No kludges here either, just a straight forward 
implementation of something similar to this algorithm:

http://local.wasp.uwa.edu.au/~pbourke/geometry/

The existing version isn't much different really.  But there is definitely a bug 
here and it shouldn't be dismissed as something else.  If one would prefer to go 
through the existing code and find the case that is failing, that's fine.  But 
someone has to do that work, which I simply didn't find easy to follow...  I can 
give a hint for anyone who wants to look for the abberant case statement: the 
existing version seems to leave the bits behind when the hidden line intersects 
with one of the vertices of the triangle that is supposed to be hiding it.  If I 
find some time, I will search for this.  (But if the original author who has 
familiarity with the CVS algorithm wants to find it, I'm fine with that too.)

As for the assertion failure.  That one doesn't really concern me, it's just 
that it is easy enough to limit the search range rather than issue an assertion 
failure and exit from the program.

...  Dynamically setting the quadtree range is the thing to look at doing.  A 
noticable speed up can come from that.  But that's not a pressing issue.

Dan