gnuplot-beta

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: 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

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...>]

Hans-Bernhard Bröker wrote:
> 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 '&'.

Naturally.  I was typing away and not paying attention.  The compiler weeds out such typos.

> 
>> 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?

Because in the patch I'm doing I'm placing a dynarray in the plot struct but it may not necessarily be used if no data is read from a file, but instead the plot type is FUNC.

>  A dynarray of 
> size zero is about as useful as a pointer to nothing.

Why assign memory if it isn't going to be used?  I could use a pointer to a dynarray in the plot struct, and then gp_malloc memory for the dynarray only if it is needed.  But that gets to be programming spaghetti.

If one could init the size to zero and on the first "nextfrom_dynarray" the array is extended by this->increment, what's wrong with that?

> 
>> 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?

Again, the issue is that such familiarity with the dynarray code is assumed (e.g., "Why set to zero?  That's silly.") that the test *which is not failsafe as I argued* seems extraneous.

Dan

Re: Small technicality on dynarray

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
>> Daniel J Sebald wrote:

>>> 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?

> Because in the patch I'm doing I'm placing a dynarray in the plot
> struct but it may not necessarily be used if no data is read from a
> file, but instead the plot type is FUNC.

So what would be the problem with delaying the init_dynarray() call 
until you actually need the thing?

>> A dynarray of size zero is about as useful as a pointer to nothing.

> Why assign memory if it isn't going to be used?  

By not doing it yet.  Do it when you know you'll need it.

>>> 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?

> Again, the issue is that such familiarity with the dynarray code is
> assumed (e.g., "Why set to zero?  That's silly.") that the test
> *which is not failsafe as I argued* seems extraneous.

The test may not be failsafe, but it's necessary, and correct as it is. 
  Among other things, have a look at free_dynarray().  The state this 
leaves the dynarray struct in has to be tested against, as well as the 
automatic all-zeroes state of the struct.

Re: Small technicality on dynarray

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

Hans-Bernhard Bröker wrote:

> So what would be the problem with delaying the init_dynarray() call 
> until you actually need the thing?

The natural flow is to simply put init_dynarray in cp_alloc where other plot elements are initialized.  If it is initialized when we know we need it, then there is some cumbersome code elsewhere... initializing to 1 is fine.

Dan

Re: Small technicality on dynarray

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

On Saturday 30 June 2007 12:30, Daniel J Sebald wrote:
> I'm using a dynarray for the "quick refresh record data etc." patch 
> (more on this shortly)

Speak up quickly then.
I was heading towards putting it in CVS as-is.
Did you find a problem with it?

	Ethan


-- 
Ethan A Merritt

Re: Small technicality on dynarray

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

Ethan A Merritt wrote:
> On Saturday 30 June 2007 12:30, Daniel J Sebald wrote:
> 
>>I'm using a dynarray for the "quick refresh record data etc." patch 
>>(more on this shortly)
> 
> 
> Speak up quickly then.
> I was heading towards putting it in CVS as-is.
> Did you find a problem with it?

Hold on a bit.  I've got something I think you will like that could be integrated into what you have fairly easily.  I'll explain now I guess since I have a prototype that works (but doesn't have a "refresh" command, just a kludged replot).

I don't like that one has to have two forms of "range check", the STORE_WITH_LOG_AND_UPDATE_RANGE and the what is in the patch.  Also, I think it is much preferred if there is no restriction on "refreshing" if log scale is changed.  That's a nice feature.  Losing negative data because of the log scale is almost a no-go for me.

I'm wrapping up a prototype right now in which all data is saved and can be recalled.  However, I punted on my original approach of leaving ->points in un-transformed format.  Although I like the idea of saving the data not processed, there are couple reasons:

1)  I got to the color axis, and it accesses the data a lot and would have required too many AXIS_LOG_VALUE's.

