gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Small technicality on dynarray

[<HBB...@t-...>]

Daniel J Sebald wrote:

> If I do
> 
>   init_dynarray(foo_array, sizeof(foo), 0, 200);

Then you're already misusing the dynarray module.  It's designed to be 
called like this:

	init_dynarray(&foo_array, sizeof(foo), 200, 200);

Note the '&'.

> That is, it seems it isn't possible to initialize
> the dynarray to size zero.  

There's no point in doing that, so why would you want to?  A dynarray of 
size zero is about as useful as a pointer to nothing.

> It'd nice if one could. It's not of great importance, but for such a
> fundamental utility "consistency" (lack of term) would be nice.

Consistency with what?

> "world.dem", line 13: nextfrom_dynarray: dynarray wasn't initialized!
[...]
> Maybe it should be
> 
> if (size <= 0) graph_error("foo"); this->v = ...

And how would that be any better than the above?  It's just a different 
error message, but no change of actual behaviour.

> It will save a test every time nextfrom_dynarray() is called (which
> is fairly considerable).  Plus, let's say init_dynarray *wasn't*
> called.  

Then size is zero --- that's why the test is done the way it is.

The control struct is supposed to be static, after all, so it's always 
initialized to zero.

 > gp_alloc uses "malloc" which isn't guaranteed to be zero
> (probably system dependent).  

What would that have to do with anything?

Re: Small technicality on dynarray

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

Daniel J Sebald wrote:

>     if (!this->v)
> 	graph_error("resize_dynarray: dynarray wasn't initialized!");
> 
[snip]
> It will save a test every time nextfrom_dynarray() is called (which
> is fairly considerable). Plus, let's say init_dynarray *wasn't*
> called. gp_alloc uses "malloc" which isn't guaranteed to be zero
> (probably system dependent). gnuplot should be using "calloc" if the
> above test is to be foolproof.

Allow me to clarify.  The above test assumes that the dynarray structure pointed to by "this" was initialized to zero.  I'm not sure how one guarantees that the programmer had done so or that a previously used dynarray structure was reset to zero.  (In the case I'm looking at memset() is already used to initialize the whole plot_struct so it's fine.)  Also, if dynarray is modified to guaranteed that the above test is foolproof, then it should be possible in init_dynarray to also test on this->v to ensure that init_dynarray isn't leaking memory with

    this->v = 0;		/* preset value, in case gp_alloc fails */

So, in summary, the above test isn't foolproof but it is only for the programmer's benefit and shouldn't cause a bug on systems that don't zero malloc memory, provided gnuplot was programmed correctly.  Could we change to

    if (!this->entry_size)
	graph_error("resize_dynarray: dynarray wasn't initialized!");

instead?

Dan

Small technicality on dynarray

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

I'm using a dynarray for the "quick refresh record data etc." patch (more on this shortly) but I just wanted to point out a picky technical issue.  That is, it seems it isn't possible to initialize the dynarray to size zero.  It'd nice if one could.  It's not of great importance, but for such a fundamental utility "consistency" (lack of term) would be nice.

If I do

  init_dynarray(foo_array, sizeof(foo), 0, 200);

and then later

  nextfrom_dynarray(foo_array);

I will get an execution error of

         "world.dem", line 13: nextfrom_dynarray: dynarray wasn't initialized!

>From the programmer's perspective, I have to look to the code to know that I must initialize to some size greater than zero.  In the init_dynarray code is

    this->v = 0;		/* preset value, in case gp_alloc fails */
    if (size)
	this->v = gp_alloc(entry_size*size, "init dynarray");

Maybe it should be

    if (size <= 0)
        graph_error("foo");
    this->v = ...

So the programmer knows to initialize to something greater than zero.  But actually, I might argue for just dropping the error messages

    if (!this->v)
	graph_error("resize_dynarray: dynarray wasn't initialized!");

It will save a test every time nextfrom_dynarray() is called (which is fairly considerable).  Plus, let's say init_dynarray *wasn't* called.  gp_alloc uses "malloc" which isn't guaranteed to be zero (probably system dependent).  gnuplot should be using "calloc" if the above test is to be foolproof.

