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

List slow

[<pl...@pi...>]

Hi,

usually I find I get my own posts back within a few minutes. In the last 
few days it's been taking many hours.

Others see this, or is it local?

Peter.

Re: NaNs not propagating

[<pl...@pi...>]

On 11/04/14 05:14, sfeam wrote:
> By the way, in the definition you show for function integ()
>
> integ(x)=(int_last==0)?(NaN,int_last=x):(int_last=int_last+x)
>
> the NaN has no effect whatsover because it is on the left
>
> side of a comma. That means the function reduces to
>
> integ(x) = (int_last = int_last+x)
>
> Ethan
>

Since this is a public archived list, I thought I ought to provide a 
more functionally correct version, just in case anyone uses it as an 
example.

integ(x)=(!istarted)?(istarted=1,int_last=x):(int_last=int_last+x)
  plot istarted=0,  datafile  using 1:(integ($2-44)) with lines


Now what I really need to do is skip the fn call if there is invalid 
data, so I try to trap the NaN in column 2:

  plot istarted=0,  datafile  using 1:(($2==NaN)?NaN:(integ($2-44))) 
with lines

This produces the same unexpected results as before and the test is 
never true. Another consequence of NaNs not propagating.

What is the correct way to trap this condition?

(isNaN($2))   undefined function: isNaN
($2==NaN)   never true
($2==0)   not true for NaN in col 2
(exists($2) always true, even for NaN

Is there currently a test condition that will trap NaN in the datafile ?

Peter.

Re: NaNs not propagating

[sfeam <sf...@us...>]

On Monday, 03 November 2014 06:45:48 PM pl...@pi... wrote:
> Hi,
> 
> I seem have a problem with NaN not propagating to function calls.
> 
> 
> gnuplot>
> 
>   integ(x)=(int_last==0)?(NaN,int_last=x):(int_last=int_last+x)
> 
> plot int_last=0, "-" u 1:(integ($2-44)) w l
> input data ('e' ends) > 1 1
> input data ('e' ends) > 2 2
> input data ('e' ends) > 3 NaN
> input data ('e' ends) > 4 4
> input data ('e' ends) > 5 5
> input data ('e' ends) > e
> 
> gnuplot> print int_last+NaN
> NaN
> 
> 
> This gives a straight line with a break which means that the third line 
> is evaluating NaN as zero and passing -44 to the function.
> 
> I was expecting the argument (NaN-44) to pass NaN to the function which 
> would in turn return and assign a NaN  leaving all further points 
> unplotted.
> 
> Bug or feature ?

I think it rates as a bug.

When the data is read in, a using spec that evaluates to NaN is
flagged as "undefined".  This is sufficient for the purpose of
plotting that one point, but as you have discovered it doesn't
address side-effects of the evaluation.  Arguably if the point
itself is undefined then it is reasonable to say that any 
side-effects are also undefined, but it's less of a surprise
if this makes the side-effect expressions evaluate to NaN also.

I'll whip up a fix for 5.0 and 5.1.



By the way, in the definition you show for function integ()
  integ(x)=(int_last==0)?(NaN,int_last=x):(int_last=int_last+x)
the NaN has no effect whatsover because it is on the left
side of a comma.  That means the function reduces to

  integ(x) = (int_last = int_last+x)

	Ethan

NaNs not propagating

[<pl...@pi...>]

Hi,

I seem have a problem with NaN not propagating to function calls.


gnuplot>

  integ(x)=(int_last==0)?(NaN,int_last=x):(int_last=int_last+x)

plot int_last=0, "-" u 1:(integ($2-44)) w l
input data ('e' ends) > 1 1
input data ('e' ends) > 2 2
input data ('e' ends) > 3 NaN
input data ('e' ends) > 4 4
input data ('e' ends) > 5 5
input data ('e' ends) > e

gnuplot> print int_last+NaN
NaN


This gives a straight line with a break which means that the third line 
is evaluating NaN as zero and passing -44 to the function.

I was expecting the argument (NaN-44) to pass NaN to the function which 
would in turn return and assign a NaN  leaving all further points 
unplotted.


Bug or feature ?

Regards, Peter.

Fwd: Re: Configure modifies the file term/lua/gnuplot-tikz.help

[Hans-Bernhard B. <HBB...@t-...>]

[keep forgetting to CC: list...]

Am 02.11.2014 um 01:20 schrieb Daniel J Sebald:
> Running "configure" appears to modify the contents of gnuplot-tikz.help.

Close, but no cigar.  It's not configure, but make that does that.
There's a build rule in term/Makefile.am that updates this file if it's
older than gnuplot-tikz.lua.

The usual rules of version control in the gnuplot project are that we
don't hold any generated files in the repository (thus the need for
"prepare").  According to those rules this file should not be in CVS to
begin with.

