From graphics-request at octave dot org Tue Aug 10 12:13:50 2004 Subject: Re: freqz_plot alterations From: Daniel J Sebald To: graphics at octave dot org Date: Tue, 10 Aug 2004 12:37:44 -0500 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: > >> pkienzle at comcast dot net 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 ''" >> 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/