I'm comfortable with just dropping those error messages (and allow dynarrays to be initialized to 0).  If init_dynarray() isn't called properly first the program will fall apart so fast that the programmer will catch on quick.

However, if one wants to keep the above errors, I'd say switch to some variation of calloc and instead of testing on "this-v", test on "this->entry_size" so that a person can initialize the size to 0.  (This would probably be the preferred route.)

Dan

Re: Axis rescaling: [was: Re: Quick refresh [was: q for quit in plot windows]]

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

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

Re: Axis rescaling: [was: Re: Quick refresh [was: q for quit in plot windows]]

[Ethan M. <merritt@u.washington.edu>]

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

Re: Axis rescaling: [was: Re: Quick refresh [was: q for quit in plot windows]]

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

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

Axis rescaling: [was: Re: Quick refresh [was: q for quit in plot windows]]

[Ethan M. <merritt@u.washington.edu>]

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

Re: gnuplot needs more developers/administrators

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 June 2007 00:22,  Hans-Bernhard Br=F6ker wrote:

> > Well, it feels like I've preached against the way 'map' was implemented=
 since
> > day one.  Nobody listened.
>=20
> I coded the "set view map", I've listened to your comments, but I had fea=
r=20
> to hit your axes module. So the status is as is.
>=20
> > it took years to sort out that mess
>=20
> yes; and I was glad when it finally worked for all cases

I was not around at that time, and don't know the history or intent of
the axis.range_is_reverted flag.  =20

Could someone enlighten me on how this is supposed to work?

The current behaviour seems inconsistent, so I am having trouble
trying to make the "refresh" code to behave equivalently.
=46or example, the following pair of commands produce a mirror pair
of plots:
	set yrange [-300:300] noreverse; plot 'silver.dat'
	set yrange [-300:300] reverse;   plot 'silver.dat'

But the following pair produce identical plots:
	set yrange [300:-300] noreverse; plot 'silver.dat'
	set yrange [300:-300] reverse;   plot 'silver.dat'

So I am confused. =20
Does "reverse" mean "interchange the requested min/max"?
Or does it mean "force the min to be greater than the max"?
The latter appears to be true, but in this case the flag seems
very much mis-named.

=46urthermore, some plot/replot/zoom operations appear to
clear this flag;  others do not.  So I cannot count on the
current state of the flag being the same as it was originally.
This again poses a problem for "refresh".

And that's before I even get to splot_map...


=2D-=20
Ethan A Merritt

Re: Quick refresh [was: q for quit in plot windows]

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

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

Re: From the discussion of patch #1723715

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 June 2007 12:32, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
>=20
> > If this is a problem, I suggest that the proper answer is to move the g=
rid
> > settings out of (struct axis) into a new self-contained structure.  I m=
ay
> > be overlooking something, but I don't see why the grid needs to be a
> > property of the axis at all.
>=20
> The grid effectively is a property of the axis, as can clearly be seen=20
> by the way we control it: the majority of grid options have a reference=20
> to some axis in their command syntax.
>=20
> We grid based on tics, which are elements obviously linked to an axis.=20
> As it is, drawing the grid needs a reference to the axis' tic=20
> definitions, its terminal mapping and lots of other things.  In other=20
> words, it needs almost the entire axis struct.

Clearly one needs to refer to the axis structure in order to know
_where_ to draw the grid lines.  But the issue Petr raised is the simpler
question of whether to draw the grid lines at all.  One doesn't need to
know anything about the axis or tics in order to track that requirement.

=46rom a user perspective, toggling the grid on/off from an interactive
display seems much more akin to toggling the ruler than to changing the
axis or tic properties.

> The axis struct is designed around the existing usage.  Redraw is new,=20
> and poses new requirements.  The axis struct will have to learn new=20
> tricks.  Splitting it up into separate sub-structs for range, tics and=20
> grid options would be the right step to start with.  That way, 'zoom'=20
> and friend can save/restore just the range, but leave grid settings alone.