Configure modifies the file term/lua/gnuplot-tikz.help

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

Running "configure" appears to modify the contents of gnuplot-tikz.help. 
  The consequence of that is unwanted diff hunks when creating a patch. 
  Is there a way to use conditional macros on this help text rather than 
modifying the file?

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

On Sat, 1 Nov 2014 17:15:55 +0900
"Jun T." <tak...@kb...> wrote:

> I don't feel it ugly to have separate buttons for Copy and Export.

I would agree!

> 
> If I can copy by keyboard shortcut (ctr-C etc.) then I don't need
> a separate button for Copy, of course. But If that is not possible,
> then I prefer a separate button for Copy rather than to open a dialog 
> and push one or more buttons there.
> 
> On Mac, copy/paste in pdf is supported by many applications.
> On Windows, many applications may support EMF but I'm not sure.
> 
> I personally use copy/paste in pdf (by aqua terminal) much more
> frequently than save into file. But each user may have his/her own
> way of using gnuplot.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Proposal: Saving graphs from Qt and wxt terminals

[Jun T. <tak...@kb...>]

I don't feel it ugly to have separate buttons for Copy and Export.

If I can copy by keyboard shortcut (ctr-C etc.) then I don't need
a separate button for Copy, of course. But If that is not possible,
then I prefer a separate button for Copy rather than to open a dialog 
and push one or more buttons there.

On Mac, copy/paste in pdf is supported by many applications.
On Windows, many applications may support EMF but I'm not sure.

I personally use copy/paste in pdf (by aqua terminal) much more
frequently than save into file. But each user may have his/her own
way of using gnuplot.

Re: Proposal: Saving graphs from Qt and wxt terminals

[Hans-Bernhard B. <HBB...@t-...>]

Am 31.10.2014 um 20:21 schrieb Ethan A Merritt:
> On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:

>  > It would be also great if I can copy the plot just by typing cmd-C (Mac)
>
>  > or ctrl-C (Windows/Unix, or other key if ctrl-C can cause interrupt).
>
> Petr Mikulik mentioned that there is an undocumented command
> "screendump". I did not know about this.