2)  The splines/fitting code alters the data in ->points.  That right there means we must keep a copy of the original points.  OK, in concept that's fine, but not so nice from a programming perspective.

3)  The good thing about STORE_VALUE_WITH_LOG_AND_UPDATE_RANGE() is that it does the work for those cases only where ->xlow, ->ylow, ->xhigh, etc., are used.  If we wait until after all data is collected then we must transform all that data assuming that it is used.

So 4th and 15... The question is then whether there is a good place to tap into the original data.  I think there is.  Rather than save the ->points, we can save the v[]'s and j's (and user specs).  That array is just as compact at the ->points array.  And if we save that, we can stuff that back through the system pretty much at the start of processing.  So, right near df_readline we can put a mechanism that stores or retrieves the v's.  Seems to work.  I'll post that soon.

The only thing that makes me wonder is the case where format information is gotten from a binary file.  We have the j's and v's and specs.  But will something about not being able to open the binary file and find info about format cause a problem?  I don't think so.  We've been pretty careful to isolate that part of the program.  I think we should be fine but not sure on that one point.

I certainly wouldn't want to descend any further (i.e. into the datafile) for storing the original data.  I'd rather it stay with the plot_struct.  You mentioned a volatile file concept.  Is there any advantage to that?  Or do you think the point to tap into the data is where I described?

Dan

Re: Small technicality on dynarray

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

On Saturday 30 June 2007 15:47, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > On Saturday 30 June 2007 12:30, Daniel J Sebald wrote:
> > 
> > Speak up quickly then.
> > I was heading towards putting it in CVS as-is.
> > Did you find a problem with it?
> 
> Hold on a bit.  I've got something I think you will like that could be 
integrated into what you have fairly easily.

You seem to be working towards something orthogonal. I don't think it
really has anything to do with my patch.

> I don't like that one has to have two forms of "range check", the 
STORE_WITH_LOG_AND_UPDATE_RANGE and the what is in the patch.  Also, I 
think it is much preferred if there is no restriction on "refreshing" if 
log scale is changed.  That's a nice feature.  Losing negative data 
because of the log scale is almost a no-go for me.

I repeat my earlier request.  Just forget about the whole log/unlog
STORE_WITH_LOG mess.  We will (eventually) put a general axis-mapping
mechanism in place, at which point we can worry about removing old
messy code.

> I'm wrapping up a prototype right now in which all data is saved and can 
be recalled.  However, I punted on my original approach of leaving 
->points in un-transformed format.

They must be stored un-transformed.  Nothing else makes sense.

> So 4th and 15... The question is then whether there is a good place to 
tap into the original data.

Could you please back off at bit, and explain what's wrong with 
just using the data as it is now stored?  Disregard log/unlog.
I don't see any need to re-work the input or data storage.
OK, the range checking could use cleaning up, particularly the axis
reversal tangle,  but that is a tangential issue and can 
be tackled separately if necessary.

My thought is that what we could do is introduce a new layer of
coordinate transform routines, one that maps the input data through
the relevant axis mapping onto the linear coordinate system
that we use now.   I think this can be developed cleanly without
altering any existing code, and then slotted in via extra mapping
calls in a small number of places like map_position() and friends. 

> I think there is.  Rather than save the ->points, we can save the v[]'s 
and j's (and user specs).  That array is just as compact at the ->points 
array.  And if we save that, we can stuff that back through the system 
pretty much at the start of processing.  So, right near df_readline we can 
put a mechanism that stores or retrieves the v's.  Seems to work.  I'll 
post that soon. 

But why would you want to do this?

> Or do you think the point to tap into the data is where I described? 

Nope. At this point I see no advantage to it at all.
That's why I ask what you see wrong with the current data flow.

-- 
Ethan A Merritt

Re: Small technicality on dynarray

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

