Re: freqz_plot alterations

I've been attempting to spruce up the freqz plots.  Regardless of those 
changes, I offer up the suggestion of tweaking the freqz/freqz_plot 
files.  The issue is that inside of the freqz_plot script, the command

      axis ([ w(1), w(n) ]);

results in the range being forced so that the right border is not a nice 
whole number in any case.  That is, w(n) is always something like 
1023/512 or 1.9980.  The consequence is that it causes (or reveals) a 
small problem with tics and grid lines in gnuplot.  Even when that is 
appropriately fixed, the tic at Fs/2 will not show.

I see that freqz_plot.m does not have the sample rate passed into it, so 
I suggest that right before calling freqz_plot.m within freqz.m, the command

    axis ([ 0, Fs/2 ]);

Then, inside freqz_plot.m, drop the occurance of

      axis ([ w(1), w(n) ]);

and change

      axis ([ w(1), w(n), maxmag-3, maxmag ]);

to

      a = axis;
      axis ([ a(1), a(n), maxmag-3, maxmag ]);

Anyone have thoughts on that?

Dan


PS:  Not a big deal, but it seems a bit peculiar that issuing the 
following would turn axes back to autoscaling:

octave:25> a = axis()
a =

  0  2  0  50




-------------

Paul Kienzle wrote:

> On Aug 6, 2004, at 5:51 PM, Daniel J Sebald wrote:
>
>> [email protected] wrote:
>>
>>> I don't know if it is feasible to drop just the top and bottom 
>>> y-labels without taking control over all labels and grids.  Every 
>>> bit of increased vertical space makes the graph more useful, unless 
>>> of course it becomes confusing.
>>
>>
>> Not sure what you mean.
>
>
> If there is no space between plots the tic labels at the bottom of one 
> plot overlap with those of the top of the next.  I don't know how to 
> suppress this without taking complete control of all labels.
>
> The reason you don't want any space between graphs is to maximize the 
> amount of space on each graph, much like you showed in your .png file.
>
>>
>>> Again, I'm not complaining.  After all, I left the gset margin 
>>> commands in there in the first place.  Still, it would be nice if 
>>> you could find a way to produce this plot without resorting to 
>>> gnuplot primitives.
>>
>>
>> The "subplot (corners)" feature is the way to go.  The gnuplot 
>> primitives would be in there.
>
>
> Yes that's what I'm talking about.  I'm not sure if you also need a 
> wrapper around the margins commands, or if they would go in the 
> subplot command or what.
>
>>
>>> It would be even nicer if you could do it in such a way that the 
>>> next plot doesn't carry the same properties.  I tried that with the 
>>> unwind_protect_cleanup section at the end of the code, but the new 
>>> automatic_replot default makes a mockery of this.  It wasn't the 
>>> correct thing to do anyway.  Better would be to modify pt-plot so 
>>> that if clear_before_plotting is true it resets and reinitializes 
>>> gnuplot then proceeds to plot.  This would help for commands like 
>>> text, tics, grid, the quiver plot, etc.  Oops... can't do that 
>>> because it will break all the code in which titles precede the plot 
>>> like we had to do in old octave.  This is not something to take on 
>>> in your freqz patches, so ignore this paragraph.
>>>
>>
>> If it is a few "gset" that are done, there is the possibility of 
>> first doing a "gshow", interpret and store that information, generate 
>> the plot, and then "gset" back to the state before the plot.
>
>
> The problem is more difficult than that.  Before the next plot you 
> want to clear a bunch of stuff that you set, but maybe not all.  I'm 
> not sure for example if grid is reset between every plot in matlab or 
> if it carries on between the plots.   Ideally these resets would 
> happen automatically with the next plot command.  Before I was able to 
> fake it by resetting the options that I changed.  Without 
> automatic_replot, these wouldn't appear until the user gave the next 
> plot command.  Now with automatic_replot they happen immediately.  
> It's a problem.  It's even more of a problem because clg doesn't fix 
> things.  Maybe the solution is to require a clf between plots in 
> octave.  That way code will work correctly in both octave and matlab, 
> assuming clf resets everything. (This may need to be fixed in 
> octave-forge.  Currently it is resetting to gnuplot defaults, which is 
> plot with points rather than plot with lines.)
>
>> Another alternative is that gnuplot has a "save set '<filename>'" 
>> command that will store all settable settings.  That file can then be 
>> reloaded after plotting operations.  Of course, multiplots and the 
>> settings for that is an issue because only the most recent plot 
>> (i.e., subplot) is stored.  The gnuploters all know this, but that is 
>> one of those back-burner things.
>
>
> Again, the problem is how to trigger this in a matlab compatible way 
> without breaking octave code and without thrashing on gnuplot.  
> Queueing the commands until the plot is flushed or until the program 
> spends half a second in the read-eval-print loop since the last 
> gnuplot command, then reordering commands so that plot and replot are 
> last will alleviate the gnuplot thrashing.  Going to matlab-style 
> plots where title, etc. follows rather than precedes the plot will be 
> more brutal.   Maybe the solution is to have the queued automatic 
> replot always on, but have a flag for resetting before plot or after.
>
> This is more work than you want to do for the freqz patches, though 
> you may want to anticipate the matlab-style by removing the plot 
> restore commands from the end, and a comment on the freqz docs that 
> you will need to enter a clf command before the next plot to reset the 
> axes.
>
> - Paul
>
> PS, this discussion should be on-list so others can comment.
>
>
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/