I take your point, but I am not sure I follow what issue you are trying
address.  Are you thinking that a change to, say, the minitic spacing
while zoomed should, or should not, be retained after unzoom?

I have no objection to such sub-structures.
But before carving the axis structure into pieces, we would need to decide
which pieces are to persist across zooming and which ones are not.
Anyhow, these issues are relatively minor compared to getting the
refresh mechanism to work at all.  Let me finish getting a working prototyp=
e;
then we can decide what aspects may need to be tweaked.

=2D-=20
Ethan A Merritt

Re: From the discussion of patch #1723715

[<HBB...@t-...>]

Ethan Merritt wrote:

> If this is a problem, I suggest that the proper answer is to move the grid
> settings out of (struct axis) into a new self-contained structure.  I may
> be overlooking something, but I don't see why the grid needs to be a
> property of the axis at all.

The grid effectively is a property of the axis, as can clearly be seen 
by the way we control it: the majority of grid options have a reference 
to some axis in their command syntax.

We grid based on tics, which are elements obviously linked to an axis. 
As it is, drawing the grid needs a reference to the axis' tic 
definitions, its terminal mapping and lots of other things.  In other 
words, it needs almost the entire axis struct.

The axis struct is designed around the existing usage.  Redraw is new, 
and poses new requirements.  The axis struct will have to learn new 
tricks.  Splitting it up into separate sub-structs for range, tics and 
grid options would be the right step to start with.  That way, 'zoom' 
and friend can save/restore just the range, but leave grid settings alone.

From the discussion of patch #1723715

[Ethan M. <merritt@u.washington.edu>]

Petr Mikulik commented: 
>> (*) There is a strange thing/bug:
>> unset grid
>> plot ... volatile
>> Now zoom several times, hit "g" for grid on, then hit "u" for 
>> unzoom => grid is lost. This does not happen with "u" in the
>> other usage of the plot command. 
>>

Yes. This is because the grid settings are stored as part of the
individual axis structures. In the new "refresh" mode, when you
"unzoom" the original axis settings are restored, which includes
the old grid settings.  By contrast, when you do a full "replot"
command the axis structures are filled in all over again rather
than being re-used.

If this is a problem, I suggest that the proper answer is to move the grid
settings out of (struct axis) into a new self-contained structure.  I may
be overlooking something, but I don't see why the grid needs to be a
property of the axis at all.  It should be sufficient to define two
bitfields for toggling axis tics on/off. For example:
   extern int grid_majortics, grid_minortics;
   /* Set major but not minor tics for the y2 axis */
   grid_majortics &= 1 << SECOND_Y_AXIS;
   grid_minortics |= ~(1 << SECOND_Y_AXIS);


On Tuesday 19 June 2007 14:58, Daniel J Farrell wrote:
> I would be interested in started developing for gnuplot, but find  
> where to start a bit daunting. Maybe some mentoring of new developers  
> with simple targets might be a good idea. Is there some sort of  
> 'introduction to gnuplot dev' docs?

So here is a nice self-contained project you could start off with.
- Remove the TBOOLEANs gridmajor and gridminor from the definition of
  struct axis    in axis.h
- Define the new bitfields, also in axis.h
- Convert existing references from the old mechanism to the new
- Check whether initialization of the new bitfields needs to be done
  in places like "reset".
  

-- 
Ethan A Merritt

Re: gnuplot needs more developers/administrators

[Petr M. <mi...@ph...>]

> AFAICS, it does it roughly the usual way, via macro
> axis.h:STORE_WITH_LOG_AND_UPDATE_RANGE().  Follow the 'update_axes' argument
> to plot_image_or_update_axes() to find it.

I remember, from the time of adding the "GPVAL_MIN_*" functionality, that 
the axis structure would deserve a min/max value as of time of plotting the 
graph, not mixed with "set range". Hans-Bernhard, haven't you thought of 
adding it?

> >   Note: We only need to support the subset of 3D plots with
> >   "set view map".  It turns out that these always use a reversed y axis.
> 
> Well, it feels like I've preached against the way 'map' was implemented since
> day one.  Nobody listened.