Ethan A Merritt wrote:
> On Saturday 30 June 2007 15:47, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>On Saturday 30 June 2007 12:30, Daniel J Sebald wrote:
>>>
>>>Speak up quickly then.
>>>I was heading towards putting it in CVS as-is.
>>>Did you find a problem with it?
>>
>>Hold on a bit.  I've got something I think you will like that could be 
> 
> integrated into what you have fairly easily.
> 
> You seem to be working towards something orthogonal. I don't think it
> really has anything to do with my patch.

No, I said I punted on the more orthogonal approach.  This will fit nicely.


>>I don't like that one has to have two forms of "range check", the 
> 
> STORE_WITH_LOG_AND_UPDATE_RANGE and the what is in the patch.  Also, I 
> think it is much preferred if there is no restriction on "refreshing" if 
> log scale is changed.  That's a nice feature.  Losing negative data 
> because of the log scale is almost a no-go for me.
> 
> I repeat my earlier request.  Just forget about the whole log/unlog
> STORE_WITH_LOG mess.  We will (eventually) put a general axis-mapping
> mechanism in place, at which point we can worry about removing old
> messy code.

The new patch has nothing to do with STORE_WITH_LOG.  You'll like it.  Give me 15 minutes...

> 
> 
>>I'm wrapping up a prototype right now in which all data is saved and can 
> 
> be recalled.  However, I punted on my original approach of leaving 
> ->points in un-transformed format.
> 
> They must be stored un-transformed.  Nothing else makes sense.
> 
> 
>>So 4th and 15... The question is then whether there is a good place to 
> 
> tap into the original data.
> 
> Could you please back off at bit, and explain what's wrong with 
> just using the data as it is now stored?  Disregard log/unlog.
> I don't see any need to re-work the input or data storage.
> OK, the range checking could use cleaning up, particularly the axis
> reversal tangle,  but that is a tangential issue and can 
> be tackled separately if necessary.

Why disregard the log/unlog?  The log and unlog mouse feature is one of the nicer ones.

> 
> My thought is that what we could do is introduce a new layer of
> coordinate transform routines, one that maps the input data through
> the relevant axis mapping onto the linear coordinate system
> that we use now.

Exactly, would be nice.  That's not the issue here.


>>I think there is.  Rather than save the ->points, we can save the v[]'s 
> 
> and j's (and user specs).  That array is just as compact at the ->points 
> array.  And if we save that, we can stuff that back through the system 
> pretty much at the start of processing.  So, right near df_readline we can 
> put a mechanism that stores or retrieves the v's.  Seems to work.  I'll 
> post that soon. 
> 
> But why would you want to do this?

So that the original data is not lost.  STORE_VALUE_WITH currently tosses the data.  If there are negative coordinate values in the data stream and the data is first transformed and stored to logarithmic scale, what will you do with the negative coordinates beyond tossing them out?  Not transform them and mark them as UNDEFINED and test for this when reverse mapping?

There is quite of bit of code between reading it in and storing it.  Fitting alters the data.  Maybe splines isn't on option outside of the plot/splot command, but I'm just worried that unless we save the raw, unprocessed data at some point we'll be in a bind.

Dan

Re: Small technicality on dynarray

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

Daniel J Sebald wrote:

> The new patch has nothing to do with STORE_WITH_LOG.  You'll like it.  Give me 15 minutes...

OK, took more than 15 minutes.  I've put the patch on sourceforge.  For the time being I just put in a bogus variable to control refresh/replot.  The way it works is the first plot command reads from a file and from there forward the "replot" acts like "refresh".  I've highlighted in the code the hunks that should be discarded to stop that prototype behavior.  Both plot and splot work.

I still don't see how anything but saving the raw data (either in v's and j's or ->points) will ensure full flexibility.  There is the log/inverse scales not mapping from the whole real line.  But also the splines complicates things.  If one chooses log scale and plots something with splines the data is altered.  Then a "unset logscale x; refresh"--if there is a method for unmapping the data back to linear scale--will be operating on modified data and not be back to the original data.

Dan

