Re: irreversibly reversing range

[Ethan A M. <sf...@us...>]

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