Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-13 11:03:33
|
On Wed, 12 May 2004, Daniel J Sebald wrote: > Here is something odd in the latest CVS version. In the "using.dem" > script, for the first plot, with the mouse active, zoom in on say a top > middle third of the data. There will be some lines extending below the > bottom border. The length of the lines seems to vary upon what area was > zoomed. (That is, do this again and the line lengths may be shorter or > longer by random.) 'impulses' plots assume the plot has a baseline they can use. Zooming may break that assumption. There have been problems like this with impulses in the past. So yes, this is a bug, but not an entirely unexpected one. > > With the first plot still zoomed, go to the command line, hit return and > go to the second plot. The second plot will be zoomed also. (Should it > stay zoomed?) In the window, unzoom the second plot by typing 'u'. The > ranges don't seem to be very nice. The image is small. The second plot > script issues a > > set xrange [1:8] > > Is there a problem with setting the range when in zoomed mode? No. There's a more general problem in the way zooming, and especially the 'u'nzoom hotkey works. The general problem is that mouse interactions change the global state of gnuplot settings. You can see that happening by typing the '6' hotkey: each zooming operation modifies the global range settings. In scripts like our demos, where all settings not explicitly changed between plots are assumed to keep the values from the previous plot command, that will break massively. Until we implement separate global data sets for each plot, so the mousing code can work on a copy instead of the single instance of all the settings we have, I don't think there's much that can be done about that. Workaround: don't zoom in demos; or if you do, remember to unzoom _before_ you proceed to the next plot. Using 'unzoom' on a different graph than the one you zoomed on is IMHO begging for trouble. [... other problem...] > strings would be shifted, the key would be in the wrong place. The next > two or three plots showed the same thing, getting progressively worse. > The problem then corrected itself and things worked fine again. I > haven't been able to reproduce this. Well, next time you come across this, 'save' the state of the broken plot then, before it disappears. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-14 11:56:01
|
On Thu, 13 May 2004, Daniel J Sebald wrote: > I see what is happening now. Impulses should behave so that negative > numbers have a line appearing below y=0. However, it appears that the > current behavior does the same thing for *any* border that appears at > the bottom of the plot. More to the point, it'll try to draw them towards the border y=0 would lie beyond, if y=0 isn't inside the yrange of the plot. But something went wrong in that area, so the actual baseline may not always be the border itself, but will end up slightly outside the actual y range. You can reproduce the problem without involving the mouse: set yrange [35.5:*] load 'using.dem' # break after the first plot. You'll find the impulses end at 35 instead of 35.5, which is below the bottom border. Looks like they were auto-extended to the nearest tick position, like autoscaled ranges. This has to be investigated at source level. > For some reason, gnuplot thinks it can plot outside the bottom border. Not quite. It doesn't really "think" about drawing outside borders at all. In technical terms: it doesn't clip all graphical primitives to the graph window. > >Workaround: don't zoom in demos; or if you do, remember to unzoom _before_ > >you proceed to the next plot. Using 'unzoom' on a different graph than the > >one you zoomed on is IMHO begging for trouble. > > > > So, when unzoomed in the second plot, the ranges go back to [*:*] or > something like that. No. They go back to what they were before you started to zoom. Do it in '6' mode and you'll see it happening. > But why should the explicit > > set xrange [1:8] > > be discarded? It's not discarded --- it's overruled by "set xrange [-1:24]" from the first plot which got pulled off the zoom stack by your typing 'u'. > Anyway, I don't see how the "each plot has its own > settings" would change matters. It wouldn't, all on its own. But it's a nacessary piece of infrastructure for allowing the next step. In particular, the mouse interaction could avoid garbling the global settings, and each new 'plot' command entered from the command line could reset the mouse code's copy of the settings. Conceptually, we have two independent streams of commands. For that to work without strange surprises like the one you observed, those two streams of commands have to work on independant sets of status variables, synchronized only on explicit request. > If one plot is zoomed and then a second > is generated, what will you use for the ranges of the second plot? The 'command line' settings. The idea would be that the mouse interaction would have its *own* set of settings to play with. One per simultaneously open plot window, actually. > which would mean that the range settings in this command only apply to > replot and when a new plot command comes along, the original ranges are > used, not the "temp" or "replot" ones. Also, with the new plot command, > these "temp" or "replot" settings are changed to those ranges > corresponding to "plot". You're just reinventing the same scheme I've been talking about ;-) Except that I wouldn't limit that to the ranges, but have a complete collections of all gnuplot settings. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-20 15:36:54
|
On Fri, 14 May 2004, Hans-Bernhard Broeker wrote: > set yrange [35.5:*] > load 'using.dem' > # break after the first plot. > > You'll find the impulses end at 35 instead of 35.5, which is below the > bottom border. Looks like they were auto-extended to the nearest tick > position, like autoscaled ranges. This has to be investigated at > source level. I've looked into this, and found the problem. It's not actually the baseline that got mistreated, but the points themselves. It was using an int to hold the y value of the datapoint before clipping it to the range boundaries. As soon as they're non-integer values, like the ones you'll almost invariably generate in mouse interaction, this breaks spectacularly. Fixed in CVS as I write this. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Daniel J S. <dan...@ie...> - 2004-05-20 17:36:33
|
Hans-Bernhard Broeker wrote: >On Fri, 14 May 2004, Hans-Bernhard Broeker wrote: > > > >> set yrange [35.5:*] >> load 'using.dem' >> # break after the first plot. >> >>You'll find the impulses end at 35 instead of 35.5, which is below the >>bottom border. Looks like they were auto-extended to the nearest tick >>position, like autoscaled ranges. This has to be investigated at >>source level. >> >> > >I've looked into this, and found the problem. It's not actually the >baseline that got mistreated, but the points themselves. It was using an >int to hold the y value of the datapoint before clipping it to the range >boundaries. As soon as they're non-integer values, like the ones you'll >almost invariably generate in mouse interaction, this breaks >spectacularly. > >Fixed in CVS as I write this. > > Great! Thanks. There is a lag in the CVS download, so I will confirm at a latter time. Dan -- Dan Sebald email: daniel DOT sebald AT ieee DOT org URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/ |
|
From: Daniel J S. <dan...@ie...> - 2004-05-13 17:27:53
|
Hans-Bernhard Broeker wrote: >On Wed, 12 May 2004, Daniel J Sebald wrote: > > > >>Here is something odd in the latest CVS version. In the "using.dem" >>script, for the first plot, with the mouse active, zoom in on say a top >>middle third of the data. There will be some lines extending below the >>bottom border. The length of the lines seems to vary upon what area was >>zoomed. (That is, do this again and the line lengths may be shorter or >>longer by random.) >> >> > >'impulses' plots assume the plot has a baseline they can use. Zooming may >break that assumption. There have been problems like this with impulses >in the past. So yes, this is a bug, but not an entirely unexpected one. > I see what is happening now. Impulses should behave so that negative numbers have a line appearing below y=0. However, it appears that the current behavior does the same thing for *any* border that appears at the bottom of the plot. For example, say the bottom border is at y=15. A value of 17 in the original plot now has a line going from 15 to 17. A value of 14 in the original plot now has a line going from 14 to 15. For some reason, gnuplot thinks it can plot outside the bottom border. There shouldn't be lines below the border. Agreed? >>With the first plot still zoomed, go to the command line, hit return and >>go to the second plot. The second plot will be zoomed also. (Should it >>stay zoomed?) In the window, unzoom the second plot by typing 'u'. The >>ranges don't seem to be very nice. The image is small. The second plot >>script issues a >> >>set xrange [1:8] >> >>Is there a problem with setting the range when in zoomed mode? >> >> > >No. There's a more general problem in the way zooming, and especially the >'u'nzoom hotkey works. The general problem is that mouse interactions >change the global state of gnuplot settings. You can see that happening >by typing the '6' hotkey: each zooming operation modifies the global range >settings. > >In scripts like our demos, where all settings not explicitly changed >between plots are assumed to keep the values from the previous plot >command, that will break massively. Until we implement separate global >data sets for each plot, so the mousing code can work on a copy instead of >the single instance of all the settings we have, I don't think there's >much that can be done about that. > >Workaround: don't zoom in demos; or if you do, remember to unzoom _before_ >you proceed to the next plot. Using 'unzoom' on a different graph than the >one you zoomed on is IMHO begging for trouble. > So, when unzoomed in the second plot, the ranges go back to [*:*] or something like that. But why should the explicit set xrange [1:8] be discarded? Anyway, I don't see how the "each plot has its own settings" would change matters. If one plot is zoomed and then a second is generated, what will you use for the ranges of the second plot? You're still going to have this same scenario. What you are suggesting is useful for the situation where there are multiple plot windows and each has its own record of ranges, etc. However to solve this zoom settings across plots problem, it seems to me that the only requirement is that range sets from the command line and from the mouse be distinguishable. (But that currently may not be the case in Gnuplot.) It seems to me that you have to have the ability to distinguish where the range set originated from, otherwise a good solution can't be done. One possibility might be that an option be added to "set range" which stands for "temporary range set", e.g., set xrange [x_left:x_right] temp or maybe set xrange [x_left:x_right] replot which would mean that the range settings in this command only apply to replot and when a new plot command comes along, the original ranges are used, not the "temp" or "replot" ones. Also, with the new plot command, these "temp" or "replot" settings are changed to those ranges corresponding to "plot". That would mean internally, gnuplot has x_range_plot x_range_replot Any commands "replot" use the settings in x_range_replot. Any commands "plot" use x_range_plot. A "plot" command does x_range_replot = x_range_plot. "set xrange [:] replot" does x_range_replot = [:]. "set xrange [:]" does x_range_replot = x_range_plot = [:]. Thus, the mouse zoom could do a set xrange [:] replot set yrange [:] replot replot and not disturb the overall settings. >[... other problem...] > > >>strings would be shifted, the key would be in the wrong place. The next >>two or three plots showed the same thing, getting progressively worse. >> The problem then corrected itself and things worked fine again. I >>haven't been able to reproduce this. >> >> > >Well, next time you come across this, 'save' the state of the broken plot >then, before it disappears. > OK Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-05-13 17:48:44
|
Daniel J Sebald wrote:
>
> Thus, the mouse zoom could do a
>
> set xrange [:] replot
> set yrange [:] replot
> replot
>
> and not disturb the overall settings.
Or, even simpler might be that "replot" has its own {ranges} option.
Then one wouldn't have to internally keep track of x_range_replot,
y_range_replot, etc. Just use the values in the
replot [:] [:]
command and discard them. The consequence is that "replot" by itself
has an inherent "unzooming" effect. Which I think isn't unreasonable.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-05-13 19:23:36
|
Yes, I believe that "replot" should have its own ranges options. Try this:
plot [0:50] [-2:2] sin(x)
and attempt to zoom. It won't zoom! That certainly isn't a user
expectation, is it? So instead of
set xrange [x_left:x_right]
set yrange [y_bottom:y_top]
replot
the mouse should issue
replot [x_left:x_right] [y_bottom:y_top]
I think that fixes all confusion then if the ranges in replot override
the current ranges and are then simply discarded.
Dan
Daniel J Sebald wrote:
>
>
> Daniel J Sebald wrote:
>
>>
>> Thus, the mouse zoom could do a
>>
>> set xrange [:] replot
>> set yrange [:] replot
>> replot
>>
>> and not disturb the overall settings.
>
>
>
> Or, even simpler might be that "replot" has its own {ranges} option.
> Then one wouldn't have to internally keep track of x_range_replot,
> y_range_replot, etc. Just use the values in the
>
> replot [:] [:]
>
> command and discard them. The consequence is that "replot" by itself
> has an inherent "unzooming" effect. Which I think isn't unreasonable.
>
> Dan
>
>
>
>
--
Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/
|
|
From: Daniel J S. <dan...@ie...> - 2004-05-13 19:40:39
|
Daniel J Sebald wrote: > the mouse should issue > > replot [x_left:x_right] [y_bottom:y_top] Of course, the "u"nzoom function would be implemented by gplt_x11 just issuing a replot Dan |
|
From: Petr M. <mi...@ph...> - 2004-05-17 08:57:39
|
> plot [0:50] [-2:2] sin(x) > > and attempt to zoom. It won't zoom! That certainly isn't a user > expectation, is it? See also Bug Request 921028 Mouse zoom doesn't work if range has been given In the old ages of mousing, I intended this behaviour, mainly for use such as plot [0:11] sin(x) => you can fix x-range, and zoom by mouse only in y-axis. If you wish to use mouse, don't do plot [ranges] but set xrange ...; plot ... Mousing is interactive stuff .. you can do your script compatible. Or is there any situation why plot [range] should be used instead of set xrange; plot ? --- PM |
|
From: Daniel J S. <dan...@ie...> - 2004-05-17 17:20:42
|
Petr Mikulik wrote: >>plot [0:50] [-2:2] sin(x) >> >>and attempt to zoom. It won't zoom! That certainly isn't a user >>expectation, is it? >> >> > >See also Bug Request > > 921028 Mouse zoom doesn't work if range has been given > > >In the old ages of mousing, I intended this behaviour, mainly for use such >as > > plot [0:11] sin(x) > >=> you can fix x-range, and zoom by mouse only in y-axis. > I guess. But I wonder how many people are cognizant enough of the mouse behavior to understand this is possible. Also, if there is this option of only allowing zooming in the y-axis, the logical thing would be for the mouse cursor to change from drawing a zoom box to drawing a zoom "bar" in only the y direction. > >If you wish to use mouse, don't do plot [ranges] but >set xrange ...; plot ... > So, is intended behavior that the mouse zoom change gnuplot's internal x-range and y-range so that a "replot" can be done to a different terminal device and that plot will have the new zoomed x-range and y-range? Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-05-14 03:04:03
|
Hans-Bernhard Broeker wrote: >>strings would be shifted, the key would be in the wrong place. The next >>two or three plots showed the same thing, getting progressively worse. >> The problem then corrected itself and things worked fine again. I >>haven't been able to reproduce this. >> >> > >Well, next time you come across this, 'save' the state of the broken plot >then, before it disappears. > > I believe I am able to replicate the plot object placement problem in X11. The fillstyle demo seems particularly apt to cause its occurrence. After doing load 'fill_style.dem' and the plot window appears, resize the plot window so that it is rather narrow, say 2 or 3cm or a ration of 6 to 1. Now hit return for the next plot. Resize the window back to the normal size, and I see a mispositioned plot and objects not in the right place, or filled regions at strange angles. Hitting return will sometimes continue to produce mispositioned plots. After a few of these strange plots it will correct itself. Here is something else I noticed, totally unrelated from that. Running the same demo, I accidently hit the up arrow (out of habit of displaying the last command, but in fact I'm in pause mode so no command appears, but instead ^[[A. Now after hitting return, the plot takes a very long time to appear. Successive plots also seem to take a long time. Ethan, is this the same situation as we were talking about before? Or might it have to do with command memory and the "pause" command? Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-05-14 05:26:05
|
On Thursday 13 May 2004 08:26 pm, Daniel J Sebald wrote: > > I believe I am able to replicate the plot object placement problem in > X11. The fillstyle demo seems particularly apt to cause its occurrence. > After doing > > load 'fill_style.dem' > > and the plot window appears, resize the plot window so that it is rather > narrow, say 2 or 3cm or a ration of 6 to 1. Now hit return for the next > plot. Resize the window back to the normal size, and I see a > mispositioned plot and objects not in the right place, or filled regions > at strange angles. Hitting return will sometimes continue to produce > mispositioned plots. After a few of these strange plots it will correct > itself. It doesn't do anything odd for me. The only ugliness I see is that the font positioning is not quite correct immediately after resizing the window. This is inherent in the way the gnuplot<->gnuplot_x11 communication is done. The font info is updated at the start of every plot or replot command. But a resize by itself does not trigger a replot. So right after you resize the plot the actual text layout is no longer correct for the new plot size. But as soon as you do a plot or replot it should be OK again. > Here is something else I noticed, totally unrelated from that. Running > the same demo, I accidently hit the up arrow (out of habit of displaying > the last command, but in fact I'm in pause mode so no command appears, > but instead ^[[A. Now after hitting return, the plot takes a very long > time to appear. Successive plots also seem to take a long time. Ethan, > is this the same situation as we were talking about before? No. It sounds like something is wrong with your configuration. For me if I hit up-arrow as you say, it buffers the input and then when I hit return I get an immediate jump through the next several plots because of the extra characters in the input buffer. No delay at all. Try a 'make clean' and 'make' to force everything to recompile jointly. Then see if you can replicate these problems. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Daniel J S. <dan...@ie...> - 2004-05-14 08:09:07
|
Ethan A Merritt wrote: >On Thursday 13 May 2004 08:26 pm, Daniel J Sebald wrote: > > >>I believe I am able to replicate the plot object placement problem in >>X11. The fillstyle demo seems particularly apt to cause its occurrence. >> After doing >> >>load 'fill_style.dem' >> >>and the plot window appears, resize the plot window so that it is rather >>narrow, say 2 or 3cm or a ration of 6 to 1. Now hit return for the next >>plot. Resize the window back to the normal size, and I see a >>mispositioned plot and objects not in the right place, or filled regions >>at strange angles. Hitting return will sometimes continue to produce >>mispositioned plots. After a few of these strange plots it will correct >>itself. >> >> > >It doesn't do anything odd for me. The only ugliness I see is that the >font positioning is not quite correct immediately after resizing the window. >This is inherent in the way the gnuplot<->gnuplot_x11 communication is >done. The font info is updated at the start of every plot or replot >command. But a resize by itself does not trigger a replot. So right after >you resize the plot the actual text layout is no longer correct for the new >plot size. But as soon as you do a plot or replot it should be OK again. > > > > >>Here is something else I noticed, totally unrelated from that. Running >>the same demo, I accidently hit the up arrow (out of habit of displaying >>the last command, but in fact I'm in pause mode so no command appears, >>but instead ^[[A. Now after hitting return, the plot takes a very long >>time to appear. Successive plots also seem to take a long time. Ethan, >>is this the same situation as we were talking about before? >> >> > >No. It sounds like something is wrong with your configuration. >For me if I hit up-arrow as you say, it buffers the input and then >when I hit return I get an immediate jump through the next several >plots because of the extra characters in the input buffer. No delay at all. > >Try a 'make clean' and 'make' to force everything to recompile jointly. >Then see if you can replicate these problems. > OK, I did a make clean. Still getting the same thing. Attached are some example PNG plots. The first looks like the key element is much larger than it should be. The second has the plot upside down. The third has a key element drawn in a random direction. I've updated my system a bit so that "prepare" and "configure" work without complaint. Here are a few bits of info if it helps: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.0) This file was extended by config.status, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ ./config.status ** Configuration summary for gnuplot 4.0.0: Where is the help file? /usr/local/share/gnuplot/4.0/gnuplot.gih configure:13496: result: Use builtin minimal readline configure:13512: result: Enable generation of JPEG files configure:13522: result: Enable generation of PNG files configure:13527: result: using gd driver configure:13545: result: Enable generation of PDF files configure:13559: result: Build gnuplot-mode for X/Emacs configure:13569: result: Build LaTeX tutorial configure:13574: result: Use the X Window System configure:13577: result: Enable mouse for X11 configure:13583: result: Enable pm3d configure:13588: result: Enable filledboxes configure:13593: result: Enable relative boxwidths configure:13598: result: Enable defined(variable) test configure:13618: result: Enable fitting error variables ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_c_compiler_gnu=yes ac_cv_c_const=yes ac_cv_c_inline=inline ac_cv_c_stringize=yes ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext= ac_cv_func_atexit=yes ac_cv_func_bcopy=yes ac_cv_func_bzero=yes ac_cv_func_connect=yes ac_cv_func_doprnt=no ac_cv_func_erf=yes ac_cv_func_erfc=yes ac_cv_func_gamma=yes ac_cv_func_getcwd=yes ac_cv_func_gethostbyname=yes ac_cv_func_index=yes ac_cv_func_lgamma=yes ac_cv_func_memcpy=yes ac_cv_func_memmove=yes ac_cv_func_memset=yes ac_cv_func_on_exit=yes ac_cv_func_pclose=yes ac_cv_func_poll=yes ac_cv_func_popen=yes ac_cv_func_remove=yes ac_cv_func_rindex=yes ac_cv_func_select=yes -- Dan Sebald email: daniel DOT sebald AT ieee DOT org URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X