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

bug at make check in gnuplot 4.3

[Christoph J. <jun...@mp...>]

Dear all,

using "make check" together with  --program-suffix does not work,
because "./src/gnuplot_x11<the suffix>" is missing.

A quick workaround is to link gnuplot_x11 to "gnuplot_x11<the suffix>"!


By the way, very useful program, science would be indigent without it.

Bye,

Christoph

-- 
Christoph Junghans
Max Planck Institute for Polymer Research
Theory Group
POBox 3148
D 55021 Mainz, Germany

Phone: +49 6131 379 335
Web: http://www.mpip-mainz.mpg.de/~junghans

Re: Is there a way of converting plot coords to graph coords?

[j1n3l0 <nel...@gm...>]

Hans-Bernhard Br=C3=B6ker wrote:
>=20
> Ethan Merritt wrote:
>> Do we have a utility routine somewhere that would convert=20
>> plot coordinates to graph or screen coordinates?
>=20
> No.  axis.h:AXIS_MAP() and AXIS_MAPBACK transform from data=20
> ('first'/'second') coordinates to terminal coordinates and back.
> Going from terminal to 'screen' is trivial (just divide by term->xmax).
> Transforming to 'graph' from data coordinates is quite easy: it's a=20
> direct linear transformation using the axis_array[].min and .max
> values.
>=20

This thread is over a year old but I am in need of a solution. I am trying
to get the screen coordinates from my graph coordinates so I can generate a=
n
image map of my plots.

Is there a way to find out the values of {l|t|b|r}margins in pixels?
Currently the best I can do is use the "show margin" command, which just
tells me that the values are computed automatically, not what the values
are. If I knew the absolute values of these (in pixels) I could find the
coordinates of each point on my graph.

I think this would go some way to helping me solve my problem.



--=20
View this message in context: http://www.nabble.com/Is-there-a-way-of-conve=
rting-plot-coords-to-graph-coords--tf1832453.html#a11499886
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

TikZ-Terminal/Howto write terminals

[Johannes M. <joh...@gm...>]

Hi ...

I read in the archive of this list, that a terminal for TikZ is being
worked on. Coincidently at about the same time I also hacked a very simple
terminal for TikZ.

It was mt first time to hack around in gnuplot code. I have to admit, that
I am a little disappointed by the terminal interface as I find it a bit too
lowlevel. But maybe I am just missing something.

A big advantage of TiKZ that I want to use is the node system. This allows
you to put text next to certain points (below, above, ...) without having
to specify the exact coordinates. Especially you don't have to know about
the size of the text, font metrics and the like, as TikZ and TeX will to
that for you.

For example a tick mark could be drawn by the following line:

\draw (1,0) node[below]{1} -- ++(0,0.1);

The problem now is, that the terminal is not told about all this stuff. It
is only told to draw lines, texts, points, polygons and stuff.

What I like to have is access to some struct, which has the information on
the plot, e.g. what the labels are, how the ticks are to be plotted, the
titles of the plots, etc.

Then I can output the TiKZ code to draw the plot skeleton, i.e. box, axes,
labels, ticks, tick marks, legends and so on. Then just the plots
themselfes should be plotted the way it is implemented now by telling the
terminal to draw simple lines.

Is there any possibility to archive this?

Thank you.


joh

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

1/0 - problem while rendering with lines

[Martin G. <mg...@in...>]

Hi all,

I'm using Gnuplot:
Version 4.3 patchlevel 0
last modified June 2007
System: Darwin 8.10.1

And i got rendering problems if i use data-clipping with lines and =20
linespoint render mode

plot 'AGdata-test.dat' using 4:($3=3D=3D1?$5:1/0) with lines,\
'AGdata-test.dat' using 8:($7=3D=3D1?$9:1/0) with lines,\
'AGdata-test.dat' using 12:($11=3D=3D1?$13:1/0) with lines

This does not draw 3 connected 'paths' between the valid value. =20
Instead multiple broken
line segments are drawn.


plot 'AGdata-test.dat' using 4:($3=3D=3D1?$5:1/0) with points,\
'AGdata-test.dat' using 8:($7=3D=3D1?$9:1/0) with points,\
'AGdata-test.dat' using 12:($11=3D=3D1?$13:1/0) with points

This in contrast seems do draw all valid point. So i suppose that =20
there is something wrong
with lines.

Can you please provide me with a patch or workarround to this problem.
I attached the data-file for testing.

Kind regards
Martin Giersich




----------------------------------------------------
Dipl.-Inf. Martin Giersich
Universit=C3=A4t Rostock
IEF - IFI - MMIS
www.informatik.uni-rostock.de/mmis

Fon: +49-381-498-7514
Fax: +49-381-498-7522

mar...@in...
----------------------------------------------------
=EF=BF=BC

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

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

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

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

[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

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

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

[<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:
> 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: [Gnuplot-info] question for extension definition range

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

Francky Leyn wrote:

> I have a problem with ranges.

No.  You have a problem with samples.  You want infinite resolution from 
a finite computer.  But gnuplot is not an analytical maths engine, and 
has no aspirations of becoming one.

If you really have to have your samples at non-equidistant positions, 
you can have that right now: use parametric mode, and set up whatever 
mapping from the original sampling to the x axis you need, e.g.:

	set param
	set trange [0:20]
	fx(t)=(t<=10)?t**2:100+(t-10)**2
	set samples 101
	p fx(t), sin(fx(t)/15) with linespoints