From: Mojca M. <moj...@gm...> - 2009-07-21 10:44:51
|
Hello, I accidentally used "plot [bigger:smaller]", but when I corrected the mistake, the plotting range didn't restore to the appropriate value. Would it make sense to fix that behaviour? Example: # ok plot [0:10] sin(x) # ok plot [10:0] sin(x) # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset" does plot [0:10] sin(x) Thanks, Mojca |
From: Thomas S. <t.s...@fz...> - 2009-07-21 12:39:58
|
set xrange [] noreverse Mojca Miklavec wrote: > > Hello, > > I accidentally used "plot [bigger:smaller]", but when I corrected the > mistake, the plotting range didn't restore to the appropriate value. > Would it make sense to fix that behaviour? > > Example: > > # ok > plot [0:10] sin(x) > # ok > plot [10:0] sin(x) > # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset" > does > plot [0:10] sin(x) > > Thanks, > Mojca > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full > prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > -- View this message in context: http://www.nabble.com/irreversibly-reversing-range-tp24585446p24586919.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
From: Mojca M. <moj...@gm...> - 2009-07-21 13:11:18
|
On Tue, Jul 21, 2009 at 14:39, Thomas Sefzick wrote: > > set xrange [] noreverse Thanks. But shouldn't it change back automatically? It automatically changes to "reverse" as soon as one uses [more:less], but doesn't automatically change back. I mean ... > show xrange set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) > plot [0:10] sin(x) > show xrange set xrange [ * : * ] noreverse nowriteback # (currently [0.00000:10.0000] ) > plot sin(x) # only "currently" changes, but gets restored as soon as one drops using explicit [:] > show xrange set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) > plot [10:0] sin(x) > show xrange set xrange [ * : * ] reverse nowriteback # (currently [10.0000:0.00000] ) > plot sin(x) # in my opinion this should become "noreverse" automatically # unless someone uses "set xrange [] reverse" by explicitely calling it > show xrange set xrange [ * : * ] reverse nowriteback # (currently [10.0000:-10.0000] ) I didn't check internals, but maybe a separate variable is needed to track "current reverse" just as there is "current range" after #. Mojca > Mojca Miklavec wrote: >> >> Hello, >> >> I accidentally used "plot [bigger:smaller]", but when I corrected the >> mistake, the plotting range didn't restore to the appropriate value. >> Would it make sense to fix that behaviour? >> >> Example: >> >> # ok >> plot [0:10] sin(x) >> # ok >> plot [10:0] sin(x) >> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset" >> does >> plot [0:10] sin(x) >> >> Thanks, >> Mojca |
From: Ethan M. <merritt@u.washington.edu> - 2009-07-21 15:46:00
|
On Tuesday 21 July 2009, Mojca Miklavec wrote: > On Tue, Jul 21, 2009 at 14:39, Thomas Sefzick wrote: > > > > set xrange [] noreverse > > Thanks. But shouldn't it change back automatically? > > It automatically changes to "reverse" as soon as one uses [more:less], > but doesn't automatically change back. I tend to agree with you on this point, but... > I mean ... > > > show xrange > set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) > > plot [0:10] sin(x) > > show xrange > set xrange [ * : * ] noreverse nowriteback # (currently [0.00000:10.0000] ) > > plot sin(x) > # only "currently" changes, but gets restored as soon as one drops > using explicit [:] > > show xrange > set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) > > plot [10:0] sin(x) > > show xrange > set xrange [ * : * ] reverse nowriteback # (currently [10.0000:0.00000] ) > > plot sin(x) > # in my opinion this should become "noreverse" automatically there I completely disagree. You set the range to be [10:0], and for a subsequent plot to silently change that is a really bad idea. IMHO the real problem is that placing a range in the plot command itself plot ... [foo:baz] ... does not have an obvious meaning. Does that range apply to only the clause it appears in? Does it apply to the entire plot command? Does it persist after the plot command? Does it affect the value of variables evaluated during the plot command? Yes, it is possible to determine the answers to these questions by experimentation, but it seems to me that the better approach is simply not to use this construct. There are no such ambiguities associated with an explicit set xrange [foo:baz]; plot ... Ethan > # unless someone uses "set xrange [] reverse" by explicitely calling it > > show xrange > set xrange [ * : * ] reverse nowriteback # (currently [10.0000:-10.0000] ) > > I didn't check internals, but maybe a separate variable is needed to > track "current reverse" just as there is "current range" after #. > > Mojca > > > Mojca Miklavec wrote: > >> > >> Hello, > >> > >> I accidentally used "plot [bigger:smaller]", but when I corrected the > >> mistake, the plotting range didn't restore to the appropriate value. > >> Would it make sense to fix that behaviour? > >> > >> Example: > >> > >> # ok > >> plot [0:10] sin(x) > >> # ok > >> plot [10:0] sin(x) > >> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset" > >> does > >> plot [0:10] sin(x) > >> > >> Thanks, > >> Mojca > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
From: Hans-Bernhard B. <HBB...@t-...> - 2009-07-21 21:32:17
|
Ethan Merritt wrote: > IMHO the real problem is that placing a range in the plot command itself > plot ... [foo:baz] ... > does not have an obvious meaning. Well, actually this one has no meaning at all --- in a plot command the range comes first, or not at all, i.e. it must be plot [foo:baz] ... And thus modified it does have a well-documented meaning (see "help plot ranges"): it sets the range for the duration of that plot command. That's been so for as long as it existed. IMHO that should qualify as obvious. If memory serves originally there was only this range option in the 'plot' argument list. "Set xrange" was added later, to make the command interface more efficient when there are lots of plots with the same range. |
From: Mojca M. <moj...@gm...> - 2009-07-21 16:45:28
|
On Tue, Jul 21, 2009 at 17:45, Ethan Merritt wrote: > On Tuesday 21 July 2009, Mojca Miklavec wrote: >> On Tue, Jul 21, 2009 at 14:39, Thomas Sefzick wrote: >> > >> > set xrange [] noreverse >> >> Thanks. But shouldn't it change back automatically? >> >> It automatically changes to "reverse" as soon as one uses [more:less], >> but doesn't automatically change back. > > I tend to agree with you on this point, but... > >> I mean ... >> >> > show xrange >> set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) >> > plot [0:10] sin(x) >> > show xrange >> set xrange [ * : * ] noreverse nowriteback # (currently [0.00000:10.0000] ) >> > plot sin(x) >> # only "currently" changes, but gets restored as soon as one drops >> using explicit [:] >> > show xrange >> set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) >> > plot [10:0] sin(x) >> > show xrange >> set xrange [ * : * ] reverse nowriteback # (currently [10.0000:0.00000] ) >> > plot sin(x) >> # in my opinion this should become "noreverse" automatically > > there I completely disagree. You set the range to be [10:0], and for a > subsequent plot to silently change that is a really bad idea. > > IMHO the real problem is that placing a range in the plot command itself > plot ... [foo:baz] ... > does not have an obvious meaning. > Does that range apply to only the clause it appears in? > Does it apply to the entire plot command? > Does it persist after the plot command? It (almost) never does. plot [foo:baz] something plots betwee foo and baz. In next plot this setting is (always) forgotten. When working with data files one usually doesn't want to have xrange defined, so one alternative is to use set xrange [foo:baz] plot sin(x) set xrange restore plot 'a.dat' as opposed to plot [foo:baz] sin(x) plot 'a.dat' but I prefer the second one (much shorter). Since one cannot set "subrange" of plots anyway, i.e. plot 'a.dat', [0:1] f(x) doesn't work, one needs to use plot 'a.dat', (x>=0 && x<=1) ? f(x) : 1/0 instead, the "plot [foo:baz]" seem very well defined to me, but I might be missing some weird cases (multiplots?) that I don't know well. > Does it affect the value of variables evaluated during the plot command? > > Yes, it is possible to determine the answers to these questions by experimentation, > but it seems to me that the better approach is simply not to use this construct. > There are no such ambiguities associated with an explicit > set xrange [foo:baz]; > plot ... Sure, but see above. That means almost twice as much typing. The fact is that one almost never needs reversed axis, so the issue hardly affects anyone and therefore has a low priority anyway. (I purely accidentally deleted one chacater too much when specifying the range and have been bitten by that unexpected behaviour. I don't expect myself to be affected in any other circumstances.) I would call it a tiny bug, but whether it's worth fixing (or if it's considered a bug at all) still depends on developers. Mojca >> # unless someone uses "set xrange [] reverse" by explicitely calling it >> > show xrange >> set xrange [ * : * ] reverse nowriteback # (currently [10.0000:-10.0000] ) >> >> I didn't check internals, but maybe a separate variable is needed to >> track "current reverse" just as there is "current range" after #. >> >> Mojca >> >> > Mojca Miklavec wrote: >> >> >> >> Hello, >> >> >> >> I accidentally used "plot [bigger:smaller]", but when I corrected the >> >> mistake, the plotting range didn't restore to the appropriate value. >> >> Would it make sense to fix that behaviour? >> >> >> >> Example: >> >> >> >> # ok >> >> plot [0:10] sin(x) >> >> # ok >> >> plot [10:0] sin(x) >> >> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset" >> >> does >> >> plot [0:10] sin(x) >> >> >> >> Thanks, >> >> Mojca |
From: Daniel J S. <dan...@ie...> - 2012-09-08 18:17:45
|
I see there is new behavior for the option "reverse" for gnuplot version 4.7+. It seems to me the change is that "{no}reverse" now only applies to autoscaling. (In fact, the documentation ostensibly says that.) Could someone write a one or two sentence summary of why the change. E.g., the previous behavior was too confusing or caused a conflict? I just want to be able to explain why the change if asked. Reverse axes aren't used real often, except in the case of y-axis and images where it is quite common to see the origin in the upper left corner of a plot. (Octave will need a change to address this.) I also want to confirm that the new behavior is really what is desired. If there is something that may have been wrong with the previous behavior it is that the old syntax was too flexible. I think it was Ethan that pointed out controlling the axis from within the plot command itself was problematic, e.g., plot [0:500] x I see the point in the sense that multiple items with different range settings can be a conflict. Maybe we shouldn't think of the range specified within the plot command as "axis range". Perhaps it is the fact that range setting itself can control the orientation of an axes, i.e., [500:0]. If that were disallowed, then there would still be an ability to control range within the plot command, but not be able to control the orientation of the axis. So rather than the change "reverse only applies to autoscaling", another change could have been "range limits no longer control orientation". So that would mean set xrange [0:500] set xrange [500:0] plot [0:500] plot [500:0] all mean the same thing, i.e., the xaxis range is from 0 to 500 using the typical Cartesian orientation. Also set xrange [0:500] reverse set xrange [500:0] reverse set xrange reverse plot [0:500] set xrange reverse plot [500:0] would all mean the same thing, i.e., the xaxis range is from 0 to 500 but using the reverse orientation. Dan |
From: Ethan M. <merritt@u.washington.edu> - 2012-09-08 20:42:33
|
On Saturday, 08 September 2012, Daniel J Sebald wrote: > I see there is new behavior for the option "reverse" for gnuplot version > 4.7+. It seems to me the change is that "{no}reverse" now only applies > to autoscaling. (In fact, the documentation ostensibly says that.) > > Could someone write a one or two sentence summary of why the change. > E.g., the previous behavior was too confusing or caused a conflict? I > just want to be able to explain why the change if asked. The old behaviour was bizarre. Example: gnuplot> set xrange [1:0] gnuplot> show xrange set xrange [ 0.00000 : 1.00000 ] reverse nowriteback gnuplot> set xrange [0:1] gnuplot> show xrange set xrange [ 0.00000 : 1.00000 ] reverse nowriteback Notice that the "reverse" property is now stuck, and no ordinary sequence of autoscaling/autorange/set xrange commands will unstick it. Only an explicit "set xr [<something>:<something>] noreverse" will work, but inside a script you can't know in advance when this might be necessary, and at that point you may not know what the correct <something> is anyhow. See also various old bug reports going back 10 years or so, e.g. #230686. > > Reverse axes aren't used real often, except in the case of y-axis and > images where it is quite common to see the origin in the upper left > corner of a plot. (Octave will need a change to address this.) You have neglected that case of inverted axis scaling x2 = F(1/x1) Consider, for example: http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/ > I also want to confirm that the new behavior is really what is desired. > If there is something that may have been wrong with the previous > behavior it is that the old syntax was too flexible. I think it was > Ethan that pointed out controlling the axis from within the plot command > itself was problematic, e.g., > > plot [0:500] x Yeah, that too. If the "reverse" flag got stuck on, the in-line range specifiers didn't work reliably. Ethan > I see the point in the sense that multiple items with different range > settings can be a conflict. Maybe we shouldn't think of the range > specified within the plot command as "axis range". > > Perhaps it is the fact that range setting itself can control the > orientation of an axes, i.e., [500:0]. If that were disallowed, then > there would still be an ability to control range within the plot > command, but not be able to control the orientation of the axis. > > So rather than the change "reverse only applies to autoscaling", another > change could have been "range limits no longer control orientation". So > that would mean > > set xrange [0:500] > set xrange [500:0] > plot [0:500] > plot [500:0] > > all mean the same thing, i.e., the xaxis range is from 0 to 500 using > the typical Cartesian orientation. Also > > set xrange [0:500] reverse > set xrange [500:0] reverse > set xrange reverse > plot [0:500] > set xrange reverse > plot [500:0] > > would all mean the same thing, i.e., the xaxis range is from 0 to 500 > but using the reverse orientation. > > Dan > |
From: Hans-Bernhard B. <HBB...@t-...> - 2009-07-21 23:38:46
|
Mojca Miklavec wrote: > plot [0:10] sin(x) show xrange > plot [10:0] sin(x) show xrange > plot [0:10] sin(x) show xrange I suggest everyone who tries this puts in those 'show xrange' between plots to see what actually happens. There are two separate issues here. 1) plot [10:0] sin(x) may never change the state of the reverse option of 'set xrange'. It doesn't change the range itself, so it should leave the reverse option alone, too. But this in and of itself is relatively harmless. This bug has been in the program since at least 4.2.3 2) The visible bug that the x axis is actually still reversed in the third plot appears to be newer. It was introduced after 4.2.3, and is still present in the current CVS head. |
From: Daniel J S. <dan...@ie...> - 2012-09-08 22:05:49
|
On 09/08/2012 03:42 PM, Ethan Merritt wrote: > On Saturday, 08 September 2012, Daniel J Sebald wrote: >> I see there is new behavior for the option "reverse" for gnuplot version >> 4.7+. It seems to me the change is that "{no}reverse" now only applies >> to autoscaling. (In fact, the documentation ostensibly says that.) >> >> Could someone write a one or two sentence summary of why the change. >> E.g., the previous behavior was too confusing or caused a conflict? I >> just want to be able to explain why the change if asked. > > The old behaviour was bizarre. Example: > gnuplot> set xrange [1:0] > gnuplot> show xrange > set xrange [ 0.00000 : 1.00000 ] reverse nowriteback Well, I don't see why "reverse" should have been set on account of that. It should have been ** gnuplot> show xrange set xrange [ 1.00000 : 0.00000 ] noreverse nowriteback > gnuplot> set xrange [0:1] > gnuplot> show xrange > set xrange [ 0.00000 : 1.00000 ] reverse nowriteback > > Notice that the "reverse" property is now stuck, and no ordinary > sequence of autoscaling/autorange/set xrange commands will unstick it. > Only an explicit "set xr [<something>:<something>] noreverse" > will work, but inside a script you can't know in advance when this > might be necessary, and at that point you may not know what the > correct<something> is anyhow. Yes, bizarre. > See also various old bug reports going back 10 years or so, e.g. #230686. > >> >> Reverse axes aren't used real often, except in the case of y-axis and >> images where it is quite common to see the origin in the upper left >> corner of a plot. (Octave will need a change to address this.) > > You have neglected that case of inverted axis scaling x2 = F(1/x1) > Consider, for example: > http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/ But x2, y2 are not controlled by anything inside a plot statement. From the "plot->range" documentation: plot [-pi:pi] [-1.3:1.3] [-1:1] sin(t),t**2 Note that the x2range and y2range cannot be specified here---`set x2range` and `set y2range` must be used. OK, so rethinking what I first wrote as an alternative, its seems a simpler alternative might be to not modify the "{no}reverse" setting on the basis of the in-command ranges (** above). I'm just wondering if people are more inclined to think that "reverse" means to reverse the axis direction all of the time rather than just for the one case of autoscaling. Dan |
From: Daniel J S. <dan...@ie...> - 2012-09-08 22:12:24
|
On 09/08/2012 05:05 PM, Daniel J Sebald wrote: >>> Reverse axes aren't used real often, except in the case of y-axis and >>> images where it is quite common to see the origin in the upper left >>> corner of a plot. (Octave will need a change to address this.) >> >> You have neglected that case of inverted axis scaling x2 = F(1/x1) >> Consider, for example: >> http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/ Oh, I see what you meant. Sure, reversing the orientation is useful. Dan |
From: Daniel J S. <dan...@ie...> - 2012-09-09 20:04:07
|
This morning I came to wonder, What if one wants one end of the range fixed while the other is autoscaled? So I tried a few things, and the results certainly aren't intuitive, or are buggy. Say, for example, my intention is to make a plot for which the left side starts at x=30 and is autoscaled on the right side. I try gnuplot> plot [30:*] x and get something very unexpected, unless I really think about it. First, the result is reversed, slightly unexpected. Then I wonder, 10 is the "upper" range? OK, now I see. If I were to "plot x", the lower range is 0 and upper range 10 by definition. So that is where the reverse axis is coming from. That means if one does gnuplot> plot [3:*] x it comes out non-reversed. And yes that is the result. OK, perhaps gnuplot should be changed so that the upper limit is "rangemin + 10", and the symmetric case "rangemax - 10". Out of curiosity I try gnuplot> set xrange [3:*] reverse gnuplot> plot x and the graph changes. However, gnuplot> set xrange [30:*] noreverse gnuplot> plot x gnuplot> set xrange [30:*] reverse gnuplot> plot x brings no change in the graph. Perhaps that is just a ramification of the "rangemin + 10" issue. So, I wonder how I can get better control of the range settings and achieve the initial goal of left end of plot fixed at thirty and the right end autoadjust. How about gnuplot> plot [30:40<*] x ? The above looks to be a bug. What I'm seeing here is: [x11 terminal] A plot range running from x=30 at left, to x=40 at right (that's good). Then there is a red line that appears in the upper left corner as though it originated from the origin and extended to (30,30). [Qt terminal] Similar to the result of x11 terminal, but there is an additional aberrant line running vertical across the screen. So, there might be two (more) bugs there, one Qt-specific, the other not specific to a terminal. ... Anyway, my mind keeps floating back to wondering if there is an inherent problem of too much flexibility in allowing the orientation of the axis to be changed by the numeric order relationship in the range setting. As Ethan described, most definitely the numeric values in the range have to be decoupled from any influence on toggling "{no}reverse". (See ** below.) But I still wonder if the latest version (4.7 beta) is a more incompatible change than necessary. I would think that "reverse" could be viewed as "do all the range computations, then when all done reverse the range". In any case, I have a patch all set for Octave to address the proposed mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an official release. Perhaps we could address the bugs I described above with the current proposed 4.7 behavior in mind and then reassess how one-side-autoadjust works. That is, fix things so that: [a:*] - The autoadjust value * is greater than a [*:b] - The autoadjust value * is less than b Dan On 09/08/2012 05:05 PM, Daniel J Sebald wrote: > On 09/08/2012 03:42 PM, Ethan Merritt wrote: >> On Saturday, 08 September 2012, Daniel J Sebald wrote: >>> I see there is new behavior for the option "reverse" for gnuplot version >>> 4.7+. It seems to me the change is that "{no}reverse" now only applies >>> to autoscaling. (In fact, the documentation ostensibly says that.) >>> >>> Could someone write a one or two sentence summary of why the change. >>> E.g., the previous behavior was too confusing or caused a conflict? I >>> just want to be able to explain why the change if asked. >> >> The old behaviour was bizarre. Example: >> gnuplot> set xrange [1:0] >> gnuplot> show xrange >> set xrange [ 0.00000 : 1.00000 ] reverse nowriteback > > Well, I don't see why "reverse" should have been set on account of that. > It should have been > > ** > gnuplot> show xrange > set xrange [ 1.00000 : 0.00000 ] noreverse nowriteback > > >> gnuplot> set xrange [0:1] >> gnuplot> show xrange >> set xrange [ 0.00000 : 1.00000 ] reverse nowriteback >> >> Notice that the "reverse" property is now stuck, and no ordinary >> sequence of autoscaling/autorange/set xrange commands will unstick it. >> Only an explicit "set xr [<something>:<something>] noreverse" >> will work, but inside a script you can't know in advance when this >> might be necessary, and at that point you may not know what the >> correct<something> is anyhow. > > Yes, bizarre. > > >> See also various old bug reports going back 10 years or so, e.g. #230686. >> >>> >>> Reverse axes aren't used real often, except in the case of y-axis and >>> images where it is quite common to see the origin in the upper left >>> corner of a plot. (Octave will need a change to address this.) >> >> You have neglected that case of inverted axis scaling x2 = F(1/x1) >> Consider, for example: >> http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/ > > But x2, y2 are not controlled by anything inside a plot statement. From > the "plot->range" documentation: > > plot [-pi:pi] [-1.3:1.3] [-1:1] sin(t),t**2 > > Note that the x2range and y2range cannot be specified here---`set x2range` > and `set y2range` must be used. > > > OK, so rethinking what I first wrote as an alternative, its seems a > simpler alternative might be to not modify the "{no}reverse" setting on > the basis of the in-command ranges (** above). I'm just wondering if > people are more inclined to think that "reverse" means to reverse the > axis direction all of the time rather than just for the one case of > autoscaling. > > Dan > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > 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 |
From: sfeam (E. Merritt) <eam...@gm...> - 2012-09-09 21:50:20
|
On Sunday, 09 September 2012, Daniel J Sebald wrote: > This morning I came to wonder, What if one wants one end of the range > fixed while the other is autoscaled? So I tried a few things, and the > results certainly aren't intuitive, or are buggy. > > Say, for example, my intention is to make a plot for which the left side > starts at x=30 and is autoscaled on the right side. I try > > gnuplot> plot [30:*] x > > and get something very unexpected, unless I really think about it. Autoscaling doesn't have an obvious meaning for function plots. Normally that command would be followed by 'plot <datafile>', with the meaning that points with x<30 would not be plotted. > First, the result is reversed, slightly unexpected. Then I wonder, 10 > is the "upper" range? OK, now I see. If I were to "plot x", the lower > range is 0 and upper range 10 by definition. Not quite. The default range for function plots is [-10:10] > So that is where the > reverse axis is coming from. That means if one does > > gnuplot> plot [3:*] x > > it comes out non-reversed. And yes that is the result. OK, perhaps > gnuplot should be changed so that the upper limit is "rangemin + 10", > and the symmetric case "rangemax - 10". > > Out of curiosity I try > > gnuplot> set xrange [3:*] reverse > gnuplot> plot x > > and the graph changes. However, > > gnuplot> set xrange [30:*] noreverse > gnuplot> plot x > gnuplot> set xrange [30:*] reverse > gnuplot> plot x > > brings no change in the graph. Perhaps that is just a ramification of > the "rangemin + 10" issue. > > So, I wonder how I can get better control of the range settings and > achieve the initial goal of left end of plot fixed at thirty and the > right end autoadjust. How about > > gnuplot> plot [30:40<*] x None of the above test commands make sense, IMHO. Function plots require a complete range specifier. I'd be in favor of giving an error message in each of those cases. That is, disallow '*' in the range specifier for function plots. <aside> As you probably recall, my opinion is that a range specifier in the plot command is always a bad idea. If it were just me, I'd remove that option altogether. The only reason I can see to allow it is if it is changed so that the in-line range applies only to the immediately following plot clause. That way you could get separate ranges for separate plots: plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) I don't really like that either, but at least it would provide a capability that isn't addressed by simply doing "set xrange" first. </aside> > I would think that "reverse" could > be viewed as "do all the range computations, then when all done reverse > the range". That is indeed what it now means. At least that's the intent. Do you have an example that works otherwise? > In any case, I have a patch all set for Octave to address the proposed > mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an > official release. Perhaps we could address the bugs I described above > with the current proposed 4.7 behavior in mind and then reassess how > one-side-autoadjust works. That is, fix things so that: > > [a:*] - The autoadjust value * is greater than a > [*:b] - The autoadjust value * is less than b That's what it does now in 4.7, at least for me. Again, do you have an example of data-driven autoscaling that gives some other result? |
From: Daniel J S. <dan...@ie...> - 2012-09-10 20:16:53
|
On 09/09/2012 04:50 PM, sfeam (Ethan Merritt) wrote: > On Sunday, 09 September 2012, Daniel J Sebald wrote: >> This morning I came to wonder, What if one wants one end of the range >> fixed while the other is autoscaled? So I tried a few things, and the >> results certainly aren't intuitive, or are buggy. >> >> Say, for example, my intention is to make a plot for which the left side >> starts at x=30 and is autoscaled on the right side. I try >> >> gnuplot> plot [30:*] x >> >> and get something very unexpected, unless I really think about it. > > Autoscaling doesn't have an obvious meaning for function plots. > Normally that command would be followed by 'plot<datafile>', with > the meaning that points with x<30 would not be plotted. > >> First, the result is reversed, slightly unexpected. Then I wonder, 10 >> is the "upper" range? OK, now I see. If I were to "plot x", the lower >> range is 0 and upper range 10 by definition. > > Not quite. The default range for function plots is [-10:10] > >> So that is where the >> reverse axis is coming from. That means if one does >> >> gnuplot> plot [3:*] x >> >> it comes out non-reversed. And yes that is the result. OK, perhaps >> gnuplot should be changed so that the upper limit is "rangemin + 10", >> and the symmetric case "rangemax - 10". >> >> Out of curiosity I try >> >> gnuplot> set xrange [3:*] reverse >> gnuplot> plot x >> >> and the graph changes. However, >> >> gnuplot> set xrange [30:*] noreverse >> gnuplot> plot x >> gnuplot> set xrange [30:*] reverse >> gnuplot> plot x >> >> brings no change in the graph. Perhaps that is just a ramification of >> the "rangemin + 10" issue. >> >> So, I wonder how I can get better control of the range settings and >> achieve the initial goal of left end of plot fixed at thirty and the >> right end autoadjust. How about >> >> gnuplot> plot [30:40<*] x > > None of the above test commands make sense, IMHO. > Function plots require a complete range specifier. > I'd be in favor of giving an error message in each of those cases. > That is, disallow '*' in the range specifier for function plots. gnuplot has always sought to make as much sense out of a command as possible and try plotting something. The following is default behavior: gnuplot> plot [*:*] x gnuplot> plot [*:*] '-' input data ('e' ends) > 1 1 input data ('e' ends) > 2 1 input data ('e' ends) > e Warning: empty y range [1:1], adjusting to [0.99:1.01] How can one say the default range specifier makes any more sense than does [30:*]? > <aside> > As you probably recall, my opinion is that a range specifier in the plot > command is always a bad idea. If it were just me, I'd remove that option > altogether. The only reason I can see to allow it is if it is changed so > that the in-line range applies only to the immediately following plot clause. > That way you could get separate ranges for separate plots: > plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) > I don't really like that either, but at least it would provide a > capability that isn't addressed by simply doing "set xrange" first. > </aside> Yes, I sort of agree with that. That is why I picked the phrasing that the range is associated with the data, not the orientation of the axis. Given the example you wrote, the paradigm is that [10:20] means the data for which x is between 10 and 20, and in that case [20:10] is no different than [10:20]. Using the range specifier to control the orientation of the plot in your example would be a mess. >> I would think that "reverse" could >> be viewed as "do all the range computations, then when all done reverse >> the range". > > That is indeed what it now means. At least that's the intent. > Do you have an example that works otherwise? Well, the change in 4.7 doesn't mean that anymore. The following produce the same graph: gnuplot> set xrange [30:50] gnuplot> plot x gnuplot> set xrange [30:50] reverse gnuplot> plot x Those of us familiar with range specifier history aren't that confused by this. But someone using gnuplot for the first time will by befuddled. In one case the user needs to use the term "reverse" to change the orientation, in another case the user needs to change the order of the numbers in the range specifier. There were sort of three small changes made here: 1) "reverse" no longer has an effect on the range specification, i.e., specifying "[30:50] reverse" doesn't peculiarly change the specification to "[50:30]" 2) The range specification no longer toggles the "{no}reverse" option so that it gets stuck. 3) "reverse" only applies to the autoadjust settings. 1 and 2 I'm happy to see, but I would also add that with those changes it seems to me that the range specification numbers and "reverse" are decoupled. Why shouldn't one be allowed to input: gnuplot> set xrange reverse ^ expecting '[' or 'restore' on its own? Anyway, the most affect on backward compatibility is 3 above, so I'm wondering why that change is preferred. One could argue that set [*:*] reverse would otherwise still stick "reverse". However, the user now has to intentionally changed the setting rather than it happening as a consequence of the range specification. >> In any case, I have a patch all set for Octave to address the proposed >> mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an >> official release. Perhaps we could address the bugs I described above >> with the current proposed 4.7 behavior in mind and then reassess how >> one-side-autoadjust works. That is, fix things so that: >> >> [a:*] - The autoadjust value * is greater than a >> [*:b] - The autoadjust value * is less than b > > That's what it does now in 4.7, at least for me. > Again, do you have an example of data-driven autoscaling that > gives some other result? OK, I'm going to just try a few plots here: gnuplot> reset gnuplot> plot [10:*] '-', x input data ('e' ends) > 5 5 input data ('e' ends) > 8 8 input data ('e' ends) > 12 12 input data ('e' ends) > 15 15 input data ('e' ends) > e gnuplot> show xrange set xrange [ * : * ] noreverse nowriteback # (currently [10.0000:15.0000] ) LOOKS GOOD... gnuplot> plot [*:10] '-', x input data ('e' ends) > 5 5 input data ('e' ends) > 8 8 input data ('e' ends) > 12 12 input data ('e' ends) > 15 15 input data ('e' ends) > e gnuplot> show xrange set xrange [ * : * ] noreverse nowriteback # (currently [5.00000:10.0000] ) LOOKS GOOD... gnuplot> set xrange [10:*] reverse gnuplot> plot '-', x input data ('e' ends) > 5 5 input data ('e' ends) > 8 8 input data ('e' ends) > 12 12 input data ('e' ends) > 15 15 input data ('e' ends) > e gnuplot> show xrange set xrange [ 10.0000 : * ] reverse nowriteback # (currently [:10.0000] ) THE PLOT LOOKS GOOD, BUT I WONDER WHY "currently" DOESN'T SAY "[15.0000:10.0000]" OR "[10.0000:15.0000] reverse"... gnuplot> set xrange [*:10] reverse gnuplot> plot '-', x input data ('e' ends) > 5 5 input data ('e' ends) > 8 8 input data ('e' ends) > 12 12 input data ('e' ends) > 15 15 input data ('e' ends) > e gnuplot> show xrange set xrange [ * : 10.0000 ] reverse nowriteback # (currently [10.0000:] ) AGAIN, PLOT IS AS EXPECTED BUT THE "currently" IS INCOMPLETE WHERE I THINK IT SHOULD SAY "[10.0000:5.0000]". Dan |
From: Karl-Friedrich R. <mai...@gm...> - 2012-09-11 18:45:20
|
On 09.09.2012 23:50, sfeam (Ethan Merritt) wrote: > > <aside> > As you probably recall, my opinion is that a range specifier in the plot > command is always a bad idea. If it were just me, I'd remove that option > altogether. The only reason I can see to allow it is if it is changed so > that the in-line range applies only to the immediately following plot clause. > That way you could get separate ranges for separate plots: > plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) > I don't really like that either, but at least it would provide a > capability that isn't addressed by simply doing "set xrange" first. > </aside> I´d strongly advocate that change, it seems a most stringent solution! That way, the range in the plot command would only refer to the sampling (one could even expand it to include an increment like in "for [::]", e.g. plot [0:2:0.2] f(x)). Then the autoscaling would only rely on the actual points the plot (be it a function or datafile) returns, and adding "reverse" would always have the expected effect of having the highest numbers on the left. Default sampling range for function plots then is [-10:10], and there is just no need for a default range of the scaling of the abscissa. Best regards, Karl |
From: Ethan A M. <sf...@us...> - 2012-09-10 22:36:47
|
On Monday, September 10, 2012 01:16:41 pm Daniel J Sebald wrote: > > None of the above test commands make sense, IMHO. > > Function plots require a complete range specifier. > > I'd be in favor of giving an error message in each of those cases. > > That is, disallow '*' in the range specifier for function plots. > > gnuplot has always sought to make as much sense out of a command as > possible and try plotting something. The following is default behavior: > > gnuplot> plot [*:*] x You do know that the [*:*] part of that command is entirely ignored? As I said, autoscaling only applies to data plots, not function plots. So far as I know that has always been true. > gnuplot> plot [*:*] '-' > input data ('e' ends) > 1 1 > input data ('e' ends) > 2 1 > input data ('e' ends) > e > Warning: empty y range [1:1], adjusting to [0.99:1.01] > > How can one say the default range specifier makes any more sense than > does [30:*]? My view is that neither [*:*] nor [30:*] have a natural meaning in the absence of data. As you discovered, it happens that the '30' replaces the default '-10' for function plots while the '*' is ignored leaving the default '10'. But I don't think that was by design, because '*' was never intended for use with function plots in the first place. > > > <aside> > > As you probably recall, my opinion is that a range specifier in the plot > > command is always a bad idea. If it were just me, I'd remove that option > > altogether. The only reason I can see to allow it is if it is changed so > > that the in-line range applies only to the immediately following plot clause. > > That way you could get separate ranges for separate plots: > > plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) > > I don't really like that either, but at least it would provide a > > capability that isn't addressed by simply doing "set xrange" first. > > </aside> > > Yes, I sort of agree with that. That is why I picked the phrasing that > the range is associated with the data, not the orientation of the axis. > Given the example you wrote, the paradigm is that [10:20] means the > data for which x is between 10 and 20, and in that case [20:10] is no > different than [10:20]. Using the range specifier to control the > orientation of the plot in your example would be a mess. The way I view it is that "set xrange [FOO:BAZ]" means the left end of the axis is pinned at FOO and the right end is pinned at BAZ. The makes sense both externally (what the user sees) and internally (mapping a numerical coordinate onto a screen position). I will note that my primary motivation for the change in 4.7 was to clean up the code internally. The fact that it also IMHO makes a more sensible user-visible syntax is just a side benefit. The change removed a tangle of calls and macros like check_axis_reversed(), CHECK_REVERSE, AXIS_ACTUAL_MIN, etc, and made it a lot easier to implement linked primary/secondary axes. It also fixed corruption in the zoom/restore state if the AXIS_REVERSE flag somehow got set while a plot was zoomed. > >> I would think that "reverse" could > >> be viewed as "do all the range computations, then when all done reverse > >> the range". > > > > That is indeed what it now means. At least that's the intent. > > Do you have an example that works otherwise? > > Well, the change in 4.7 doesn't mean that anymore. The following > produce the same graph: > > gnuplot> set xrange [30:50] > gnuplot> plot x > gnuplot> set xrange [30:50] reverse > gnuplot> plot x > > Those of us familiar with range specifier history aren't that confused > by this. But someone using gnuplot for the first time will by > befuddled. In one case the user needs to use the term "reverse" to > change the orientation, in another case the user needs to change the > order of the numbers in the range specifier. I don't see it that way. To me it seems very intuitive. [30:50] means start at 30 and go to 50. [50:30] means start at 50 and go to 30. The word "reverse" is never needed when you are specifying explicit limits. It's only relevant when the limits are not known in advance - the autoscale from data case. > Why shouldn't one be allowed to input: > > gnuplot> set xrange reverse > ^ > expecting '[' or 'restore' > > on its own? I don't know. But that isn't a recent change - it's always been that way. > Anyway, the most affect on backward compatibility is > ["reverse" only applies to the autoadjust settings] > so I'm wondering why that change is preferred. The `reverse` keyword was added sometime between versions 3.5 and 3.7 Its documentation has always said `reverse` is intended primarily for use with `autoscale` > >> In any case, I have a patch all set for Octave to address the proposed > >> mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an > >> official release. Perhaps we could address the bugs I described above > >> with the current proposed 4.7 behavior in mind and then reassess how > >> one-side-autoadjust works. That is, fix things so that: > >> > >> [a:*] - The autoadjust value * is greater than a > >> [*:b] - The autoadjust value * is less than b > > > > That's what it does now in 4.7, at least for me. > > Again, do you have an example of data-driven autoscaling that > > gives some other result? > > OK, I'm going to just try a few plots here: > > gnuplot> reset > gnuplot> plot [10:*] '-', x > input data ('e' ends) > 5 5 > input data ('e' ends) > 8 8 > input data ('e' ends) > 12 12 > input data ('e' ends) > 15 15 > input data ('e' ends) > e > gnuplot> show xrange > > set xrange [ * : * ] noreverse nowriteback # (currently > [10.0000:15.0000] ) > > LOOKS GOOD... > > gnuplot> plot [*:10] '-', x > input data ('e' ends) > 5 5 > input data ('e' ends) > 8 8 > input data ('e' ends) > 12 12 > input data ('e' ends) > 15 15 > input data ('e' ends) > e > gnuplot> show xrange > > set xrange [ * : * ] noreverse nowriteback # (currently > [5.00000:10.0000] ) > > LOOKS GOOD... > > gnuplot> set xrange [10:*] reverse > gnuplot> plot '-', x > input data ('e' ends) > 5 5 > input data ('e' ends) > 8 8 > input data ('e' ends) > 12 12 > input data ('e' ends) > 15 15 > input data ('e' ends) > e > gnuplot> show xrange > > set xrange [ 10.0000 : * ] reverse nowriteback # (currently [:10.0000] ) > > THE PLOT LOOKS GOOD, BUT I WONDER WHY "currently" DOESN'T SAY > "[15.0000:10.0000]" OR "[10.0000:15.0000] reverse"... > > gnuplot> set xrange [*:10] reverse > gnuplot> plot '-', x > input data ('e' ends) > 5 5 > input data ('e' ends) > 8 8 > input data ('e' ends) > 12 12 > input data ('e' ends) > 15 15 > input data ('e' ends) > e > gnuplot> show xrange > > set xrange [ * : 10.0000 ] reverse nowriteback # (currently [10.0000:] ) > > AGAIN, PLOT IS AS EXPECTED BUT THE "currently" IS INCOMPLETE WHERE I > THINK IT SHOULD SAY "[10.0000:5.0000]". Dan, you are again showing tests with function plots. I keep pointing out that the x-axis autoscaling commands, including the * character in a "set xrange" command _do not apply_ to the samples generated for functions. I am pretty sure that whatever result you get is pure happenstance; it was not a deliberate design decision, and the use of * for function domains was never documented because its use was not intended. If you think there is a need to introduce a specific documented effect of "set xrange [min:*]" on a subsequent function plot - please make a proposal. Up to now that command has no documented meaning. Ethan |
From: sfeam (E. Merritt) <eam...@gm...> - 2012-09-11 03:33:51
|
On Monday, 10 September 2012, Hans-Bernhard Bröker wrote: > On 11.09.2012 00:34, Ethan A Merritt wrote: > > > You do know that the [*:*] part of that command is entirely ignored? > > As I said, autoscaling only applies to data plots, not function plots. > > For the independent axes of a function plot, yes. Not so much for the > dependent ones (y in a plot, z in an splot, all of them in a parametric > one). Yes, of course. So far the discussion has concerned the x-axis range in a 2D function plot (not polar, not parametric). The same issue arises for both x- and y- axes in a 3D plot, with the additional complication that in the past "set/unset view map" implicitly toggled their internal flag AXIS_REVERSE, thus making its eventual state even less understandable. > > I don't see it that way. To me it seems very intuitive. > > [30:50] means start at 30 and go to 50. > > [50:30] means start at 50 and go to 30. > > The word "reverse" is never needed when you are specifying explicit limits. > > But what about the cases where only half the limits are explicit? > > set yrange [30:*] reverse > > has been meaningful for quite a while now. Changing that should require > a pretty good reason. I may be missing a scenario, but so far as I know that command has exactly same effect in the current 4.7 as it had in earlier versions. It is an example of autoscaling. > > The `reverse` keyword was added sometime between versions 3.5 and 3.7 > > Its documentation has always said > > `reverse` is intended primarily for use with `autoscale` > > But that doesn't mean it should have no effect otherwise. Since the historical behavior has been strange, to say the least, I think we are free establish more reasonable behavior starting with the eventual release 5.0. It is my position that the "reverse" keyword should explicitly affect only autoscaling, even though the documentation has in the past only said this is "intended" rather than "guaranteed". > > Dan, you are again showing tests with function plots. > > I keep pointing out that the x-axis autoscaling commands, including the > > * character in a "set xrange" command _do not apply_ to the samples generated > > for functions. > > Which is only half true. > > It's true that auto-scaling an independent variable for a _pure_ > function plot makes no sense --- which is why gnuplot always replaced it > by a default range. But as soon as x becomes a dependent variable > (parametric mode, polar mode), or data files enter the picture, > auto-scaling x becomes well-defined and worth having. Sure. No one is disputing that. The specific issues that I take from this discussion are 1) How to fix the long-standing problem that the 'reverse' flag is set implicitly but can only be cleared explicitly, leading to context-dependent output from explict range commands? My solution is to ignore the reverse flag whenever foo and baz are both given, applying it only if the axis limits are chosen by autoscaling. That removes the context-dependence and is consistent with the previous "intended" use. 2) The plot produced by plot [30:40<*] x is very strange. Bug? Unreasonable command? In any case the issue has been present since the introduction of conditional range limits by Volker Dobler's patch 2 years ago. It's not related to "reverse". 3) The empty range plot produced by plot [10:*] x is unexpected, although understandable if you remember that the implicit upper axis limit is 10 by default. Bug? Unreasonable command? Should it do something else entirely? Again this is not directly related to "reverse". 4) Dan provided a test case that resulted in a blank entry in the "currently" field of "show range". I haven't looked into that one yet, but it appears to be a bug in the "show" command rather than a real problem with the plot or autoscaling. |
From: Daniel J S. <dan...@ie...> - 2012-09-11 06:56:23
|
On 09/10/2012 10:33 PM, sfeam (Ethan Merritt) wrote: > Since the historical behavior has been strange, to say the least, > I think we are free establish more reasonable behavior starting > with the eventual release 5.0. It is my position that the "reverse" > keyword should explicitly affect only autoscaling, even though the > documentation has in the past only said this is "intended" rather > than "guaranteed". Something that could have been done instead of the "reverse" option is to have put control for orientation within the autoscaling syntax, e.g., [*:-*] just as with the non-auto-adjust. It seems that has become overloaded anyway with specifiers like [30:40<*]. Whether that is better in the long run, not sure. That means there can't be multiple xranges in a plot command unless the all result in the same orientation. > 4) Dan provided a test case that resulted in a blank entry in the > "currently" field of "show range". I haven't looked into that > one yet, but it appears to be a bug in the "show" command > rather than a real problem with the plot or autoscaling. I see that the field is blank before even doing the plot, so yes probably a "show" issue... I will look into the 'writeback' option as well. Dan |
From: Daniel J S. <dan...@ie...> - 2012-09-11 00:02:13
|
On 09/10/2012 05:34 PM, Ethan A Merritt wrote: > On Monday, September 10, 2012 01:16:41 pm Daniel J Sebald wrote: >>> <aside> >>> As you probably recall, my opinion is that a range specifier in the plot >>> command is always a bad idea. If it were just me, I'd remove that option >>> altogether. The only reason I can see to allow it is if it is changed so >>> that the in-line range applies only to the immediately following plot clause. >>> That way you could get separate ranges for separate plots: >>> plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) >>> I don't really like that either, but at least it would provide a >>> capability that isn't addressed by simply doing "set xrange" first. >>> </aside> >> >> Yes, I sort of agree with that. That is why I picked the phrasing that >> the range is associated with the data, not the orientation of the axis. >> Given the example you wrote, the paradigm is that [10:20] means the >> data for which x is between 10 and 20, and in that case [20:10] is no >> different than [10:20]. Using the range specifier to control the >> orientation of the plot in your example would be a mess. > > The way I view it is that "set xrange [FOO:BAZ]" means the left > end of the axis is pinned at FOO and the right end is pinned at BAZ. > The makes sense both externally (what the user sees) and internally > (mapping a numerical coordinate onto a screen position). > > I will note that my primary motivation for the change in 4.7 was to clean > up the code internally. The fact that it also IMHO makes a more sensible > user-visible syntax is just a side benefit. The change removed a > tangle of calls and macros like check_axis_reversed(), CHECK_REVERSE, > AXIS_ACTUAL_MIN, etc, and made it a lot easier to implement linked > primary/secondary axes. It also fixed corruption in the zoom/restore > state if the AXIS_REVERSE flag somehow got set while a plot was zoomed. That's good. There's a natural complexity to these sorts of things and controlling the range doesn't seem like it should be so complex. >> Anyway, the most affect on backward compatibility is >> ["reverse" only applies to the autoadjust settings] >> so I'm wondering why that change is preferred. > > The `reverse` keyword was added sometime between versions 3.5 and 3.7 > Its documentation has always said > `reverse` is intended primarily for use with `autoscale` Oh, then that was a bug when released. The "NB: This is a change introduced in version 4.7." comment in the xrange documentation suggests the old behavior was intentional. I have the fix for Octave ready to go then. > Dan, you are again showing tests with function plots. > I keep pointing out that the x-axis autoscaling commands, including the > * character in a "set xrange" command _do not apply_ to the samples generated > for functions. I am pretty sure that whatever result you get is pure > happenstance; it was not a deliberate design decision, and the use of * for > function domains was never documented because its use was not intended. I included the function x so that it illustrates the data points passing through the line and that things are working properly. Try without the function x and it is the same result. I'll do this with a bit more detail, and I will use 9 as a lower limit so as to rule out some strange conflict between the [-10:10] of the default range: G N U P L O T Version 4.7 patchlevel 0 last modified 2012-06-19 Build System: Linux x86_64 Copyright (C) 1986-1993, 1998, 2004, 2007-2012 Thomas Williams, Colin Kelley and many others gnuplot home: http://www.gnuplot.info mailing list: gnu...@li... faq, bugs, etc: type "help FAQ" immediate help: type "help" (plot window: hit 'h') Terminal type set to 'qt' gnuplot> show xrange set xrange [ * : * ] noreverse nowriteback # (currently [-10.0000:10.0000] ) gnuplot> set xrange [9:*] gnuplot> show xrange set xrange [ 9.00000 : * ] noreverse nowriteback # (currently [:10.0000] ) gnuplot> plot '-' input data ('e' ends) > 5 5 input data ('e' ends) > 8 8 input data ('e' ends) > 12 12 input data ('e' ends) > 15 15 input data ('e' ends) > e gnuplot> show xrange set xrange [ 9.00000 : * ] noreverse nowriteback # (currently [:15.0000] ) My plot is showing the xaxis starting at 9 and ending at 15. Shouldn't that be saying "currently [9.0000:15.0000]", because that is currently what the range is on the plot? Dan |
From: Tait <gnu...@t4...> - 2012-09-11 03:52:52
|
> >>> <aside> > >>> As you probably recall, my opinion is that a range specifier in the plot > >>> command is always a bad idea. If it were just me, I'd remove that option > >>> altogether. The only reason I can see to allow it is if it is changed so > >>> that the in-line range applies only to the immediately following plot clause. > >>> That way you could get separate ranges for separate plots: > >>> plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) > >>> I don't really like that either, but at least it would provide a > >>> capability that isn't addressed by simply doing "set xrange" first. > >>> </aside> > >> > >> Yes, I sort of agree with that. That is why I picked the phrasing that > >> the range is associated with the data, not the orientation of the axis. > >> Given the example you wrote, the paradigm is that [10:20] means the > >> data for which x is between 10 and 20, and in that case [20:10] is no > >> different than [10:20]. Using the range specifier to control the > >> orientation of the plot in your example would be a mess. I like the idea of separating axis range from (data/function) plot range. It's a somewhat frequently-asked question how to use a different range for a function than what is used for the axis, and the current solution -- to use a ternary -- isn't especially elegant. As suggested, it would then become natural to allow "set xrange reversed" by itself. > gnuplot> set xrange [9:*] > gnuplot> show xrange > > set xrange [ 9.00000 : * ] noreverse nowriteback # (currently [:10.0000] ) > > gnuplot> plot '-' > input data ('e' ends) > 5 5 > input data ('e' ends) > 8 8 > input data ('e' ends) > 12 12 > input data ('e' ends) > 15 15 > input data ('e' ends) > e > gnuplot> show xrange > > set xrange [ 9.00000 : * ] noreverse nowriteback # (currently [:15.0000] ) > > > My plot is showing the xaxis starting at 9 and ending at 15. Shouldn't > that be saying "currently [9.0000:15.0000]", because that is currently > what the range is on the plot? What you're asking about is GPVAL_X_MAX, which is not the same as the xrange. If you were to continue by plotting another data set that extended to 22, then you would rightly expect to (and gnuplot would) scale to the new x-max of 22. The possibility to have the autoscale performed only on the first plot, then locked into place is supported by the "writeback" option. I don't normally use writeback, but in trying it just now, it appears to be broken. Both "set xrange [9:*] writeback" and "set xrange [*:*] writeback" followed by the plot above fail to write the range back as they should. It's left auto-scaled. (And if we support "set xrange [no]reverse" we should likewise support "set xrange [no]writeback".) |
From: sfeam (E. Merritt) <eam...@gm...> - 2012-11-18 04:13:31
|
On Monday, 10 September 2012, Tait <gnu...@t4...> wrote: > > "sfeam (Ethan Merritt)" <sf...@us...> > > >>> <aside> > > >>> As you probably recall, my opinion is that a range specifier in the plot > > >>> command is always a bad idea. If it were just me, I'd remove that option > > >>> altogether. The only reason I can see to allow it is if it is changed so > > >>> that the in-line range applies only to the immediately following plot clause. > > >>> That way you could get separate ranges for separate plots: > > >>> plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x) > > >>> I don't really like that either, but at least it would provide a > > >>> capability that isn't addressed by simply doing "set xrange" first. > > >>> </aside> > I like the idea of separating axis range from (data/function) plot range. > It's a somewhat frequently-asked question how to use a different range for > a function than what is used for the axis, and the current solution -- to > use a ternary -- isn't especially elegant. I've put a patchset on SourceForge that implements this idea. https://sourceforge.net/tracker/?func=detail&aid=3587664&group_id=2055&atid=302055 Its documentation says: + By default, computed functions or data generated for the pseudo-file "+" are + sampled over the entire range of the plot. This range may have been specified + by a prior `set xrange` command, by an explicit global range specifier at the + very start of the plot command, or by autoscaling of the range to span data + seen in all the elements of this plot command. However, individual plot + elements can be assigned a more restricted sampling range. + + Examples: + + This establishes a total range on x running from 0 to 1000 and then plots + data from a file and two functions each spanning a portion of the total range: + plot [0:1000] 'datafile', [0:200] func1(x), [200:500] func2(x) + + This is similar except that the total range is established by the contents + of the data file. In this case the sampled functions may or may not be + entirely contained in the plot: + set autoscale x + plot 'datafile', [0:200] func1(x), [200:500] func2(x) + + This command is ambiguous. The initial range will be interpreted as applying to + the entire plot, not solely to the sampling of the first function as was + probably the intent: + plot [0:10] f(x), [10:20] g(x), [20:30] h(x) + + This command removes the ambiguity of the previous example by inserting a dummy + definition so that the range is not the first element of the plot command: + plot dummy=0, [0:10] f(x), [10:20] g(x), [20:30] h(x) |