Re: Small technicality on dynarray

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

On Saturday 30 June 2007 16:55, Daniel J Sebald wrote:
> > But why would you want to do this?
> 
> So that the original data is not lost.  STORE_VALUE_WITH currently tosses the data.

It does not.
We are ignoring the log/unlog case, because it will go away.

> There is quite of bit of code between reading it in and storing it.  

Please quote code sections.  I see none.
 

-- 
Ethan A Merritt

Re: Small technicality on dynarray

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

Ethan A Merritt wrote:
> On Saturday 30 June 2007 16:55, Daniel J Sebald wrote:
> 
>>>But why would you want to do this?
>>
>>So that the original data is not lost.  STORE_VALUE_WITH currently tosses the data.
> 
> 
> It does not.

It currently does.

	if (VALUE<0.0) {						  \
	    TYPE = UNDEFINED;						  \
	    UNDEF_ACTION;						  \
	    break;							  \

breaks before storing the data.

> We are ignoring the log/unlog case, because it will go away.

How will it go away?  That's what I'm trying to point out.  Are you saying that one will not be able to use mouse log/unlog scale and "set logscale x", etc. unless the data file is present?  (I just tried the patch and that's currently how it works.)  We agree that isn't acceptable, long term (forget the fact this may be incremental), right?

So, the question is then how does one get from where the patch is to log/unlog working correctly?  I just tried something similar to this by saving the data without taking the log.  I punted because, yes a bit of work with all the uses here and there, but mainly because that curve-fitting code that alters the data.

I've come to the conclusion that saving the v's and j's is preferred.  Sure there are other things to fix like the scale (I think 1/x is a perfectly fine and nice feature).  But the curve fitting code, and having two versions of ranging code to keep track of are detrimental in comparison to using a hunk of memory for the original data.

The j/v's solution is actually pretty solid because of the code clean up we've done.  Data can only come in through df_readline() and that is where we are tapping into things.  On refresh, just push the code through the very beginning of the system and it doesn't matter if there was curve fitting code in between.


>>There is quite of bit of code between reading it in and storing it.  
> 
> 
> Please quote code sections.  I see none.

I meant between reading and plotting, sorry.  E.g., splines and who knows what else?

Dan

Re: Small technicality on dynarray

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

On Saturday 30 June 2007 19:49, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > On Saturday 30 June 2007 16:55, Daniel J Sebald wrote:
> > 
> >>>But why would you want to do this?
> >>
> >>So that the original data is not lost.  STORE_VALUE_WITH currently tosses the data.
> > 
> > 
> > It does not.
> > We are ignoring the log/unlog case, because it will go away.
> 
> It currently does.
> 
> 	if (VALUE<0.0) {						  \
> 	    TYPE = UNDEFINED;						  \
> 	    UNDEF_ACTION;						  \
> 	    break;							  \

Only for logscale data.  I said to ignore that.

> How will it go away?
> Are you saying that one will not be able to use mouse log/unlog scale 
> and "set logscale x", etc. unless the data file is present?

I am saying that totally separate from this patch, we should implement
a method of axis-scaling that is general enough to handle log scale as
just one more scaling operation.  When that is in place, input data will
be stored as read in, and the existing special case code for log scale
can go away.

> I punted ... mainly because that curve-fitting code that alters the data.  

I must have missed that. Where?

> I've come to the conclusion that saving the v's and j's is preferred.

I think I know what you mean by v[], but who are the j's?
Anyhow, I doubt it.  

Counter-example 1:  Consider the dumb but perfectly legal case of an input file
with 100 columns, and the command 'plot "foo" using ($1+$2+$3+...+$100)'
Why should we store all 100 columns, when only one value will be used?

Counter-example 2:  'splot "foo" using 1:2:(system("date")) with labels'
Not that it makes any sense to plot the date, but the point is you cannot
assume that the value of v[3] will be the same next time you execute the plot
command.  And if it isn't, then what have you gained by saving it?

> The j/v's solution is actually pretty solid because of the code clean up we've done.  
> Data can only come in through df_readline() and that is where we are tapping into things.  
> On refresh, just push the code through the very beginning of the system and it 
> doesn't matter if there was curve fitting code in between.   

Are you suggesting that the curve-fitting would be re-done, and perhaps change,
during a zoom operation?  That sounds highly undesirable to me.
And if it doesn't change, then why go back and do it again?

> >>There is quite of bit of code between reading it in and storing it.  
> > 
> > Please quote code sections.  I see none.
> 
> I meant between reading and plotting, sorry.  E.g., splines and who knows what else?

Code sections please.


-- 
Ethan A Merritt

Re: Small technicality on dynarray

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

Ethan A Merritt wrote:
> On Saturday 30 June 2007 19:49, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>On Saturday 30 June 2007 16:55, Daniel J Sebald wrote:
>>>
>>>
>>>>>But why would you want to do this?
>>>>
>>>>So that the original data is not lost.  STORE_VALUE_WITH currently tosses the data.
>>>
>>>
>>>It does not.
>>>We are ignoring the log/unlog case, because it will go away.
>>
>>It currently does.
>>
>>	if (VALUE<0.0) {						  \
>>	    TYPE = UNDEFINED;						  \
>>	    UNDEF_ACTION;						  \
>>	    break;							  \
> 
> 
> Only for logscale data.  I said to ignore that.
> 
> 
>>How will it go away?
>>Are you saying that one will not be able to use mouse log/unlog scale 
>>and "set logscale x", etc. unless the data file is present?
> 
> 
> I am saying that totally separate from this patch, we should implement
> a method of axis-scaling that is general enough to handle log scale as
> just one more scaling operation.  When that is in place, input data will
> be stored as read in, and the existing special case code for log scale
> can go away.
> 
> 
>>I punted ... mainly because that curve-fitting code that alters the data.  
> 
> 
> I must have missed that. Where?

It's this hunk of code.  I really only looked at this closely the other day:

                /* sort */
                switch (this_plot->plot_smooth) {
                /* sort and average, if the style requires */
                case SMOOTH_UNIQUE:
                case SMOOTH_FREQUENCY:
                case SMOOTH_CSPLINES:
                case SMOOTH_ACSPLINES:
                case SMOOTH_SBEZIER:
                    sort_points(this_plot);
                    cp_implode(this_plot);
                case SMOOTH_NONE:
                case SMOOTH_BEZIER:
                default:
                    break;
                }
                switch (this_plot->plot_smooth) {
                /* create new data set by evaluation of
                 * interpolation routines */
                case SMOOTH_FREQUENCY:
                    gen_interp_frequency(this_plot);
                    break;
                case SMOOTH_CSPLINES:
                case SMOOTH_ACSPLINES:
                case SMOOTH_BEZIER:
                case SMOOTH_SBEZIER:
                    gen_interp(this_plot);
                case SMOOTH_NONE:
                case SMOOTH_UNIQUE:
                default:
                    break;
                }


> 
>>I've come to the conclusion that saving the v's and j's is preferred.
> 
> 
> I think I know what you mean by v[], but who are the j's?
> Anyhow, I doubt it.  

    while ((j = df_readline(v, max_cols)) != DF_EOF) {

The j indicates how many columns were read, upon which these big case statements are tested.  Perhaps it is constant, but it may not necessarily be so.  It's like another variable (with very low entropy).

> 
> Counter-example 1:  Consider the dumb but perfectly legal case of an input file
> with 100 columns, and the command 'plot "foo" using ($1+$2+$3+...+$100)'
> Why should we store all 100 columns, when only one value will be used?

No.  v is an array of MAXDATACOLS, which is 7.  So if we save those, along with j that is 8 elements, counting j as a double.  The point structure has x, y, z, xlow, xhigh, ylow, yhigh, and type.  Again 8 elements.  We don't save 100 columns.  If the user want's to get at the other columns in the data file he or she will have to issue a new "plot" command in which case "refresh" is no longer relevant.  Saving a copy of the points, or a copy of the v's and j's is roughly the same.

> 
> Counter-example 2:  'splot "foo" using 1:2:(system("date")) with labels'
> Not that it makes any sense to plot the date, but the point is you cannot
> assume that the value of v[3] will be the same next time you execute the plot
> command.  And if it isn't, then what have you gained by saving it?

The v's and j's get recorded over if there is a new "plot".

But the labels thing is something I forgot about.  This is the kind of thing that really poses a problem: multiply entry paths for data.  Had a label been passed over as a series of encoded points somehow through df_readline, that'd been fine.  Like the matrix data coming in from a different pathway in the plot3d.c case, patching things together like that limits flexibility.  But I'm sure the "with labels" case could be handled in a similar way, I don't know.

> 
> 
>>The j/v's solution is actually pretty solid because of the code clean up we've done.  
>>Data can only come in through df_readline() and that is where we are tapping into things.  
>>On refresh, just push the code through the very beginning of the system and it 
>>doesn't matter if there was curve fitting code in between.   
> 
> 
> Are you suggesting that the curve-fitting would be re-done, and perhaps change,
> during a zoom operation?  That sounds highly undesirable to me.
> And if it doesn't change, then why go back and do it again?

No, that wouldn't be desirable, perhaps.  (Setting different smoothing parameters perhaps would be useful.)  But the issue is the ramification on log/unlog.  Say the command is one of the examples in "help acsplines" and we have logscale set:

set logscale x
sw(x,S)=1/(x*x*S)
plot 'data_file' using 1:2:(sw($3,100)) smooth acsplines

The manner in which gnuplot is set up is that data is translated to the log scale and saved.  Then splines smoothing is applied to the data.  Let L() represent the logarithmic translation.  Let S() be the mapping resulting from splines.  L() is invertible, S() isn't necessarily so, and even if it were, knowing the inversion would be difficult.  So, at this point we have S(L(.)).  Now, if the user unwittingly types 'l' in the plot or 'unset logscale x' at the command line then the inverse transform you've suggested, call that E() for exponentiation, then we get  E(S(L(.))).  In general E(S(L(.))) != S(E(L(.))), and the latter is what would happen if the user type:

unset logscale x
sw(x,S)=1/(x*x*S)
plot 'data_file' using 1:2:(sw($3,100)) smooth acsplines

This is why I'm saying be careful.  Maybe they shouldn't be the same.  But if people are going to use these features for scientific endeavor they need to know exactly what is happening with the data.  I think there would be a little bit of confusion in that case.  Whatever you do, just make sure to think this all the way through before getting to committed on the implementation.

Dan

Re: Small technicality on dynarray

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

Daniel J Sebald wrote:

> No.  v is an array of MAXDATACOLS, which is 7.  So if we save those,
> along with j that is 8 elements, counting j as a double.  The point
> structure has x, y, z, xlow, xhigh, ylow, yhigh, and type.  Again 8
> elements.  We don't save 100 columns.  If the user want's to get at
> the other columns in the data file he or she will have to issue a new
> "plot" command in which case "refresh" is no longer relevant.  Saving
> a copy of the points, or a copy of the v's and j's is roughly the
> same.

Also, if memory space is a concern, we could keep track of the largest value of 'j' throughout the data read then condense the dynarray to one of narrower width by tossing out columns max(j)+1:7 which didn't contain any used data.  We can't necessarily do that with the point coordinates stored with the plot.  The xlow, yhigh, etc. could have been used for something special according to the case statement.  So from that standpoint saveing j's and v's is maybe one of the more condensed records of the data.

The v/j dynarray (that rhymes!) has its advantages, for what it's worth.

Dan