I coded the "set view map", I've listened to your comments, but I had fear 
to hit your axes module. So the status is as is.

> it took years to sort out that mess

yes; and I was glad when it finally worked for all cases

---
PM

Re: gnuplot needs more developers/administrators

[<HBB...@t-...>]

Ethan Merritt wrote:

> - I can't figure out how/where plots "with image" contribute to 
>   autoscaling.  Where in the existing code does this happen?

AFAICS, it does it roughly the usual way, via macro 
axis.h:STORE_WITH_LOG_AND_UPDATE_RANGE().  Follow the 'update_axes' 
argument to plot_image_or_update_axes() to find it.

>   Note: We only need to support the subset of 3D plots with
>   "set view map".  It turns out that these always use a reversed y axis.

Well, it feels like I've preached against the way 'map' was implemented 
since day one.  Nobody listened.  Reversed axes were tricky, but still 
basically sane until the waters were muddied further by inventing 
another reason why some axis would be reverted, supposedly without the 
majority of the code noticing.  But then it turned some parts of the 
code did have to notice.  It took years to sort out that mess.  Sort of.

Re: gnuplot needs more developers/administrators

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 27 June 2007 13:02, Dr. Johannes Zellner wrote:
> I'd also vote strongly for this patch. I'ts useful for all apps which
> write via a pipe to gnuplot both gnuplot commands and inline data.
>=20
> 2007/6/25, Petr Mikulik <mi...@ph...>:
> >
> > I would see the most urgent patch to finish
> >
> > =A0 =A0 =A0 =A0 [ 1723715 ] Refresh plot or zoom without re-reading data
> >
> > because this it is required by the Octave community.

I've uploaded to SourceForge a second-generation version of=20
patch 1723715   "Refresh plot or zoom without re-reading data"

In default mode, it uses the new "refresh" mechanism if and only if
it is a 2D plot containing data flagged "volatile". That means either
data read from pseudodevice '-' or from a file with the the keyword
"volatile".

If the data is not volatile, or if there is some change in state that
requires re-reading the data, then it falls back to calling "replot"
instead.  To test the mechanism without having to type data in by hand,
try
    plot 'silver.dat' volatile with linespoints



Improvements since previous version:

=2D the code has been simplified a bit
=2D 'r' 'a' 'g' 'e' hotkeys tested and working
=2D autoscaling after zooming now works (except for image data)
=2D documentation

Known problems. Please help!

=2D I can't figure out how/where plots "with image" contribute to=20
  autoscaling.  Where in the existing code does this happen?

=2D Reversed axes are not handled correctly.  The existing code for
  reversed axes is a horrible tangle, which doesn't help any.

=2D My first attempts to implement refresh for 3D plots (set view map)
  were a failure.  More thought will be required.  In principle
  it should be sufficient to modify the code in plot3d.c and graph3d.c
  in parallel to the already working changes in plot.c and graphics.c.
  Note: We only need to support the subset of 3D plots with
  "set view map".  It turns out that these always use a reversed y axis.
  So maybe I just need to get reversed axes working properly, and then
  the 3D case will also start working.

=2D-=20
Ethan A Merritt

Re: gnuplot needs more developers/administrators

[Dr. J. Z. <joh...@ze...>]

Hi,

seems that gnuplot is heavily used by crystallographers.
I just thought I'll let you know that me too worked in crystallography some
years ago ... ;-)

-- 
Dr. Johannes Zellner <joh...@ze...>

