Re: irreversibly reversing range

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

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