Well, it's not strictly undocumented.  The documentation is just stuck 
away inside the chapter about the (so far) only terminal driver that 
command exists in: see "help windows printing" (or term/win.trm around 
line 1120, if you don't have a Windows version of gnuplot at hand).

But if a feature like this is extended to other drivers, the command and 
its documentation should probably move up into "help commands"

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/31/2014 03:16 PM, Ethan A Merritt wrote:
> On Friday, 31 October, 2014 14:50:18 Daniel J Sebald wrote:
>> On 10/31/2014 02:21 PM, Ethan A Merritt wrote:
>>> On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:
>>>
>>>>   I haven't been following this long thread, but
>>>
>>>>
>>>
>>>>   2014/10/31 09:03, Ethan A Merritt<sf...@us...>  wrote:
>>>
>>>>   >  I added it to cvs for 5.1 but I'd like to hear whether it does or
>>>
>>>>   >  doesn't work on Windows and OSX
>>>
>>>>
>>>
>>>>   I tried cvs HEAD and the Export to File works fine on OSX,
>>>
>>>>   but the Copy to clipboard (pasteboard) button is now gone.
>>>
>>>>   Is it possible to have both?
>>>
>>> I agree. I was hoping that someone, maybe Dan Sebald, can find a
>>>
>>> clever way to make "clipboard" act like a filetype in the selection widget.
>>>
>>>>   When copying the plot to the clipboard, I prefer PDF format rather than
>>>
>>>>   PNG (either on wxt or qt). Is this possible?
>>>
>>> I don't know.
>>
>> I think it would be possible to derive a custom button from the standard
>> button and add a right mouse click handler to the event table.
>
> That's more complicated that I had in mind.

This is actually one of the easier approaches I've come across having 
dug into WXT a bit.


> I was thinking that "clipboard" would be a label in the file-selector widget
> (that part is easy), but unlike the others it would not require a file name
> (that is the part I got stuck on).  I can make it copy to the clipboard just
> fine, but only if I first click on or type some junk file name.

Yeah, the dialog must have some type of filename, otherwise it doesn't 
pass the wxID_OK event further on to the dialog.  Unfortunately, the 
logic for this is in the particular tookkits and not in a generic 
location where one could make an easy change.  Here's GTK, for example:

https://github.com/LuaDist/wxwidgets/blob/master/src/gtk/filedlg.cpp

WXT has a bit of limitation in the sense that it is difficult to program 
in front of a widget operation.  There's access after a widget has done 
something and indicates an event, but not before.  E.g., I'm finding it 
quite difficult to get at the program flow before the "Save" button does 
its file-exists check.


>> How
>> about right mouse click on the clipboard icon opens a dialog or drop
>> down menu that configures the image format saved to file?  To make
>> things more clear, the format, e.g., "png", "pdf", "svg" could be
>> superimposed on the clipboard icon with the format selection.  And maybe
>> change the tool tip to read "Left Click: Copy, Right Click: Configure".
>
> Maybe.  My inclination is that if you want a file then Export-to-File is
> the right thing to look for.  The clipboard is typically used for cut-and-paste,
> and I don't think many program are expected a paste operation to
> contain pdf or svg.

I agree with that.  But there are a number of formats for which 
cut-and-paste will work.


> Or we could just put the Clipboard icon back as a separate widget.
> That is easy but IMHO kind of ugly compared to grouping all the
> export options in a single place.

That was what I was thinking when I queried the discussion list.  The 
clipboard icon would be present, but it could be easily configured for 
the image format.  Copying to clipboard should be a one-step operation. 
  Opening a dialog and then doing another action to copy to clipboard 
seems too much.

But if one were to go that route, maybe adding a third button to the 
file dialog, i.e., "Cancel", "Copy To Clipboard" and "Save" would be the 
most straightforward.  That then is just one additional step (provided 
the file type remains sticky, for which I just about have a patch ready).

Think it over.  I can program something this weekend.

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan A M. <sf...@us...>]

On Friday, 31 October, 2014 14:50:18 Daniel J Sebald wrote:
> On 10/31/2014 02:21 PM, Ethan A Merritt wrote:
> > On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:
> >
> >>  I haven't been following this long thread, but
> >
> >>
> >
> >>  2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote:
> >
> >>  > I added it to cvs for 5.1 but I'd like to hear whether it does or
> >
> >>  > doesn't work on Windows and OSX
> >
> >>
> >
> >>  I tried cvs HEAD and the Export to File works fine on OSX,
> >
> >>  but the Copy to clipboard (pasteboard) button is now gone.
> >
> >>  Is it possible to have both?
> >
> > I agree. I was hoping that someone, maybe Dan Sebald, can find a
> >
> > clever way to make "clipboard" act like a filetype in the selection widget.
> >
> >>  When copying the plot to the clipboard, I prefer PDF format rather than
> >
> >>  PNG (either on wxt or qt). Is this possible?
> >
> > I don't know.
> 
> I think it would be possible to derive a custom button from the standard 
> button and add a right mouse click handler to the event table. 

That's more complicated that I had in mind.
I was thinking that "clipboard" would be a label in the file-selector widget
(that part is easy), but unlike the others it would not require a file name
(that is the part I got stuck on).  I can make it copy to the clipboard just
fine, but only if I first click on or type some junk file name.

> How 
> about right mouse click on the clipboard icon opens a dialog or drop 
> down menu that configures the image format saved to file?  To make 
> things more clear, the format, e.g., "png", "pdf", "svg" could be 
> superimposed on the clipboard icon with the format selection.  And maybe 
> change the tool tip to read "Left Click: Copy, Right Click: Configure".

Maybe.  My inclination is that if you want a file then Export-to-File is
the right thing to look for.  The clipboard is typically used for cut-and-paste,
and I don't think many program are expected a paste operation to 
contain pdf or svg.

Or we could just put the Clipboard icon back as a separate widget.
That is easy but IMHO kind of ugly compared to grouping all the 
export options in a single place.


	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/31/2014 02:21 PM, Ethan A Merritt wrote:
> On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:
>
>>  I haven't been following this long thread, but
>
>>
>
>>  2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote:
>
>>  > I added it to cvs for 5.1 but I'd like to hear whether it does or
>
>>  > doesn't work on Windows and OSX
>
>>
>
>>  I tried cvs HEAD and the Export to File works fine on OSX,
>
>>  but the Copy to clipboard (pasteboard) button is now gone.
>
>>  Is it possible to have both?
>
> I agree. I was hoping that someone, maybe Dan Sebald, can find a
>
> clever way to make "clipboard" act like a filetype in the selection widget.
>
>>  When copying the plot to the clipboard, I prefer PDF format rather than
>
>>  PNG (either on wxt or qt). Is this possible?
>
> I don't know.

I think it would be possible to derive a custom button from the standard 
button and add a right mouse click handler to the event table.  How 
about right mouse click on the clipboard icon opens a dialog or drop 
down menu that configures the image format saved to file?  To make 
things more clear, the format, e.g., "png", "pdf", "svg" could be 
superimposed on the clipboard icon with the format selection.  And maybe 
change the tool tip to read "Left Click: Copy, Right Click: Configure".

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan A M. <sf...@us...>]

On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:
> I haven't been following this long thread, but
> 
> 2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote:
> > I added it to cvs for 5.1 but I'd like to hear whether it does or
> > doesn't work on Windows and OSX
> 
> I tried cvs HEAD and the Export to File works fine on OSX,
> but the Copy to clipboard (pasteboard) button is now gone.
> Is it possible to have both?

I agree. I was hoping that someone, maybe Dan Sebald, can find a
clever way to make "clipboard" act like a filetype in the selection widget.
 
> When copying the plot to the clipboard, I prefer PDF format rather than
> PNG (either on wxt or qt). Is this possible?

I don't know.

> It would be also great if I can copy the plot just by typing cmd-C (Mac)
> or ctrl-C (Windows/Unix, or other key if ctrl-C can cause interrupt).

Petr Mikulik mentioned that there is an undocumented command
"screendump".  I did not know about this.  If "screendump" works
on your system, then I would expect that you can bind it to whatever
key you like using the "bind" command.

    bind "ctrl-c" "screendump"

But right now I think this command must only exist for Windows.
Petr said:

> This reminds me: there is an undocumented command for printing
> the current graph (i.e. for showing a Print(er) dialog):
>         screendump
> This, however, works for the "windows" terminal only, otherwise
> gnuplot says
>         screendump not implemented

	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Jun T. <tak...@kb...>]

I haven't been following this long thread, but

2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote:
> I added it to cvs for 5.1 but I'd like to hear whether it does or
> doesn't work on Windows and OSX

I tried cvs HEAD and the Export to File works fine on OSX,
but the Copy to clipboard (pasteboard) button is now gone.
Is it possible to have both?

When copying the plot to the clipboard, I prefer PDF format rather than
PNG (either on wxt or qt). Is this possible?

It would be also great if I can copy the plot just by typing cmd-C (Mac)
or ctrl-C (Windows/Unix, or other key if ctrl-C can cause interrupt).

Re: Should gnuplot become a programming environment?

[Ethan A M. <sf...@us...>]

On Friday, 31 October, 2014 17:38:00 pl...@pi... wrote:
> On 10/30/14 22:42, Ethan A Merritt wrote:
> >
> > On Thursday, 30 October, 2014 12:58:54 pl...@pi... wrote:
> >>   Also the odd need to use commas in place of the usual semicolon
> >>   in defining functions seems inconsistent and could be limiting as
> >>   things move forwards.
> >
> > Are you referring to the comma operator for serial evaluation?
> > That is taken straight from C, C++, perl, javascript and no doubt
> > other languages as well.
> >
> >      http://en.wikipedia.org/wiki/Comma_operator
> >
> >
> > 	Ethan
> >
> 
> My apologies, apparently I was successfully using this feature without 
> realising its correct syntax definition. Where is it documented? 

gnuplot> help expressions operators binary

> help comma does not seem relevant.

True, but we don't have sections for "help plus sign" or "help equals" either.

I think it is covered best by the first  sentences of "help expressions"

gnuplot> help expression
     In general, any mathematical expression accepted by C, FORTRAN, 
     Pascal, or BASIC is valid.  The precedence of these operators is
     determined by the specifications of the C programming language.  

But this statement is not entirely true.  Pascal  operators  <>  div  mod
are not recognized.   And gnuplot only learned about the bit shift operators
>> and << recently.

	Ethan