2007/6/22, Ethan Merritt <merritt@u.washington.edu>:
> On Thursday 21 June 2007 15:04, Petr Mikulik wrote:
> > I've just came from a crystallography workshop ... there I was surprised by
> > an acknowledgment to gnuplot by one speaker. When asked, she said her boss
> > convinced her to use gnuplot and he was right :-)
>
> Heh.
> I also saw gnuplot used in a crystallography presentation recently,
> in a totally unexpected way.  The presenter had recorded diffraction
> images from a non-monochromatic X-ray beam on a CCD detector.
> Successive images were separated by a very small angular rotation of
> the crystal. The CCD images were plotted in gnuplot using some variant
> of "plot with image" and output as an animated gif. This made
> a nice movie showing the displacement of individual Bragg reflections
> on the detector surface as the crystal rotation gradually shifted the
> wavelength accepted by Bragg's Law.
>
> --
> Ethan A Merritt
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: gnuplot needs more developers/administrators

[Dr. J. Z. <joh...@ze...>]

I'd also vote strongly for this patch. I'ts useful for all apps which
write via a pipe to gnuplot both gnuplot commands and inline data.

-- 
Dr. Johannes Zellner <joh...@ze...>

2007/6/25, Petr Mikulik <mi...@ph...>:
> > I would be interested in started developing for gnuplot, but find
> > where to start a bit daunting. Maybe some mentoring of new developers
> > with simple targets might be a good idea.
>
> I would see the most urgent patch to finish
>
>         [ 1723715 ] Refresh plot or zoom without re-reading data
>
> because this it is required by the Octave community.
>
> If you push it into cvs, that would be a great start-up.
>
>
> ---
> PM
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: License change for gpexecute.c and .h, BSD, LGPLv2

[<tim...@en...>]

Timothée Lecomte wrote:
> Dear contributors to gnuplot,
>
> (...)
> So I first wrote to the original authors: Johannes Zellner, Petr 
> Mikulik, Pieter-Tjerk de Boer.
> Then I wrote to the contributors: Hans-Bernhard Broeker, Ethan Merritt.
>   

I forgot Alexander Mai in the above list of contributors I contacted.


> I got positive answers for all of the six people, with the following 
> details:
> (...)
> contributors to these two files:
> (...)
> Alexander: BSD or LGPL, hasn't expressed a preference yet

To be be clear, Alexander said he is ok with both. I'm waiting for his 
answer to whether he has a preference.

Best regard,

Timothée Lecomte

License change for gpexecute.c and .h, BSD, LGPLv2

[<tim...@en...>]

Dear contributors to gnuplot,

The last days, I took the initiative to contact the authors of 
gpexecute.c and gpexecute.h to ask them about a change of the license of 
those files. As you know from my previous posts on this mailing list, 
dealing with gnuplot ambiguous license is part my todo list. I chose to 
start with those two files, because the authors are well identified and 
the code itself is self-contained and useful for terminal drivers as a 
communication library with gnuplot core.

So I first wrote to the original authors: Johannes Zellner, Petr 
Mikulik, Pieter-Tjerk de Boer.
Then I wrote to the contributors: Hans-Bernhard Broeker, Ethan Merritt.

I got positive answers for all of the six people, with the following 
details:

original authors:
Johannes: BSD favourite, LGPLv2 ok
Petr: BSD favourite ("as open as possible"), LGPLv2 ok
Pieter-Tjerk: LGPLv2 favourite, BSD ok

contributors to these two files:
Ethan: BSD favourite, LGPLv2 ok
Alexander: BSD or LGPL, hasn't expressed a preference yet
Hans-Bernhard: LGPLv2 favourite, BSD ok

for what is worth (I modified to lines of gpexecute.c last week ;):
me: LGPLv2 favourite, BSD ok

The good news is that we have agreement from everybody to relicense 
these two files.
The next step is to choose between the two licenses, and as you can see 
the two have roughly an equal share of votes.

So I propose to wait until next week for the final decision, and 
meanwhile I'll let any other contributor to gnuplot speak up. Of course, 
it could be great to get other files of gnuplot relicensed, and it's 
pretty essential to have the _same license for the whole project_, for 
the sake of clarity.

