Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2007-06-10 05:22:13
|
Due to an probable change of venue in the coming weeks, I will likely not have time for gnuplot code as I occassionally have had in the past. If there are any code bugs or features, or any sourceforge patches that people want me to look at, now is time. Dan |
|
From: Petr M. <mi...@ph...> - 2007-06-13 09:27:32
|
> Due to an probable change of venue in the coming weeks, I will likely not have > time for gnuplot code as I occassionally have had in the past. If there are any > code bugs or features, or any sourceforge patches that people want me to look > at, now is time. My comments: - history patch fine, I propose to move it to cvs - [1488168] z_floor and z_ceiling based on xyplane.absolute fine, I propose to move it to cvs - [ 1731160 ] min/max printout error for show Xrange fine, I propose to move it to cvs - [1004754] Tics and grid slightly outside border. is this still needed? - hidden patches current status? --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-13 16:04:30
|
On Wednesday 13 June 2007 02:27, Petr Mikulik wrote: > > Due to an probable change of venue in the coming weeks, I will likely not have > > time for gnuplot code as I occassionally have had in the past. If there are any > > code bugs or features, or any sourceforge patches that people want me to look > > at, now is time. > > My comments: > > - history patch > fine, I propose to move it to cvs OK. I hope you guys have tested it thoroughly. > - [1488168] z_floor and z_ceiling based on xyplane.absolute > fine, I propose to move it to cvs OK. > - [ 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"? > - [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. > - 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. -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-06-13 17:35:43
|
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
|
|
From: Petr M. <mi...@ph...> - 2007-06-14 08:10:04
|
> >>- [ 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. > > set yrange [ * : * ] noreverse writeback # (currently [-10.0000:10.0000] ) > should change to reflect something. > > 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., I was always puzzled by "currently [-10:10]" when the range was completely different. Indeed, "default" is the correct word. However, this information is completely useless. I usually want to show the real xrange, not the unused default. Nowadays, I can do print GPVAL_Y_MIN, GPVAL_Y_MAX but that's rather cumbersome and not easy to find for others. I proposed to apply Daniel's patch. Then, via "show yrange", I can easily copy the real current range to my script, and edit the range manually. > >>- hidden patches > > > 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. >From a user point of view, the patch brings hiding of lines and polygons, which look much better (and correctly) than what we have now. So, it's an improvement, therefore I propose to apply the patch. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-14 18:26:51
|
On Thursday 14 June 2007 01:10, Petr Mikulik wrote: > > I was always puzzled by "currently [-10:10]" when the range was completely > different. Indeed, "default" is the correct word. However, this information > is completely useless. I usually want to show the real xrange, not the > unused default. Nowadays, I can do > print GPVAL_Y_MIN, GPVAL_Y_MAX > but that's rather cumbersome and not easy to find for others. > > I proposed to apply Daniel's patch. Then, via "show yrange", I can easily > copy the real current range to my script, and edit the range manually. OK. I warn you that the existing code for zoom/unzoom actually looks at these values, so it is possible this may change the zoom behaviour. But the "refresh" patch I've been working on replaces that code anyhow, so now might not be such a bad time to take the risk. -- Ethan A Merritt |
|
From: <pl...@pi...> - 2007-06-14 18:48:44
|
On Thu, 14 Jun 2007 20:26:46 +0200, Ethan Merritt <merritt@u.washington.edu> wrote: > On Thursday 14 June 2007 01:10, Petr Mikulik wrote: >> >> I was always puzzled by "currently [-10:10]" when the range was >> completely >> different. Indeed, "default" is the correct word. However, this >> information >> is completely useless. I usually want to show the real xrange, not the >> unused default. Nowadays, I can do >> print GPVAL_Y_MIN, GPVAL_Y_MAX >> but that's rather cumbersome and not easy to find for others. >> >> I proposed to apply Daniel's patch. Then, via "show yrange", I can >> easily >> copy the real current range to my script, and edit the range manually. > > OK. I warn you that the existing code for zoom/unzoom actually looks at > these values, so it is possible this may change the zoom behaviour. > But the "refresh" patch I've been working on replaces that code anyhow, > so now might not be such a bad time to take the risk. > since you are looking at zoom, I have noticed that current code does not unzoom as I expected having read the doc. 'u' just jumps back to initial unzoomed plot. I seem to recall the doc saying it goes to "previous" zoom state. Thus if I do two successive zooms I'd expected to back out in two steps with 'u'. Maybe I just misunderstood, if so, this may be a good idea. I often want to do just this and end up having to repeat the first zoom. Thx |
|
From: Petr M. <mi...@ph...> - 2007-06-14 20:40:03
|
> since you are looking at zoom, I have noticed that current code does not > unzoom as I expected having read the doc. > > 'u' just jumps back to initial unzoomed plot. I seem to recall the doc saying > it goes to "previous" zoom state. u is really unzoom; hit 'h' in the graphics window for this help: n `builtin-zoom-next` go to next zoom in the zoom stack p `builtin-zoom-previous` go to previous zoom in the zoom stack u `builtin-unzoom` --- PM |
|
From: Daniel J S. <dan...@ie...> - 2007-06-18 18:41:04
Attachments:
hidden3d_18jun2007.patch
|
Daniel J Sebald wrote: > 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.) Here's a patch to get one started on fixing bug [ 1718109 ]. And there is always the alternate method if no one gets around to looking at this. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-06-13 09:41:10
|
Petr Mikulik wrote: > - [1004754] Tics and grid slightly outside border. > is this still needed? The following still places a grid line outside the border (try it a couple times if the first time the problem doesn't appear): set xrange [0:1.99805] set grid plot sin(x) (Another application computes the range, hence the strange choice.) Dan |
|
From: Petr M. <mi...@ph...> - 2007-06-13 09:56:49
|
> > - [1004754] Tics and grid slightly outside border. > > is this still needed? > > The following still places a grid line outside the border (try it a couple times > if the first time the problem doesn't appear): > > set xrange [0:1.99805] > set grid > plot sin(x) > > (Another application computes the range, hence the strange choice.) Yes, this looks strange. It seems that the grid line should be canceled if its center in screen coordinates is larger than the center of the border line. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-13 18:51:17
|
On Wednesday 13 June 2007 10:35, Daniel J Sebald wrote: > 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 + ...? Because it is bad to have vanishingly small changes in the specified range cause large changes in the plot layout? -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-06-13 19:04:56
|
Ethan Merritt wrote: > On Wednesday 13 June 2007 10:35, Daniel J Sebald wrote: > >>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 + ...? > > > Because it is bad to have vanishingly small changes in the specified range > cause large changes in the plot layout? Is the argument that a range [0:1.99805] should result in a plot having the same appearance as with range [0:2] (which they currently aren't)? I.e., we're off by 0.0019500 for a range of 1.99805, or 0.0975 percent so no big difference? Hans-Bernhard suggested not doing such a thing. The fix would be to simply not draw the tic and verticle dotted line outside the border for range [0:1.99805]. That would still look like the [0:2] case. Dan |
|
From: Petr M. <mi...@ph...> - 2007-06-14 08:02:34
|
> >>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 + ...? > > > > > > Because it is bad to have vanishingly small changes in the specified range > > cause large changes in the plot layout? > > Is the argument that a range [0:1.99805] should result in a plot having the same > appearance as with range [0:2] (which they currently aren't)? I.e., we're off > by 0.0019500 for a range of 1.99805, or 0.0975 percent so no big difference? > Hans-Bernhard suggested not doing such a thing. The fix would be to simply not > draw the tic and verticle dotted line outside the border for range [0:1.99805]. We may not do this in real graph coordinates, but in terminal coordinates. If center of the left/right grid line is smaller/larger than center of the border line, then don't draw that grid line. --- PM |
|
From: Petr M. <mi...@ph...> - 2007-06-14 20:36:21
|
> > I was always puzzled by "currently [-10:10]" when the range was completely
> > different. Indeed, "default" is the correct word. However, this information
> > is completely useless. I usually want to show the real xrange, not the
> > unused default. Nowadays, I can do
> > print GPVAL_Y_MIN, GPVAL_Y_MAX
> > but that's rather cumbersome and not easy to find for others.
> >
> > I proposed to apply Daniel's patch. Then, via "show yrange", I can easily
> > copy the real current range to my script, and edit the range manually.
>
> OK. I warn you that the existing code for zoom/unzoom actually looks at
> these values, so it is possible this may change the zoom behaviour.
> But the "refresh" patch I've been working on replaces that code anyhow,
> so now might not be such a bad time to take the risk.
No, it does not. The output from Daniel's patch only effects what is printed
on the screen as a comment. Compare:
current-gnuplot> set xrange [-2:2]; p x*x-1; show yrange
set yrange [ * : * ] noreverse nowriteback # (currently
[-10.0000:10.0000] )
patched-gnuplot> set xrange [-2:2]; p x*x-1; show yrange
set yrange [ * : * ] noreverse nowriteback # (currently
[-1.00000:3.50000] )
The latter is much more logic, but it's just a comment for the user.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-14 21:13:06
|
On Thursday 14 June 2007 13:36, Petr Mikulik wrote: > > > I was always puzzled by "currently [-10:10]" when the range was completely > > > different. Indeed, "default" is the correct word. However, this information > > > is completely useless. I usually want to show the real xrange, not the > > > unused default. Nowadays, I can do > > > print GPVAL_Y_MIN, GPVAL_Y_MAX > > > but that's rather cumbersome and not easy to find for others. > > > > > > I proposed to apply Daniel's patch. Then, via "show yrange", I can easily > > > copy the real current range to my script, and edit the range manually. > > > > OK. I warn you that the existing code for zoom/unzoom actually looks at > > these values, so it is possible this may change the zoom behaviour. > > But the "refresh" patch I've been working on replaces that code anyhow, > > so now might not be such a bad time to take the risk. > > No, it does not. The output from Daniel's patch only effects what is printed > on the screen as a comment. Ah, OK then. I thought he was proposing to update the values themselves in the axis structure. Sure, printing the current value is much more useful than always printing [10:10]. Ethan > Compare: > > > current-gnuplot> set xrange [-2:2]; p x*x-1; show yrange > > set yrange [ * : * ] noreverse nowriteback # (currently > [-10.0000:10.0000] ) > > > patched-gnuplot> set xrange [-2:2]; p x*x-1; show yrange > > set yrange [ * : * ] noreverse nowriteback # (currently > [-1.00000:3.50000] ) > > > The latter is much more logic, but it's just a comment for the user. > > --- > PM > -- Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