> I was thinking the following two uses were the same thing. It seems the 
> first is a separator, second is an operator:
> 
> gnuplot> plot a=1,b=2, sin(x)
> fn(x)=( a=1,b=2, sin(x) )
> 
> Peter.

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

On Fri, 31 Oct 2014 17:38:00 +0100
pl...@pi... wrote:

> On 10/30/14 22:42, Ethan A Merritt wrote:
> >
> > On Thursday, 30 October, 2014 12:58:54 pl...@pi... wrote:
> >>   Also the odd need to use commas in place of the usual semicolon
> >>   in defining functions seems inconsistent and could be limiting as
> >>   things move forwards.
> >
> > Are you referring to the comma operator for serial evaluation?
> > That is taken straight from C, C++, perl, javascript and no doubt
> > other languages as well.
> >
> >      http://en.wikipedia.org/wiki/Comma_operator
> >
> >
> > 	Ethan
> >
> 
> My apologies, apparently I was successfully using this feature
> without realising its correct syntax definition. Where is it
> documented? help comma does not seem relevant.

It's among the list of binary operators.
(In the PDF doc on p28.)

> 
> I was thinking the following two uses were the same thing. It seems
> the first is a separator, second is an operator:
> 
> gnuplot> plot a=1,b=2, sin(x)
> fn(x)=( a=1,b=2, sin(x) )
> 
> Peter.
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Should gnuplot become a programming environment?

[<pl...@pi...>]

On 10/30/14 22:42, Ethan A Merritt wrote:
>
> On Thursday, 30 October, 2014 12:58:54 pl...@pi... wrote:
>>   Also the odd need to use commas in place of the usual semicolon
>>   in defining functions seems inconsistent and could be limiting as
>>   things move forwards.
>
> Are you referring to the comma operator for serial evaluation?
> That is taken straight from C, C++, perl, javascript and no doubt
> other languages as well.
>
>      http://en.wikipedia.org/wiki/Comma_operator
>
>
> 	Ethan
>

My apologies, apparently I was successfully using this feature without 
realising its correct syntax definition. Where is it documented? help 
comma does not seem relevant.

I was thinking the following two uses were the same thing. It seems the 
first is a separator, second is an operator:

gnuplot> plot a=1,b=2, sin(x)
fn(x)=( a=1,b=2, sin(x) )

Peter.

Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan A M. <sf...@us...>]

On Thursday, 23 October, 2014 23:18:12 Philipp K. Janert wrote:
>
> I think it would be wonderful if both current
> interactive terminals (Qt and wxt) would allow 
> the user to "save" the current graph to file in 
> a range of file formats (basically PNG and PDF).

This thread kind of diverged into discussion of other things,
but thanks in large part to Dan Sebald there is now an
Export to File  widget on the wxt terminal toolbar.
It supports output to png, pdf, or svg.

I added it to cvs for 5.1 but I'd like to hear whether it does or
doesn't work on Windows and OSX before deciding whether to
include it in the 5.0 release.

I'm also curious how widespread the wxt support for svg
output is.  If your local cairo installation doesn't support it
then you should get an error message.

The qt terminal already has such a widget.

	Ethan

Re: Should gnuplot become a programming environment?

[Ethan A M. <sf...@us...>]

On Thursday, 30 October, 2014 12:58:54 pl...@pi... wrote:
>  Also the odd need to use commas in place of the usual semicolon
>  in defining functions seems inconsistent and could be limiting as
>  things move forwards.

Are you referring to the comma operator for serial evaluation?
That is taken straight from C, C++, perl, javascript and no doubt
other languages as well.

    http://en.wikipedia.org/wiki/Comma_operator


	Ethan

heredocs aren´t data (was Re: Should gnuplot become a programming environment?)

[Karl R. <ra...@un...>]

On 30.10.2014 21:00, Philipp K. Janert wrote:

> variables. It kept no memory of the data
> plotted - it read it from scratch every time
> it was plotted again.
> 
> What's different about heredocs (and why I
> refer to them as "state") is that now gnuplot
> has a facility for "remembering" data sets
> between plots. 

But heredocs are just text files, only they´re read from memory
instead of file system. The whole parsings is done identically (as i
understand), and has to be re-done on every plot.

I don´t think that´s "stored data", but rather a very convenient,
transparent kind of a temporary file.

Regarding heredocs as a temporary file also resolves the issue about
saving it. Nobody would expect it to save.

  Karl

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