For those of you who are going to speak up now, here is a short reminder 
of some differences between BSD 
(http://www.freebsd.org/copyright/freebsd-license.html) and LGPL 
(http://www.fsf.org/licensing/licenses/lgpl.html) :
-BSD imposes very few restrictions on the reuse of the code. It's 
roughly "do whatever you want with this", in particular you can include 
the code in proprietary applications
-LGPL additionally tries to ensure that the modified code remains free. 
It's roughly: "use, modify, or distribute it as you want, but make your 
modifications publicly available".

Thank you for your interest in the future of gnuplot, I hope to read 
from you soon.

Best regards,

Timothée Lecomte
--
École Normale Supérieure, Paris
Condensed Matter Physics graduate

Re: default size of wxt terminal

[<tim...@en...>]

Dmitri A. Sergatskov wrote:
> On 6/7/07, Timothée Lecomte <tim...@en...> wrote:
>
>>
>> You can still put that line in your $HOME/.gnuplot file and it will be a
>> default then ;)
>
> That is the plan :)
>
>>
>> I'll try to implement that in the next days.
>>
>
> Thanks!
>
It took quite a bit of the "next days" before I started doing it ;), but 
it's now in the CVS !
Thanks for your interest in gnuplot and wxt.

Best regards,

Timothée

Re: gnuplot needs more developers/administrators

[Ethan M. <merritt@u.washington.edu>]

On Monday 25 June 2007 11:22, Petr Mikulik wrote:
> > I would be interested in started developing for gnuplot, but find  
> > where to start a bit daunting. Maybe some mentoring of new developers  
> > with simple targets might be a good idea.
> 
> I would see the most urgent patch to finish
> 
> 	[ 1723715 ] Refresh plot or zoom without re-reading data
> 
> because this it is required by the Octave community.
> 
> If you push it into cvs, that would be a great start-up.

It would be, but this is not the simplest entry point into gnuplot
development!

But yes, I certainly welcome any help with testing or improving this patch.
I have had virtually no feedback on how well it actually works in practice,
and I am not an Octave user so I don't have a good feel for what is
needed there.


-- 
Ethan A Merritt

Re: gnuplot needs more developers/administrators

[Petr M. <mi...@ph...>]

> I would be interested in started developing for gnuplot, but find  
> where to start a bit daunting. Maybe some mentoring of new developers  
> with simple targets might be a good idea.

I would see the most urgent patch to finish

	[ 1723715 ] Refresh plot or zoom without re-reading data

because this it is required by the Octave community.

If you push it into cvs, that would be a great start-up.


---
PM

Re: gnuplot needs more developers/administrators

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 19 June 2007 14:58, Daniel J Farrell wrote:
>=20
> I would be interested in started developing for gnuplot, but find =20
> where to start a bit daunting. Maybe some mentoring of new developers =20
> with simple targets might be a good idea.

Looking back on who has joined the project over the past several years,
it seems that a common path into gnuplot development has been through
improvement of specific terminal drivers, or contribution of new drivers.
Each terminal is largely self-contained, the API is described in=20
=2E./term/README, and existing terminals serve as example code.

Drivers currently under development:

wxt 	- marked EXPERIMENTAL in 4.2
	  (lead developer: Timoth=E9e Lecomte)

cairopdf - likely to go into CVS soon, but still could use a lot of
	  testing and additional features
	  (lead developer: Timoth=E9e Lecomte)

aquaterm - in 4.2, but doesn't fully support recent features added
	  to CVS such as transparency, image clipping, ...
	  (lead developer: Per Persson)

tikz	- brand new, prototype circulated to mailing list but first
	  version not yet on SourceForge.  This looks to be the way
	  forward towards supporting pdflatex.
	  (lead developer: Mojca Miklavec)

svg	- I'd really like to see someone take on the task of adding
	  mousing support to the svg driver.  This would permit=20
	  server-side interactive graphs, which would be a totally
	  new capability. No one is working on this that I know of,
	  but see the contact info attached to Feature Request
	  #1523116  "Allow mousing and zoom of embedded SVG plots"
	  (lead developer: me I guess, although mostly I'm just
	  fielding bug reports and suggested fixes from users)

Old drivers that could use some updating, bug fixes, or extension:

fig	- see various bug reports on SourceForge
	  (lead developer: none that I know of)

