Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 20:53:13
|
> - There should be some way to turn off the quick refresh if you really do
> want to re-read the data during a zoom operation. Maybe a new command
> set zoom {replot|refresh}
> or
> set mouse zoom {replot|refresh}
If this is a necessary option, I might prefer this to be an option for the
replot command, i.e., "set datafile reread/noreread" or something like that.
To have a "refresh" command and then have "refresh" an option somewhere is
getting along the lines of the "hidden3d" and "pm3d hidden3d" option confusion.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 21:23:47
|
On Monday 04 June 2007 13:53, Daniel J Sebald wrote:
> > - There should be some way to turn off the quick refresh if you really do
> > want to re-read the data during a zoom operation. Maybe a new command
> > set mouse zoom {replot|refresh}
>
> If this is a necessary option, I might prefer this to be an option for the
> replot command, i.e., "set datafile reread/noreread" or something like that.
It's not tied to a datafile, so that doesn't work.
> To have a "refresh" command and then have "refresh" an option somewhere is
> getting along the lines of the "hidden3d" and "pm3d hidden3d" option confusion.
Huh? What option?
There would be two commands. I am not wedded to calling the new one "refresh",
but let's go with that for the moment.
replot = re-read the data and plot all over again
refresh = don't reread the data, but update the plot with new limits+labels+etc
If you're typing from the command line, no problem.
You just pick whichever of the two commands you want.
The issue is what happens under the hood when a mouse operation,
in particular zooming, needs to redraw the plot.
Does it use "refresh" or does it use "replot"?
You've got to be able to tell it that somehow, and that's kind of
hard to do without mention the name of the command you want it to use.
--
Ethan A Merritt
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 21:45:17
|
Ethan Merritt wrote: >>To have a "refresh" command and then have "refresh" an option somewhere is >>getting along the lines of the "hidden3d" and "pm3d hidden3d" option confusion. > > > Huh? What option? > > There would be two commands. I am not wedded to calling the new one "refresh", > but let's go with that for the moment. > replot = re-read the data and plot all over again > refresh = don't reread the data, but update the plot with new limits+labels+etc Fine for now. I'm not strongly pitching "set datafile reread". I'm simply wondering how users might like this oft-used command. Would some be happier to set an option and have "replot" to mean reread the data and all. E.g., Octave users have asked for gnuplot to simply reread data. No mention of an alternate command. I guess it is a question of both "replot" and "refresh" commonly used to go back and forth, or simply be in one mode and stay that way. > If you're typing from the command line, no problem. > You just pick whichever of the two commands you want. > The issue is what happens under the hood when a mouse operation, > in particular zooming, needs to redraw the plot. > Does it use "refresh" or does it use "replot"? > You've got to be able to tell it that somehow, and that's kind of > hard to do without mention the name of the command you want it to use. "set datafile reread/noreread" would accomplish the same thing. (I'm considering '-' a datafile (in-line).) No strong feelings either way, just kind of tossing the alternatives around... Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-04 21:54:13
|
On Monday 04 June 2007 14:45, you wrote: > > You've got to be able to tell it that somehow, and that's kind of > > hard to do without mention the name of the command you want it to use. > > "set datafile reread/noreread" would accomplish the same thing. (I'm > considering '-' a datafile (in-line).) But that makes it seem like it's a property of the data file [*]. It isn't. It's a question of mouse interactions and hot keys. That's why I suggested "set mouse ..." Actually, I'd much rather have a mechanism that *was* tied to specific data files. That way you could mark a particular data file as volatile, or not re-readable. That would free me from having to make this quick refresh mode work for all possible mixtures of plots simultaneously, which is a headache. But so far I have not figured out a way to do that. The decision is made at a higher level: either we re-parse and re-execute the plot command line, re-reading files as we go, or we skip that whole operation and go with what's already in the plot data structures. It's all or none. [*] In fact it works the same way for functions, although that's an unintended side-effect. -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-06-04 21:57:54
|
Ethan Merritt wrote: > On Monday 04 June 2007 14:45, you wrote: > >>>You've got to be able to tell it that somehow, and that's kind of >>>hard to do without mention the name of the command you want it to use. >> >>"set datafile reread/noreread" would accomplish the same thing. (I'm >>considering '-' a datafile (in-line).) > > > But that makes it seem like it's a property of the data file [*]. > It isn't. It's a question of mouse interactions and hot keys. > That's why I suggested "set mouse ..." > > Actually, I'd much rather have a mechanism that *was* tied to > specific data files. That way you could mark a particular > data file as volatile, or not re-readable. I too thought of individual file behavior, but I then thought that would only complicate matters but that may be an incorrect assumption. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-28 20:10:24
|
On Thursday 28 June 2007 12:56, Daniel J Sebald wrote: > > > Dan: <<I think it doesn't get us in the direction we want to go, which is > > to eventually store the data, all of it, and then just reuse it in whatever > > way we see fit.>> > > > > Please give a concise example of what you mean. How would it be different > > from what we are already doing? What part of "all of it" are we failing to > > store? > > > Let me illustrate the difference by discussing the drawbacks of this macro: > > #define STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, TYPE, AXIS, \ > OUT_ACTION, UNDEF_ACTION) \ > ... > > There is too much going on there. > Here is the problem with doing the range adjustment and logarithm upfront. > 1) The logarithm is especially egregious. I think everybody agrees on this. At least, I don't recall hearing a dissenting opinion. My request was simply that you leave the existing log scale code in place until a general mechanism was ready to replace it. But that's not an issue of failing to store input data; it's an issue of whether you apply axis scaling upon input or wait until later. I thought maybe you were proposing that the keyword "every", for example, should be ignored during input and only applied later on. That would be a bad idea IMHO because the whole purpose may be to avoid input of the entirety of absurdly large data files. > You may ask Why run the generated function data through preparation? The CVS code can already do this. See "help datafile special" for a description of the '+' pseudofile. -- Ethan A Merritt |
|
From: James R. V. Z. <jr...@co...> - 2007-07-27 02:17:44
|
Ethan Merritt wrote:
> But that's not an issue of failing to store input data; it's an
> issue of whether you apply axis scaling upon input or wait until
> later.
Currently the data are scaled and replaced. That means if the user
reverts to linear scaling, the data has to be unscaled. Any
nonpositive data points will have been lost. It also means we need an
"unscale" function. The probability scaling in my patch uses the same
kind of implementation.
I would like to implement general scaling by a user-defined function,
and would rather not force the user to supply its inverse too. We
could do that with "just in time scaling" - i.e. store the data as
read in from the file, and apply scaling immediately before
calculating screen positions. If we agree that's the way to go, then
it makes sense to make that change before applying [a version of] my
axis scaling patch.
- Jim Van Zandt
|
|
From: Daniel J S. <dan...@ie...> - 2007-06-28 19:56:17
|
I've re-enabled for a discussion on the quick refresh...
> Dan: <<I think it doesn't get us in the direction we want to go, which is
> to eventually store the data, all of it, and then just reuse it in whatever
> way we see fit.>>
>
> Please give a concise example of what you mean. How would it be different
> from what we are already doing? What part of "all of it" are we failing to
> store?
>
> Let's spin off discussion of axis scaling to the mailing list. It's only
> marginally relevant to the issue of refresh vs replot.
>
Let me illustrate the difference by discussing the drawbacks of this macro:
#define STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, TYPE, AXIS, \
OUT_ACTION, UNDEF_ACTION) \
do { \
/* HBB 20000726: new check, to avoid crashes with axis index -1 */ \
if (AXIS==-1) \
break; \
/* HBB 20040304: new check to avoid storing infinities and NaNs */ \
if (! (VALUE > -VERYLARGE && VALUE < VERYLARGE)) { \
TYPE = UNDEFINED; \
UNDEF_ACTION; \
break; \
} \
if (axis_array[AXIS].log) { \
if (VALUE<0.0) { \
TYPE = UNDEFINED; \
UNDEF_ACTION; \
break; \
} else if (VALUE == 0.0) { \
STORE = -VERYLARGE; \
TYPE = OUTRANGE; \
OUT_ACTION; \
break; \
} else { \
STORE = AXIS_DO_LOG(AXIS,VALUE); \
} \
} else \
STORE = VALUE; \
if (TYPE != INRANGE) \
break; /* don't set y range if x is outrange, for example */ \
if ((int)AXIS < 0) \
break; /* HBB 20000507: don't check range if not a coordinate */ \
if ( VALUE<axis_array[AXIS].min ) { \
if (axis_array[AXIS].autoscale & AUTOSCALE_MIN) \
axis_array[AXIS].min = VALUE; \
else { \
TYPE = OUTRANGE; \
OUT_ACTION; \
break; \
} \
} \
if ( VALUE>axis_array[AXIS].max ) { \
if (axis_array[AXIS].autoscale & AUTOSCALE_MAX) \
axis_array[AXIS].max = VALUE; \
else { \
TYPE = OUTRANGE; \
OUT_ACTION; \
} \
} \
} while(0)
There is too much going on there. What I'm working on changes this to simply
#define STORE_VALUE(STORE, VALUE, TYPE, AXIS) \
do { \
/* HBB 20000726: new check, to avoid crashes with axis index -1 */ \
if (AXIS==-1) \
break; \
/* HBB 20040304: new check to avoid storing infinities and NaNs */ \
if (! (VALUE > -VERYLARGE && VALUE < VERYLARGE)) { \
TYPE = UNDEFINED; \
break; \
} \
STORE = VALUE; \
} while(0)
Here is the problem with doing the range adjustment and logarithm upfront.
1) The logarithm is especially egregious. Notice that if log scale axis is active, the cases of (VALUE<0.0) and (VALUE == 0.0) do not store the data. The log is monotonic and one-to-one only for positive real numbers. So if one does
unset logscale x
refresh
the refresh will not work. Some of the user's data may have been lost. That's unreliable. So that is why I say we should just store the data without and translation; that way we will always have the original data. The translations can be done when needed, and having the extra UNDEFINEDs in the data doesn't seem to effect the results. In fact, not translating seems to simplify things in other places. There are other potential limitations to hinder development. The Bragg reflection example in mgr.dem might be another.
plot "big_peak.dat" title "Rate" with errorbars, \
"" smooth csplines t "Rate"
Looking at the code, the csplines will change the data in the plot structure. One can't refresh this plot too easily, I don't think.
2) Doing the update range right away isn't so bad. Patch [ gnuplot-Patches-1723715 ] has a compact routine to recompute the ranges. Compact routines are good, but having two methods of updating ranges is a problem. One has to make sure that if either is changed, so is the other. I'd prefer just a single routine than one for plot/replot and one for refresh. With that in mind I've organized the range checking code as follows:
/* Various preparations on data, without actually modifying the data. */
static void
prepare_data(struct curve_points *cp)
{
int i;
/* Go through all the points classifying according to the
* logarithmic scale and sign of data.
*/
for (i = 0; i < cp->p_count; ++i) {
switch (cp->plot_style) {
/* Only x and y are relevant to axis scaling */
default:
int_warn(NO_CARET, "Missing style %d in switch statement", cp->plot_style);
case LINES:
case POINTSTYLE:
case IMPULSES:
case LINESPOINTS:
case DOTS:
case FILLEDCURVES:
#ifdef EAM_DATASTRINGS
case LABELPOINTS:
#endif
axis_update_range(cp->x_axis, cp->points[i].x, &cp->points[i].type);
axis_update_range(cp->y_axis, cp->points[i].y, &cp->points[i].type);
break;
case XERRORBARS:
case BOXES:
case XERRORLINES:
axis_update_range(cp->x_axis, cp->points[i].xlow, &cp->points[i].type);
axis_update_range(cp->x_axis, cp->points[i].xhigh, &cp->points[i].type);
axis_update_range(cp->y_axis, cp->points[i].y, &cp->points[i].type);
break;
case YERRORBARS:
case CANDLESTICKS:
case FINANCEBARS:
case YERRORLINES:
axis_update_range(cp->x_axis, cp->points[i].x, &cp->points[i].type);
axis_update_range(cp->y_axis, cp->points[i].ylow, &cp->points[i].type);
axis_update_range(cp->y_axis, cp->points[i].yhigh, &cp->points[i].type);
break;
case XYERRORBARS:
case BOXXYERROR:
case BOXERROR:
case VECTOR:
case XYERRORLINES:
#ifdef EAM_HISTOGRAMS
case HISTOGRAMS:
#endif
axis_update_range(cp->x_axis, cp->points[i].xlow, &cp->points[i].type);
axis_update_range(cp->x_axis, cp->points[i].xhigh, &cp->points[i].type);
axis_update_range(cp->y_axis, cp->points[i].ylow, &cp->points[i].type);
axis_update_range(cp->y_axis, cp->points[i].yhigh, &cp->points[i].type);
break;
#ifdef WITH_IMAGE
case IMAGE:
case RGBIMAGE:
/* Size of pixels determined by spacing of grid. Do nothing here, but
* after all data collected then update the range. */
break;
#endif
}
#ifdef EAM_HISTOGRAMS
/* Fiddle the auto-scaling data for histograms */
if (cp->plot_style == HISTOGRAMS)
histogram_update_range(cp);
#endif /* EAM_HISTOGRAMS */
#ifdef WITH_IMAGE
if (cp->plot_style == IMAGE || cp->plot_style == RGBIMAGE) {
/* Images are defined by a grid representing centers of pixels.
* Compensate for extent of the image so `set autoscale fix`
* uses outer edges of outer pixels in axes adjustment.
*/
cp->image_properties.type = IC_PALETTE;
plot_image_or_update_axes(cp, TRUE);
}
#endif
}
}
Notice how the above has organized updates for individual points, then groups of points afterward when all data is collected (histogram_update_range was fiddle_histograms).
OK, in brief, here's what I've worked toward (and should post soon), but it doesn't have refresh, just organizes things better, I think.
datafiles
|
| ("plot"/"replot")
|
V
raw_stored_data <--- ("refresh")
|
| (splines perhaps)
|
V
preprocessed_data ----------------> onplot
|
| (prepare_data())
|
V
ranges_for_data
|
| (parameterize routine)
|
V
function_data -------------------> onplot
|
| (prepare_data())
|
V
ranges_for_functions
You may ask Why run the generated function data through preparation? Because I'm wondering if we should have gnuplot not give a message like this
gnuplot> set logscale x
gnuplot> plot x
x range must be greater than 0 for log scale
and simply do the best it can if there is non-positive data. The data from [-10:0] of default [-10:10] could be ignored... or in this case we could choose the default to be [1:10] in the case of logscale.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2007-07-01 23:41:16
|
The following is confusing to me:
" The `volatile` keyword indicates that the contents of the data file may be
different if the file is re-read. This tells the program to use `refresh`
rather than `replot` commands whenever possible. See `refresh`."
I assume "tells the program" means "tells gnuplot". But beyond that, the interpretation of this is more left to the user. OK, "volatile" is clear. But for one user it may be desired that the volatile files be reread with every new "replot", for another user it may be desired that the volatile files not be reread. In other words "volatile" is an accurate word, but implication is somewhat ambiguous.
The other thing I don't like is the "whenever possible". I've been trying to make the point that unless there is precise behavior for this feature the "whenever possible" is going to make the user or programmer give up in futility because he or she won't know when datafiles are actually reread. "Not when log/unlog via mouse or set", "not when there are splines", "not for this condition", etc. And there is no documentation about any of this. It's a guessing game.
I'd say drop the "volatile" keyword. Then two methods are acceptable. One, there are two commands "replot/refresh" in which "replot" *always* rereads files and "refresh" *always* retrieves the data from memory. That way there is no ambiguity and any operation is left to the user's intention. Two, a mode option for replot say
set replot {reread:noreread}
Again, in "reread" mode "replot" always behaves one way. In "noreread" mode "replot" always behaves another way.
Then also make the definition that the mouse zoom/unzoom and mouse log/unlog always uses the "refresh" method and never rereads data files.
As for the patch, evaluating it makes me more stalwart on the notion that "refresh" data has to be fed into the system near the start of "get_data()" and fed through the whole system for reprocessing. There can't be an ancillary hunk of code that duplicates some operation that is within "get_data()" and then circumvent other aspects of "get_data()" going directly to "eval_plots()". That's difficult to follow from a programmer's perspective and some day a new programmer will alter something in one place and not realize something must be changed in another place.
Again, I want to point out the factual content of the v's and j's that come from df_readline(). There are only MAXDATACOLS, which is seven (plus 1 for j). That is the equivalent of a "point". I don't see the storage of the v's and j's being any worse than storing the points. In fact, after knowing the maximum j, we can narrow the width of any records of the v's and j's to save space. Furthermore, in some and maybe all circumstances the "points" array could be discarded after the plot is done if we retain the v's and j's. The mouse zoom/unzoom, mouse log/unlog, mouse rotation in 3D are all something that could be redone with the "refresh" mode of operation. Tapping into df_readline seems the way to go, to me.
As for the "strings", those are already saved in the plot structure so they are readily available. There is a little problem in the sense that cp->labels storage keeps track of a pointer to an element of cp->points. Would have to figure out something there. Could tag the label not with the ->point but with the v/j combo and feed that too back through the system from the point of df_readline.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-07-02 01:12:06
|
On Sunday 01 July 2007 16:41, Daniel J Sebald wrote: > The following is confusing to me: > > " The `volatile` keyword indicates that the contents of the data file > may be different if the file is re-read. This tells the program to > use `refresh` rather than `replot` commands whenever possible. > > I assume "tells the program" means "tells gnuplot". But beyond that, the interpretation of this is more left to the user. OK, "volatile" is clear. But for one user it may be desired that the volatile files be reread with every new "replot", for another user it may be desired that the volatile files not be reread. Exactly. That's why they get a choice of whether to use the keyword or not. If you know the data may change, but you want to zoom and play aroung with the the existing plot without reading in new data, then you plot it with "volatile". This tells gnuplot to keep using the old data rather than reading in new data. If you want to update the display with the newest available data every time you hit the 'e' key, then you *don't* flag it volatile. Hmmm, yes I see that could be a bit confusing. I'll ponder a better way to describe it. > In other words "volatile" is an accurate word, but implication is somewhat ambiguous. Feel free to suggest better wording, or even a different keyword. The basic point is to provide a way to say "reread every time" vs. "reread only when there's no other option". > The other thing I don't like is the "whenever possible". I've been trying to make the point that unless there is precise behavior for this feature the "whenever possible" is going to make the user or programmer give up in futility because he or she won't know when datafiles are actually reread. "Not when log/unlog via mouse or set", "not when there are splines", "not for this condition", etc. "The perfect is the enemy of the good". For the last 20 years gnuplot has not allowed you to zoom volatile data. Mostly it's been a minor annoyance. Now there's a reason to support it, since Octave sends data in-line. But you are taking the extreme position that a patch to fix this is no good unless it also re-works log/unlog axis rescaling. I just don't get it. I'm perfectly happy to see the axis scaling cleaned up. But it's an orthogonal issue. Besides which, in all the years that I've used gnuplot (less then 20 but more than 10 :-) I've never wanted to toggle log scale with a hot key. Is this really so important to you? > I'd say drop the "volatile" keyword. Then two methods are acceptable. > One, there are two commands "replot/refresh" in which "replot" *always* > rereads files and "refresh" *always* retrieves the data from memory. That is exactly what I implemented. If you have found a case in which it doesn't act this way, please report it as a bug. The "volatile" keyword does not affect this. Perhaps my documentation and description is inadequate, since you seem to misunderstand what the patch actually does. I welcome your help in improving the documentation, but I do not agree with you that the log/unlog business is particularly relevant. It's a footnote at best: "Please note that the 'l' and 'L' hotkeys are disabled if the plot contains in-line or volatile data". -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-07-02 05:12:01
|
> I've used gnuplot (less then 20 but more than 10 :-) I've never > wanted to toggle log scale with a hot key. Is this really so > important to you? I use it daily, really. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2007-06-28 21:32:27
|
Ethan Merritt wrote: > On Thursday 28 June 2007 12:56, Daniel J Sebald wrote: > >>>Dan: <<I think it doesn't get us in the direction we want to go, which is >>>to eventually store the data, all of it, and then just reuse it in whatever >>>way we see fit.>> >>> >>>Please give a concise example of what you mean. How would it be different >>>from what we are already doing? What part of "all of it" are we failing to >>>store? >>> >> >>Let me illustrate the difference by discussing the drawbacks of this macro: >> >>#define STORE_WITH_LOG_AND_UPDATE_RANGE(STORE, VALUE, TYPE, AXIS, \ >> OUT_ACTION, UNDEF_ACTION) \ >>... >> >>There is too much going on there. >>Here is the problem with doing the range adjustment and logarithm upfront. >>1) The logarithm is especially egregious. > > > I think everybody agrees on this. At least, I don't recall hearing a > dissenting opinion. My request was simply that you leave the existing > log scale code in place until a general mechanism was ready to replace it. What do you mean by general? Able to apply mappings other than log scale? (I'm sure there are some I can't think of right now. > But that's not an issue of failing to store input data; it's an issue of > whether you apply axis scaling upon input or wait until later. It is. Wait for later. With the log scale, STORE_... currently tosses data: set logscale x plot "foo" with points unset logscale x refresh will not have all the data that was in the data file "foo". I argue it should. > I thought maybe you were proposing that the keyword "every", for example, > should be ignored during input and only applied later on. That would be > a bad idea IMHO because the whole purpose may be to avoid input of > the entirety of absurdly large data files. That's not what I meant. Just the records the user says to bring into gnuplot. If the user discards something intentionally, that's different. >>You may ask Why run the generated function data through preparation? > > > The CVS code can already do this. > See "help datafile special" for a description of the '+' pseudofile. OK, I'm not familiar with that. I'll look more closely. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-28 21:54:19
|
On Thursday 28 June 2007 14:32, Daniel J Sebald wrote: > Ethan Merritt wrote: > > > > My request was simply that you leave the existing > > log scale code in place until a general mechanism was ready to replace it. > > What do you mean by general? Able to apply mappings other than log scale? Exactly. I gave a bunch of examples earlier. The most common request (and hardest to work around) is marking off the X-axis as 1/x. For instance, we crystallographers have to deal with inconsistent usage all the time; some quantities are given in terms of energy while others are given in terms of wavelength. There is an inverse relationship: Energy = k / Wavelength where k is an appropriate constant. It is a pain to try to persuade gnuplot to mark off both Energy and Wavelength on axes of the same plot. I would like to be able to do something like: set axis x1 x # will use for Energy set axis x2 k/x # will use for Wavelength set axis y1 log(y) # log scale value to be plotted Even better if there is a way to automatically lock x1 to x2, so that they are forced to span the same range. -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-06-28 22:18:22
|
Ethan Merritt wrote: > On Thursday 28 June 2007 14:32, Daniel J Sebald wrote: > >>Ethan Merritt wrote: >> >>>My request was simply that you leave the existing >>>log scale code in place until a general mechanism was ready to replace it. >> >>What do you mean by general? Able to apply mappings other than log scale? > > > Exactly. I gave a bunch of examples earlier. > The most common request (and hardest to work around) is marking off the > X-axis as 1/x. For instance, we crystallographers have to deal with > inconsistent usage all the time; some quantities are given in terms of > energy while others are given in terms of wavelength. There is an > inverse relationship: > Energy = k / Wavelength > where k is an appropriate constant. It is a pain to try to persuade > gnuplot to mark off both Energy and Wavelength on axes of the same plot. > > I would like to be able to do something like: > > set axis x1 x # will use for Energy > set axis x2 k/x # will use for Wavelength > set axis y1 log(y) # log scale value to be plotted > > Even better if there is a way to automatically lock x1 to x2, so that > they are forced to span the same range. Sounds good. I don't think anything I've done would effect the ability to provide such options. Basically, LOG/DE_LOG could be MAP/UNMAP or some variation with functions. There should be pairs of functions, one being the inverse function of the other. For the sampled functions, instead of axis_unlog_interval(x_axis, &t_min, &t_max, 1) probably axis_linearize_interval() because that is what we are trying to do, i.e., some parameterization that for which linear spacing results in linear spacing on the scale whatever it is. Not too difficult, I think, but I'd say get data storage squared away first. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-07-02 03:10:43
|
Ethan A Merritt wrote: > On Sunday 01 July 2007 16:41, Daniel J Sebald wrote: > >>The following is confusing to me: >> >>" The `volatile` keyword indicates that the contents of the data file >>may be different if the file is re-read. This tells the program to >>use `refresh` rather than `replot` commands whenever possible. >> >>I assume "tells the program" means "tells gnuplot". But beyond that, the > > interpretation of this is more left to the user. OK, "volatile" is clear. > But for one user it may be desired that the volatile files be reread with > every new "replot", for another user it may be desired that the volatile > files not be reread. > > Exactly. That's why they get a choice of whether to use the keyword > or not. If you know the data may change, but you want to zoom and > play aroung with the the existing plot without reading in new data, > then you plot it with "volatile". This tells gnuplot to keep using > the old data rather than reading in new data. > > If you want to update the display with the newest available data every > time you hit the 'e' key, then you *don't* flag it volatile. Hmmm, > yes I see that could be a bit confusing. I'll ponder a better way > to describe it. Well, that feature makes sense. Typing 'e' in the plot window will update the data? That's nice. I see that now, "builtin-replot". However, I'd argue--given the "refresh" feature is in place--that zoom/unzoom and log/unlog should not ever reread from a file. That's what 'e' is for. >>In other words "volatile" is an accurate word, but implication is > > somewhat ambiguous. > > Feel free to suggest better wording, or even a different keyword. > The basic point is to provide a way to say "reread every time" > vs. "reread only when there's no other option". zoom/unzoom/log/unlog keystrokes in the plot window always being "refresh" is fine with me. No one should be using those features as a means to re-read a data file. Is there an instance someone can think of where that is preferred? In fact, it's kind of strange that anyone would want to reread data when zooming. The question becomes "Is what I'm seeing a result of looking more closely or the data changing?" >>The other thing I don't like is the "whenever possible". I've been > > trying to make the point that unless there is precise behavior for this > feature the "whenever possible" is going to make the user or programmer > give up in futility because he or she won't know when datafiles are > actually reread. "Not when log/unlog via mouse or set", "not when there > are splines", "not for this condition", etc. > > "The perfect is the enemy of the good". For the last 20 years > gnuplot has not allowed you to zoom volatile data. > Mostly it's been a minor annoyance. Now there's a reason to support > it, since Octave sends data in-line. But you are taking the extreme > position that a patch to fix this is no good unless it also re-works > log/unlog axis rescaling. I just don't get it. I've proposed a method that achieves the full spectrum of features, feeds data at the very front and runs it through the system so there is no concern about any different behavior having to do with splines or probably any future processing method. It's just that I think that is the much preferred way to go. Keep in mind I didn't start with this antithesis position. I've tried different ideas for how to reuse the plot data, all with some problems. I've eventually moved to the position that "save data from df_readline()" is the way to go. > I'm perfectly happy to see the axis scaling cleaned up. > But it's an orthogonal issue. Besides which, in all the years that > I've used gnuplot (less then 20 but more than 10 :-) I've never > wanted to toggle log scale with a hot key. Is this really so > important to you? No, I've not made great use of log/unlog, but there are fields where this would be the case, spectrum analysis, time/frequency analysis. But from a user's standpoint consistency is the issue. The user isn't concerned about the innards of gnuplot, he or she just notices that zoom/unzoom works but not log/unlog when the data comes in from a pipe or at the command line. >>I'd say drop the "volatile" keyword. Then two methods are acceptable. >>One, there are two commands "replot/refresh" in which "replot" *always* >>rereads files and "refresh" *always* retrieves the data from memory. > > > That is exactly what I implemented. If you have found a case in > which it doesn't act this way, please report it as a bug. > > The "volatile" keyword does not affect this. > > Perhaps my documentation and description is inadequate, since you seem > to misunderstand what the patch actually does. I welcome your > help in improving the documentation, but I do not agree with you that > the log/unlog business is particularly relevant. It's a footnote at > best: "Please note that the 'l' and 'L' hotkeys are disabled if the > plot contains in-line or volatile data". You haven't said anything yet about the solution to the splines issue, or any future processing that a programmer may apply to the data which invalidates going back and forth between logarithmic, inverse and linear scales. From what you have said above I'm gathering that now even long term you think that log/unlog on volatile data will not happen. And there is the issue of the patch currently not resampling the FUNC data in refresh mode. That one can be fixed in concept, but not easily without shuffling around some code so that one can get to the hunk labelled "second pass" in plot2d.c and plot3d.c. I'm not seeking perfection, but I'm saying there are too many compromises with the approach, especially when there is an alternative. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-07-02 04:38:21
|
On Sunday 01 July 2007 20:10, Daniel J Sebald wrote: > Ethan A Merritt wrote: > > On Sunday 01 July 2007 16:41, Daniel J Sebald wrote: > > > > If you want to update the display with the newest available data every > > time you hit the 'e' key, then you *don't* flag it volatile. Hmmm, > > yes I see that could be a bit confusing. I'll ponder a better way > > to describe it. > > Well, that feature makes sense. Typing 'e' in the plot window will update the data? Oy. Now I really do give up. This was the entire original point of the exercise. The hotkeys 'e' 'a' 'n' 'p' and 'u' and mouse zooming stopped working for Octave. I have tried to make them work again. The ruler and grid toggles stopped working also, but they could probably have been fixed in a simpler manner if that were the only problem. > No one should be using those features as a means to re-read a data file. > Is there an instance someone can think of where that is preferred? Yep. We use it often. We have long-running jobs that do simulations or stochastic refinement. If you plot the logged output, you can often tell whether it has found a likely solution yet or not. So we leave a gnuplot plot window on the workstation screen to monitor the history of the run so far. Often I run a little script in an infinite loop that replots every few minutes, but if you want to see the current status at any time you can just hit the 'e' key (or the replot icon on the wxt terminal). For this particular use it is not particularly important whether the zoom/unzoom also updates. But if it doesn't, you'd want to force an update first using the 'e' key. > From what you have said above I'm gathering that now even > long term you think that log/unlog on volatile data will not happen. I am finding this discussion rather frustrating, because you don't seem to read either the patch documentation or the (2? 3?) explanations I have offered for longer term plans. In fact I think that long-term log/unlog will cease to be a special case, and no special measures will be needed to handle it. > I'm not seeking perfection, but I'm saying there are too many > compromises with the approach, especially when there is an alternative. You have proposed an alternative, but you have not convinced me it will work. Are you planning to finish off a complete alternative patch any time soon? I thought you were bowing out of the project, but if you are about to present a complete alternative solution I'm willing to hold off and run side-by-side tests on the two alternatives to evaluate pros and cons. The problems I have with your current prototype patch include: - It adds a whole new layer of data storage that at a minimum doubles the space required. In fact I think it will turn out to be much worse than doubling by the time all plot types and input alternatives are handled. - The comments do not match the actual code. For instance, the comment at the top says that it does away with the df_eof mechanism. But it doesn't. In fact it breaks it entirely, so far as I can tell by reading the patch. Have you really tested this? - It doesn't handle strings or expression evalution involving strcol(). This may or may not be a killer. - It doesn't actually provide any advantage over the current "refresh" patch other than toggling the log scale. If I'm wrong about that, please provide a test script so that I can understand the difference. You mentioned smoothing, but I think you are off the mark there. That is not an option you can change via replot in the first place. You would need to construct a whole new plot command. You do bring up an interesting point with regard to the sampling interval of functions. If the sampling interval is too coarse, then we may notice a difference between the two approaches. But I think I can bump up the sampling interval in advance if I know that 'refresh' will be used for zoomin. Thanks for that observation. -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-07-02 09:45:39
|
Ethan A Merritt wrote:
> On Sunday 01 July 2007 20:10, Daniel J Sebald wrote:
>
>>Ethan A Merritt wrote:
>>
>>>On Sunday 01 July 2007 16:41, Daniel J Sebald wrote:
>>>
>>>If you want to update the display with the newest available data every
>>>time you hit the 'e' key, then you *don't* flag it volatile. Hmmm,
>>>yes I see that could be a bit confusing. I'll ponder a better way
>>>to describe it.
>>
>>Well, that feature makes sense. Typing 'e' in the plot window will update the data?
>
>
> Oy. Now I really do give up. This was the entire original point of the exercise.
> The hotkeys 'e' 'a' 'n' 'p' and 'u' and mouse zooming stopped working for Octave.
> I have tried to make them work again.
I'm not as lost in space as you are trying to imply. Quite aware of the issue, just hadn't heard 'e' bandied about.
>>No one should be using those features as a means to re-read a data file.
>>Is there an instance someone can think of where that is preferred?
> For this particular use it is not particularly important whether the
> zoom/unzoom also updates. But if it doesn't, you'd want to force an
> update first using the 'e' key.
So, it isn't important, in this case, that the zoom/unzoom rereads data, which was my point. 'e' fits the bill.
>>From what you have said above I'm gathering that now even
>>long term you think that log/unlog on volatile data will not happen.
>
>
> I am finding this discussion rather frustrating, because you don't seem
> to read either the patch documentation or the (2? 3?) explanations I
> have offered for longer term plans. In fact I think that long-term
> log/unlog will cease to be a special case, and no special measures
> will be needed to handle it.
I'm dogmatic because I don't believe it.
>>I'm not seeking perfection, but I'm saying there are too many
>>compromises with the approach, especially when there is an alternative.
>
>
> You have proposed an alternative, but you have not convinced me it
> will work. Are you planning to finish off a complete alternative
> patch any time soon? I thought you were bowing out of the project,
Yes, a month ago I said I'll be making changes in my life so I was trying to give developers an opportunity to integrate any patches I had remaining on sourceforge so I could address any concerns. Patches that fix current bugs. Ones I'd been asked to "pick a bug and fix it". Etc. Over the course of a month did any of them get consideration? No. When someone volunteers their time, should make good use of it.
And why ask for a review of your patch if you aren't willing to hash out any concerns, like the splines problem and the un-resampled FUNC data? You are rushing your patch toward CVS whereas with other patches you've been measured and cautious.
> but if you are about to present a complete alternative solution
> I'm willing to hold off and run side-by-side tests on the two
> alternatives to evaluate pros and cons.
I'll put a complete patch in sourceforge. Evaluate as you wish. End of discussion.
> The problems I have with your current prototype patch include:
>
> - It adds a whole new layer of data storage that at a minimum
> doubles the space required. In fact I think it will turn out
> to be much worse than doubling by the time all plot types and
> input alternatives are handled.
>
> - The comments do not match the actual code. For instance, the
> comment at the top says that it does away with the df_eof
> mechanism. But it doesn't. In fact it breaks it entirely,
> so far as I can tell by reading the patch. Have you really
> tested this?
Sure, df_eof is simply a global variable. That information is already passed back by df_readline(). Don't need the extraneous global. It's still used inside datafile.c of course.
> - It doesn't handle strings or expression evalution involving
> strcol(). This may or may not be a killer.
I'll attempt to fix that.
The thing is, I don't think strings will work with the method you are proposing without additional code. The x,y,z values of the labels are gotten in get_data() as:
case LABELPOINTS:
/* Load the coords just as we would have for a point plot */
store2d_point(current_plot, i, v[0], v[1], v[0], v[0], v[1],
v[1], -1.0);
/* Allocate and fill in a text_label structure to match it */
store_label(current_plot->labels,
&(current_plot->points[i]), i, df_tokens[2], v[3]);
i++;
break;
But your patch is circumventing get_data(). So how is it that the values in the strings will have their x,y,z updated when the axis scale is modified? Put a loop inside refresh_request() to update the x,y,z of strings as well. But at what point does refresh_request() become an almost full reimplementation of the code inside plot2d.c?
>
> - It doesn't actually provide any advantage over the current
> "refresh" patch other than toggling the log scale. If I'm
> wrong about that, please provide a test script so that I can
> understand the difference.
The splines smoothing/curve fitting. E(L(X)) may equal X, i.e., reversible axis transform. But E(S(L(X)) != S(E(L(X))) = S(X).
The FUNC data is always resampled so that this works as expected.
> You mentioned smoothing, but I think you are off the mark there.
> That is not an option you can change via replot in the first
> place. You would need to construct a whole new plot command.
No, but logscale is. And if the roadmap is to allow logscale to work with refresh, with something like
plot "foo" with lines <smoothing option, I forget keyword>
set logscale x
refresh
the data comes in and is stored in "points". Then smoothing code alters "points". After that the data cannot be transformed between axis scalings anymore because it has been altered inside "points".
> You do bring up an interesting point with regard to the
> sampling interval of functions. If the sampling interval is
> too coarse, then we may notice a difference between the two
> approaches. But I think I can bump up the sampling interval
> in advance if I know that 'refresh' will be used for zoomin.
> Thanks for that observation.
Not a good solution.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-07-02 16:25:05
|
On Monday 02 July 2007 02:45, Daniel J Sebald wrote: > > Yes, a month ago I said I'll be making changes in my life so I was trying= =20 > to give developers an opportunity to integrate any patches I had remainin= g=20 > on sourceforge so I could address any concerns. Patches that fix current= bugs. =20 > Ones I'd been asked to "pick a bug and fix it". Etc. Over the course of= =20 > a month did any of them get consideration? No. =20 > When someone volunteers their time, should make good use of it. =20 Dan, I have myself put 4 of your patches into CVS over the past three weeks, according to the ChangeLog. Thimoth=E9e and Petr were going over your hidden3d and helpfile patches. Your effort and contributions are appreciated. But some of these are large patches, and touch pieces of the code that were already messy to begin with. It's not trivial to review and understand these. It is for example much easier to evaluate a self-contained body of new cleanly-written code than it is to=20 evaluate the effects of adding complex bandaids to old crufty code. That's why new drivers can be adopted fairly rapidly, while re-working the multiplexed terminal input code paths has been an recurring thorn in our side for years. > And why ask for a review of your patch if you aren't willing to hash out= =20 > any concerns, like the splines problem and the un-resampled FUNC data? I already thanked you for pointing out the function resampling issue. As to splines - I still have not spotted where in the code this would be a problem, and I haven't noticed any problems in practice using the demo files (e.g. mgr.dem). Could I ask you one more time to point to specific code lines or a demo script that shows a problem with splines or=20 smoothing? > You are rushing your patch toward CVS whereas with other patches=20 > you've been measured and cautious. =20 Heh. I'm not the one who is rushing it. I'd just as soon let it sit on SourceForge to accummulate feedback, as is my usual wont. It's the release of an incompatible Octave version that is fueling the urgency. > > the comment at the top says that it does away with the df_eof > > mechanism. But it doesn't. Have you really tested this? > Sure, df_eof is simply a global variable. That information is already=20 > passed back by df_readline(). Don't need the extraneous global. Sadly, this is not true. Getting rid of df_eof has been on my personal TODO list for quite a while. I've tried to remove it before and learned that it gets messy. The routines in datafile.c use it as an OOB channel for passing error conditions back to the calling routines. I'm sure a cleaner mechanism without the global variable is possible, but it's not as simple as just deleting it. > The thing is, I don't think strings will work with the method you are=20 > proposing without additional code. The x,y,z values of the labels are=20 > gotten in get_data() .... >=20 > But your patch is circumventing get_data(). So how is it that the=20 > values in the strings will have their x,y,z updated when the axis=20 > scale is modified? ??? I don't intend that their x,y,z values ever be updated. The point of "refresh" is to *not* update the values. I am suggesting that we implement axis scaling as an extra step in coordinate mapping. Input coordinates will always remain untouched. I thought we were in 100% agreement on that point. The transformation will be done later, at the time a plot coordinate is converted to a screen coordinate. No doubt this will turn up some wrinkles (e.g. layout of tic positions), but it will do away with the current complexities at the input stage. > > - It doesn't actually provide any advantage over the current > > "refresh" patch other than toggling the log scale. If I'm > > wrong about that, please provide a test script so that I can > > understand the difference. =20 >=20 > The splines smoothing/curve fitting. E(L(X)) may equal X, i.e.,=20 > reversible axis transform. But E(S(L(X)) !=3D S(E(L(X))) =3D S(X).=20 Give me an actual test script showing a problem, please. =2D-=20 Ethan A Merritt |
|
From: James R. V. Z. <jr...@co...> - 2007-07-20 01:40:28
|
I've just uploaded a patch that implements probability axes:
1757226 Provide "probability" scaling and axes 2007-07-19 21:31 5 nobody vanzandt
Rationale:
Probability axes simplify the presentation of certain kinds of data.
Recall that if Y varies as the exponential of X, then data values are
best shown in a log plot - i.e. where you plot the logarithm of Y
against X. More generally, if there are very small and very large Y
values, but all are positive, then it is convenient to use a log Y
axis. E.g. if you plot Y values of .002, .02, and 200 along a linear
axis, it would be hard to tell the first two apart. However, it would
be easy with a log axis.
Suppose you have a collection of n data values that you think are
normally distributed. Find the "empirical distribution function": a
cumulative probability distribution function that concentrates
probability 1/n at each of the n numbers in the sample. I.e. sort the
values and label them X(1) through X(n). Then let Y(k)=k/n. If you
plot Y vs. X, you get something like a sigmoid curve, which starts
near the line Y=0, rises quickly near the mean of the X values, then
gradually approaches the line Y=1. Probability axes are the way of
transforming Y values such that, if the X values were really normally
distributed, then the transformed data points fall approximately along
a straight line.
More generally, if there are both very small Y values and values very
near 1, but none outside the range 0 to 1 (e.g. if Ys represent
probabilities), then probability axes can make the data easier to see.
Summary of changes: Most of the added code is in the new files
"transform.c" and the corresponding header file "transform.h".
The "probability" transformation (inverse of normal CDF) is the only
one implemented here. However, the logic for labeling the axis is
quite general. The goal is to select a set of tics and minitics such
that:
- tic labels are "simple"
- tic labels do not overlap
- the distances between tics are roughly equal
- the numeric value corresponding to any minitic is unambiguous
- the distances between minitics are roughly equal, and small enough
that the numeric value of any point can be estimated by eye.
The current code for log axes uses the functional forms for both the
data transform log(x) and its inverse 10^x. This patch for
probability axes does the same. However the part that calculates tic
and minitic locations uses the function form only for the forward
transformation -- inverse values are found numerically. My hope is
that this more general implementation can be easily applied to other
transform functions, including user-supplied ones without a convenient
inverse.
axis_array[axis].log is now an enum, with values SCALE_LINEAR,
SCALE_LOG, and SCALE_PROBABILITY, and AXIS_LOG_VALUE and
AXIS_DE_LOG_VALUE are functions instead of macros.
TODO:
- Rename axis_array[axis].log to axis_array[axis].scale
- Convert names AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE to lower case.
- Implement several other kinds of axes, including "weibull plots".
- Implement a user-supplied scaling function.
- Implement scaling only of axis labels, without scaling the data.
- New command syntax [axis] "set scale linear|log|probability|f(x) x|y|..."
Ethan Merritt wrote:
> > >
> > > My request was simply that you leave the existing log scale code
> > > in place until a general mechanism was ready to replace it.
> >
> > What do you mean by general? Able to apply mappings other than
> > log scale?
>
> Exactly. I gave a bunch of examples earlier. The most common
> request (and hardest to work around) is marking off the X-axis as
> 1/x. For instance, we crystallographers have to deal with
> inconsistent usage all the time; some quantities are given in terms
> of energy while others are given in terms of wavelength. There is
> an inverse relationship:
> Energy = k / Wavelength
> where k is an appropriate constant. It is a pain to try to persuade
> gnuplot to mark off both Energy and Wavelength on axes of the same plot.
>
> I would like to be able to do something like:
>
> set axis x1 x # will use for Energy
> set axis x2 k/x # will use for Wavelength
> set axis y1 log(y) # log scale value to be plotted
>
> Even better if there is a way to automatically lock x1 to x2, so that
> they are forced to span the same range.
>
> --
> Ethan A Merritt
Ethan wants to rescale one or both axes without changing the data. I
would like to think that this patch is a first step toward that
capability. The patch rescales the data as well as the axes.
At least, it could easily handle the tic/minitic placement.
(By the way, I do have CVS write access, but I figured this would be
too big a change to apply to the head. I am not comfortable enough
with my CVS skills to start a new branch, let alone to try and merge
later on.)
- Jim Van Zandt
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-07-20 03:51:15
|
On Thursday 19 July 2007 18:40, James R. Van Zandt wrote: > > I've just uploaded a patch that implements probability axes: > > 1757226 Provide "probability" scaling and axes 2007-07-19 21:31 5 nobody vanzandt Looks interesting. But I'm heading out of town for a week, and won't be able to look at it until I get back. Ethan > > Rationale: > > Probability axes simplify the presentation of certain kinds of data. > > Recall that if Y varies as the exponential of X, then data values are > best shown in a log plot - i.e. where you plot the logarithm of Y > against X. More generally, if there are very small and very large Y > values, but all are positive, then it is convenient to use a log Y > axis. E.g. if you plot Y values of .002, .02, and 200 along a linear > axis, it would be hard to tell the first two apart. However, it would > be easy with a log axis. > > Suppose you have a collection of n data values that you think are > normally distributed. Find the "empirical distribution function": a > cumulative probability distribution function that concentrates > probability 1/n at each of the n numbers in the sample. I.e. sort the > values and label them X(1) through X(n). Then let Y(k)=k/n. If you > plot Y vs. X, you get something like a sigmoid curve, which starts > near the line Y=0, rises quickly near the mean of the X values, then > gradually approaches the line Y=1. Probability axes are the way of > transforming Y values such that, if the X values were really normally > distributed, then the transformed data points fall approximately along > a straight line. > > More generally, if there are both very small Y values and values very > near 1, but none outside the range 0 to 1 (e.g. if Ys represent > probabilities), then probability axes can make the data easier to see. > > Summary of changes: Most of the added code is in the new files > "transform.c" and the corresponding header file "transform.h". > > The "probability" transformation (inverse of normal CDF) is the only > one implemented here. However, the logic for labeling the axis is > quite general. The goal is to select a set of tics and minitics such > that: > - tic labels are "simple" > - tic labels do not overlap > - the distances between tics are roughly equal > - the numeric value corresponding to any minitic is unambiguous > - the distances between minitics are roughly equal, and small enough > that the numeric value of any point can be estimated by eye. > > The current code for log axes uses the functional forms for both the > data transform log(x) and its inverse 10^x. This patch for > probability axes does the same. However the part that calculates tic > and minitic locations uses the function form only for the forward > transformation -- inverse values are found numerically. My hope is > that this more general implementation can be easily applied to other > transform functions, including user-supplied ones without a convenient > inverse. > > axis_array[axis].log is now an enum, with values SCALE_LINEAR, > SCALE_LOG, and SCALE_PROBABILITY, and AXIS_LOG_VALUE and > AXIS_DE_LOG_VALUE are functions instead of macros. > > TODO: > - Rename axis_array[axis].log to axis_array[axis].scale > - Convert names AXIS_LOG_VALUE and AXIS_DE_LOG_VALUE to lower case. > - Implement several other kinds of axes, including "weibull plots". > - Implement a user-supplied scaling function. > - Implement scaling only of axis labels, without scaling the data. > - New command syntax [axis] "set scale linear|log|probability|f(x) x|y|..." > > > Ethan Merritt wrote: > > > > > > > > My request was simply that you leave the existing log scale code > > > > in place until a general mechanism was ready to replace it. > > > > > > What do you mean by general? Able to apply mappings other than > > > log scale? > > > > Exactly. I gave a bunch of examples earlier. The most common > > request (and hardest to work around) is marking off the X-axis as > > 1/x. For instance, we crystallographers have to deal with > > inconsistent usage all the time; some quantities are given in terms > > of energy while others are given in terms of wavelength. There is > > an inverse relationship: > > Energy = k / Wavelength > > where k is an appropriate constant. It is a pain to try to persuade > > gnuplot to mark off both Energy and Wavelength on axes of the same plot. > > > > I would like to be able to do something like: > > > > set axis x1 x # will use for Energy > > set axis x2 k/x # will use for Wavelength > > set axis y1 log(y) # log scale value to be plotted > > > > Even better if there is a way to automatically lock x1 to x2, so that > > they are forced to span the same range. > > > > -- > > Ethan A Merritt > > Ethan wants to rescale one or both axes without changing the data. I > would like to think that this patch is a first step toward that > capability. The patch rescales the data as well as the axes. > At least, it could easily handle the tic/minitic placement. > > (By the way, I do have CVS write access, but I figured this would be > too big a change to apply to the head. I am not comfortable enough > with my CVS skills to start a new branch, let alone to try and merge > later on.) > > - Jim Van Zandt -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-07-24 12:25:41
|
> I've just uploaded a patch that implements probability axes: > Probability axes simplify the presentation of certain kinds of data. It's just a particular scaling for one case. I would prefer Ethan's proposal: > > I would like to be able to do something like: > > > > set axis x1 x # will use for Energy > > set axis x2 k/x # will use for Wavelength > > set axis y1 log(y) # log scale value to be plotted > > > > Even better if there is a way to automatically lock x1 to x2, so that > > they are forced to span the same range. > (By the way, I do have CVS write access, but I figured this would be > too big a change to apply to the head. I am not comfortable enough > with my CVS skills to start a new branch, let alone to try and merge > later on.) Your proposal is a major patch, so it should be discussed and agreed on the mailing list. Don't make a branch, stay with a patch. --- PM |
|
From: James R. V. Z. <jr...@co...> - 2007-07-27 02:05:13
|
Petr Mikulik <mi...@ph...> wrote:
> > I've just uploaded a patch that implements probability axes:
> > Probability axes simplify the presentation of certain kinds of data.
>
> It's just a particular scaling for one case. I would prefer Ethan's
> proposal:
>
> > > I would like to be able to do something like:
> > >
> > > set axis x1 x # will use for Energy
> > > set axis x2 k/x # will use for Wavelength
> > > set axis y1 log(y) # log scale value to be plotted
> > >
I would like to see a more general mechanism too. For the general
case, I would write something like
set axis x1 f(x) # how the x1 axis labels and tic marks relate
# to the "number being plotted"
set axis x2 g(x) # how the x2 axis labels and tic marks relate
# to the "number being plotted"
set x scale h(x) # how screen distances relate to the "number
# being plotted"
plot (k($1)):2 # how the "number being plotted" relates to the
# data in column 1 of the data file
For an ordinary linear plot: f(x) = g(x) = h(x) = x
For a log scale: f(x) = g(x) = x
h(x) = log10(x)
For probability scaling: f(x) = g(x) = x
h(x) = inverse_normal_func(x)
One tricky part is placing the tic marks and labels if f(h(x)) or
g(h(x)) is nonlinear. That's what my code in transform.c does.
The other tricky part is actually allowing the user to define the
functions. I know the expression parsing and function evaluation is
in gnuplot, but I have not been able to hook that up to my code. I'm
hoping one of the other developers will consider that an easy job :-)
There are two more issues:
1) The range of validity for log scaling is hard-coded in, of course.
I did the same thing for probability scaling. If we let the user
define a function, I think we'll have to let him define its range of
validity too. That holds for each of the functions f(), g(), and h().
So for Ethan's wavelength scale we would have something like
set axis x1 x
set axis x2 k/x valid x>0
set x scale log(x) valid x>0
or for probabilty scales
set x scale inverse_normal_func(x) valid ((0<x) && (x<1))
2) For either linear or log scales, gnuplot can "round out" the plot
range so it can put a labeled tic mark at each end of the axis. If
the two axes are related by a function, then we cannot generally do
that. (A user-defined function may not even be defined outside the
range of the data provided.) My code does not round out.
> > > Even better if there is a way to automatically lock x1 to x2, so that
> > > they are forced to span the same range.
I don't follow this. It looks to me that Ethan's syntax does force
the two axes to span the same range.
- Jim Van Zandt
|