Ethan -

I don't want to let your answer go w/o reply,
but I also don't want to let this thread turn
into a conversation between the two of us about 
the semantics of computer science terms. I am
not sure how fruitful that would be.

> 
> Obviously you cannot reproduce a data plot without access to the
> data being plotted.  But this is not "state" as I understand the term.

"State" is what is maintained by a computer
component between operations. 

The only state gnuplot maintained between
invocations of the plot command (which is
what gnuplot is all about) was the collection
of the "set" options - and (increasingly)
variables. It kept no memory of the data
plotted - it read it from scratch every time
it was plotted again.

What's different about heredocs (and why I
refer to them as "state") is that now gnuplot
has a facility for "remembering" data sets
between plots. 

(I am disregarding GUI issues here, because
that's really a separate component, which -
as you point out - does not interfere back
to the rest of gnuplot.)

But I really don't think that these fineries 
get us to the heart to the matter!

Re: Should gnuplot become a programming environment?

[<pl...@pi...>]

On 10/30/14 17:30, Philipp K. Janert wrote:
>
>
> [snip]
>
>>> Do we want differentiation and integration -
>>> in a PLOTTING program??? My answer is: hell, no!
>>
>> I don't think such hard-line attitudes are helpful.
>
> Yes, you are right. And I don't want to give
> the impression of being rigid and dogmatic here.
>
> As you (and others) point out, it's a balancing
> act - how much scripting should gnuplot support,
> and where to draw the line?
>
> But the line has to be drawn somewhere, otherwise
> you end up with the kitchen sink.
>
> I will also admit that I am much less clear in my
> own mind what the right course of action is here.
> To a certain extent, I am playing devil's advocate.
>
> Two sentiments motivate my recent postings:
>
> 1) In my opinion, we are crossing "the line"
>     from a simple, stateless, straightforward
>     graphical plotting program towards a much
>     more complicated programming and computing
>     environment.
>
> 2) I lack a sense of direction in the recent
>     crop of gnuplot features. I get the sense
>     that features are implemented on a whim,
>     and with little consideration of their
>     follow-up costs and implications.
>     That's ok if it's yet another interpolation
>     algorithm - because its scope is so limited
>     (and because it's still strictly within the
>     graphical plotting world.)
>     But general-purpose programming infrastructure
>     is not limited in the same way: it opens up
>     "huge possibilities" as you say, and I am sure
>     that it will continue to beget more features
>     (local vars, data structures, functions, etc),
>     that have nothing to do with "plotting data in
>     a file".
>
> I have looked at several scientific (and general)
> programming environments over time, and one of the
> essential ingredients seems to be the ability to
> say "No". Or at least: "Not here".
>
> Because this is another direction in which this
> discussion could be taken: not "yes" or "no", but
> "how". If there is a desire to enable scripting
> with gnuplot, is the right way to achieve this to
> kludge for-loops onto the (already overloaded) plot
> command?
>
> Is there a way to structure this better? For
> instance, maybe rather than cluttering the
> commands with even more sub-options, should
> one think about a really clean and simple
> plugin architecture for programming needs?
>

I agree, that  while useful, the for loops do feel like a bit of a 
bolt-on kludge.

Maybe this could be done in a more structured way.

Also plot gets very messy at times. Off loading to a fn call can some 
times help.

I'd like something more compact than  :  linecol rgb "light-gray"  at 
times ;)

BTW, you mentioned why don't I use octave: because it's buggy and the 
main devs a snotty Mac elitists who think they know it all.

Here suggstions get a fair run and if they're good they get acted on fast.

h/t to Ethan.

Peter.




> (And at that point, one can ask whether one
> could leverage an existing scripting language,
> rather than inventing one ad-hoc.)
>
> [snip]
>
>>
>> If I want to do an FFT I would not try to do it in gnuplot script !!!!
>
> All I can say is: not YET.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Should gnuplot become a programming environment?

[Ethan A M. <sf...@us...>]

On Thursday, 30 October, 2014 00:29:42 Philipp K. Janert wrote:
> On Wed, 29 Oct 2014 23:29:45 -0700
> sfeam <sf...@us...> wrote:
> 
> > On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> > > 
> > > - structured data types
> > 
> >   There are no structured data types in gnuplot that I can think of
> >   other than complex numbers {R, I}, and they were in gnuplot from
> >   Day One.
> 
> Heredocs are a structured data type - they are not scalars!