win	- probably needs updating for Vista, also needs updating to
	  support recent features like transparency
	  (lead developer: none that I know of)

linux	- this is a console-mode terminal driver, i.e. it can be used even
	  if you are not running x11.  It has two main drawbacks.
	  (1) it uses libsvga, which requires root permission
	  and in general is not very nice.  (2) I've never managed to get
	  it to work, although I see reports that other people use it.


Other possible projects:

Pick a bug from the SourceForge collection, and submit a patch that
fixes it.

Pick a patchset submitted to SourceForge by someone else, and test it
thoroughly.  Patches tested and endorsed by multiple people are much
more likely to get moved into CVS.  If the only one advocating for a
patch is the person who wrote it, and it's not an obvious bug fix,
then it may sit there for a long time before another champion comes
along.

Look through the feature requests on SourceForge, and re-start=20
discussion on the mailing list about whether we could or should
implement it.  Many of these are IMHO not worth pursuing, but some
of them are simply waiting for a clever idea on how to implement it.
Examples of the latter are
 1506495  	  Parallel coordinate plot type
 1359667  	  Make clickable graphics possible


My personal list of things it would be nice to see added for an
eventual version 4.4 or 5.0 includes

=2D better internationalization support

=2D uniform scaling of plot elements (e.g. font size, linewidth)=20
  independent of the canvas size.  Discussion of this has been
  scattered across the mailing list and comments on various bug
  reports and feature requests. I think implementation would be
  fairly easy; it just requires agreeing on the desired API and
  then working through the whole set of terminal drivers to hook
  up the new API to existing capabilities.

=2D Modify term->image() code to pass a transformation matrix to the driver.
  Some terminals (post pdf svg wxt) can use the matrix to modify the image,
  which is a much better option than having the core code do it pixel by
  pixel. Your primary resource here for the core code would be Dan Sebald,
  plus whoever has the best handle on individual terminal capabilities.

=2D additional demo files illustrating features that generate frequent
  questions on the newsgroup or elsewhere

=2D modify the various interactive terminals (x11, wxt, win, aqua) to
  allow mousing of subplots within a multiplot figure

=2D new plot types, but only if there is a scientific community that
  uses them already.  Someone should look through the catalogs of
  plot types available in S+, R, matlab, etc to see if there are some
  obvious ones that are missing in gnuplot.



=2D-=20
Ethan A Merritt

Re: gnuplot needs more developers/administrators

[Petr M. <mi...@ph...>]

> I also saw gnuplot used in a crystallography presentation recently,
> in a totally unexpected way.  The presenter had recorded diffraction
> images from a non-monochromatic X-ray beam on a CCD detector.
> Successive images were separated by a very small angular rotation of
> the crystal. The CCD images were plotted in gnuplot using some variant
> of "plot with image" and output as an animated gif. This made
> a nice movie showing the displacement of individual Bragg reflections
> on the detector surface as the crystal rotation gradually shifted the
> wavelength accepted by Bragg's Law.

Yes, I did something similar for a rocking imaging. Usually with zimg + 
convert/gifsiecle. With gnuplot the image processing is slower, but needed 
when real axes around the image were necessary.

---
PM

Re: gnuplot needs more developers/administrators

[Ethan M. <merritt@u.washington.edu>]

On Thursday 21 June 2007 15:04, Petr Mikulik wrote:
> I've just came from a crystallography workshop ... there I was surprised by 
> an acknowledgment to gnuplot by one speaker. When asked, she said her boss 
> convinced her to use gnuplot and he was right :-)

Heh.
I also saw gnuplot used in a crystallography presentation recently,
in a totally unexpected way.  The presenter had recorded diffraction
images from a non-monochromatic X-ray beam on a CCD detector.
Successive images were separated by a very small angular rotation of
the crystal. The CCD images were plotted in gnuplot using some variant
of "plot with image" and output as an animated gif. This made
a nice movie showing the displacement of individual Bragg reflections
on the detector surface as the crystal rotation gradually shifted the
wavelength accepted by Bragg's Law.

-- 
Ethan A Merritt