That is a false dichotomy.
They are not scalars.  Also they are not structured.

More to the point, you seem to be conflating "data type" with "variable type". 

As I see it, gnuplot has three variable types:
   complex    {real, imaginary}
   integer       i
   string         "null-terminated sequence of bytes"

It also has three data source types:
  file			text or binary
  inline		pseudofile '-'
  heredoc		named datablock

This is an important distinction.   Functions and expressions accept
complex/integer/string arguments and return a complex/integer/string
result.   There is no way to pass a datablock to a function or to declare a 
function that returns a datablock. 

> > > - statefulness and persistence.
> 
> Heredocs, again. You now maintain state (=data) in the session. 

No.  Again you are conflating two things that are quite distinct.
"data" is not "state".     Also "command script" is not "state", nor
is it "session".

Although there is no formal specification of state variables in gnuplot,
I think it is correct to say that the current session state has two
components.

The first component is operationally defined by a sequence of "set"
commands and variable assignments.  Let's call this "program state".
Program state is what is stored to file by the "save" command.

The second component of the current state includes whatever 
interactions you have performed through the GUI for the current
terminal.  This includes things like the zoom/unzoom stack,
the currently selected or deselected plot components toggled 
by clicking in the legend,  and the size of the window displayed
on the screen.   Let's call this "GUI state".  There is no gnuplot
command to save or restore the GUI state, although some of the
terminals (Qt, wxt) use a toolkit that maintains some state
(size, background, antialiasing, ...) across sessions.

Obviously you cannot reproduce a data plot without access to the
data being plotted.  But this is not "state" as I understand the term.

Perhaps you could say  plot = state + data.

%%%

Some of gnuplot's new features extend the operations that
are possible through the GUI  (toggle, hypertext, export through
a toolkit-dependent filter).    They affect the GUI state but not
the program state. 

But heredocs do not affect state at all. They are data.

	Ethan
 

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

> > Do we want differentiation and integration -
> > in a PLOTTING program??? My answer is: hell, no!
> 
> I don't think such hard-line attitudes are helpful.
> 

Maybe I can say this much simpler: if you want
scripting and numerics with gnuplot, why don't 
you use Octave?

Because it's complicated, right?


(Take my point?)

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

[snip]

> > Do we want differentiation and integration -
> > in a PLOTTING program??? My answer is: hell, no!
> 
> I don't think such hard-line attitudes are helpful.

Yes, you are right. And I don't want to give
the impression of being rigid and dogmatic here.

As you (and others) point out, it's a balancing
act - how much scripting should gnuplot support,
and where to draw the line? 

But the line has to be drawn somewhere, otherwise
you end up with the kitchen sink.

I will also admit that I am much less clear in my
own mind what the right course of action is here.
To a certain extent, I am playing devil's advocate.

Two sentiments motivate my recent postings:

1) In my opinion, we are crossing "the line" 
   from a simple, stateless, straightforward
   graphical plotting program towards a much
   more complicated programming and computing
   environment.

2) I lack a sense of direction in the recent
   crop of gnuplot features. I get the sense
   that features are implemented on a whim,
   and with little consideration of their 
   follow-up costs and implications.
   That's ok if it's yet another interpolation
   algorithm - because its scope is so limited
   (and because it's still strictly within the
   graphical plotting world.)
   But general-purpose programming infrastructure
   is not limited in the same way: it opens up
   "huge possibilities" as you say, and I am sure
   that it will continue to beget more features
   (local vars, data structures, functions, etc),
   that have nothing to do with "plotting data in
   a file".

I have looked at several scientific (and general)
programming environments over time, and one of the 
essential ingredients seems to be the ability to
say "No". Or at least: "Not here".

Because this is another direction in which this
discussion could be taken: not "yes" or "no", but 
"how". If there is a desire to enable scripting 
with gnuplot, is the right way to achieve this to 
kludge for-loops onto the (already overloaded) plot 
command? 

Is there a way to structure this better? For
instance, maybe rather than cluttering the 
commands with even more sub-options, should 
one think about a really clean and simple 
plugin architecture for programming needs?

(And at that point, one can ask whether one 
could leverage an existing scripting language,
rather than inventing one ad-hoc.)

[snip]

> 
> If I want to do an FFT I would not try to do it in gnuplot script !!!!

All I can say is: not YET.