Should gnuplot become a programming environment?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Should gnuplot become a programming environment?

Philipp K. Janert

(This started as a discussion on heredocs, but
is really about a bigger-picture-issue. So, I'll
try to restart this thread again.)

Recently, gnuplot has begun to acquire features
that are typical of a programming language:

- loops and conditionals
- structured data types
- statefulness and persistence.

I don't think this is a good trend, and I'd like
to raise awareness for what's happening.

Gnuplot used to be a simple plotting tool - that
was its weakness, but also its strength.

Now, gnuplot has begun to become a programming
environment. This will make gnuplot more
complicated: more complicated to learn, but
eventually also more complicated to develop for.

I doubt that the benefits of turning gnuplot
into a programming environment outweigh the
costs. I also think that this will lead gnuplot
into a competition with more established
"scientific workbenches" (R, NumPy/SciPy,
Octave) that it will lose.

I think gnuplot would be better off to stay
a plotting tool, and not try to become a
programming environment. I suggest that we
should evaluate each such feature very
carefully before accepting it into gnuplot -
and be ready to reject certain ideas (and/or
look for alternatives that do not require
changes to the gnuplot main program).

I am concerned about "creeping featurism",
where each new "simple/useful" feature drags
in bigger and bigger features. (Example: gnuplot
now has loops. It is only natural that it should
have an iterable data structure. Once it has
that, it will be natural to ask for vector
operations and indexing magic - and for
matrix computations. At that point there will
be demand for local variables and proper blocks,
which will lead to subroutines. And so on.)

I don't think anybody INTENDS to turn gnuplot
into a matlab competitor, but that - in fact -
makes it worse: because there is no thought
given to design upfront, stuff is just being
kludged on. (The result will not be pretty.)

There are only ways to stop this:
- to collectively say "No"
- to collectively say "Yes", discuss the
  direction, and then accept features if
  they fit with the agreed upon direction.

One more thing: scientists are not language
designers, and therefore tend to underestimate
the difficulties in designing a consistent
and maintainable language.

In doing research for my book on
open-source tools for data analysis, I have
looked at a wide variety of "scientific"
programming environments, and got the sense
that most (if not all) of them struggle under
their own weight: they were started, without
much thought, design, or knowledge, by
scientists who "just wanted to do some
calculations", but who did not have much
knowledge or experience in the theory of
languages and data structures, who did not
understand large-scale programming, and who -
more than anything - underestimated what they
were in for. All these programming environments
(no names, to protect the guilty) are now big,
overgrown, and unstructured monsters. I
don't want to see gnuplot go the same way.

What do others think?

Best,

                Ph.

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

sfeam

On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:

>

> (This started as a discussion on heredocs, but

> is really about a bigger-picture-issue. So, I'll

> try to restart this thread again.)

>

> Recently, gnuplot has begun to acquire features

> that are typical of a programming language:

>

> - loops and conditionals

 

Yes, loops are new.

 

The only thing new about conditionals is that the

introduction of bracketed clauses means that you

no longer have to stuff the entire content on a

single input line.

 

IHMO both of these are significant improvements

in usability.

 

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

 

> - statefulness and persistence.

 

You said this before but I do not understand what you are

referring to. Could you give an example?

 

You don't mention the one programming-language feature added a

while back that I do regret: macros.

 

Macros were one of my failed attempts to implement string variables,

one that I wish had been removed when real string variables were

added later. The poor design is even more evident now that we

have loops, since it confuses people that the macros are only

evaluated outside the loop, even if the associated string variable

is changed inside the loop.

 

Since you raise the issue of backing out bad ideas,

could we start by deprecating macros?

 

Ethan

 

>

> I don't think this is a good trend, and I'd like

> to raise awareness for what's happening.

>

> Gnuplot used to be a simple plotting tool - that

> was its weakness, but also its strength.

>

> Now, gnuplot has begun to become a programming

> environment. This will make gnuplot more

> complicated: more complicated to learn, but

> eventually also more complicated to develop for.

>

> I doubt that the benefits of turning gnuplot

> into a programming environment outweigh the

> costs. I also think that this will lead gnuplot

> into a competition with more established

> "scientific workbenches" (R, NumPy/SciPy,

> Octave) that it will lose.

>

> I think gnuplot would be better off to stay

> a plotting tool, and not try to become a

> programming environment. I suggest that we

> should evaluate each such feature very

> carefully before accepting it into gnuplot -

> and be ready to reject certain ideas (and/or

> look for alternatives that do not require

> changes to the gnuplot main program).

>

> I am concerned about "creeping featurism",

> where each new "simple/useful" feature drags

> in bigger and bigger features. (Example: gnuplot

> now has loops. It is only natural that it should

> have an iterable data structure. Once it has

> that, it will be natural to ask for vector

> operations and indexing magic - and for

> matrix computations. At that point there will

> be demand for local variables and proper blocks,

> which will lead to subroutines. And so on.)

>

> I don't think anybody INTENDS to turn gnuplot

> into a matlab competitor, but that - in fact -

> makes it worse: because there is no thought

> given to design upfront, stuff is just being

> kludged on. (The result will not be pretty.)

>

> There are only ways to stop this:

> - to collectively say "No"

> - to collectively say "Yes", discuss the

> direction, and then accept features if

> they fit with the agreed upon direction.

>

> One more thing: scientists are not language

> designers, and therefore tend to underestimate

> the difficulties in designing a consistent

> and maintainable language.

 

I'm not sure history bears you out there.

 

Some of the most successful computer languages,

starting with Fortran, were designed by scientists.

 

Conversely some of the most unmaintainable languages

(I'm looking at you, Python) were created by people or

committees that fancied themselves as language designers.

 

EAM

 

>

> In doing research for my book on

> open-source tools for data analysis, I have

> looked at a wide variety of "scientific"

> programming environments, and got the sense

> that most (if not all) of them struggle under

> their own weight: they were started, without

> much thought, design, or knowledge, by

> scientists who "just wanted to do some

> calculations", but who did not have much

> knowledge or experience in the theory of

> languages and data structures, who did not

> understand large-scale programming, and who -

> more than anything - underestimated what they

> were in for. All these programming environments

> (no names, to protect the guilty) are now big,

> overgrown, and unstructured monsters. I

> don't want to see gnuplot go the same way.

>

> What do others think?

>

> Best,

>

> Ph.

>

> ------------------------------------------------------------------------------

> _______________________________________________

> gnuplot-beta mailing list

> [hidden email]

> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

 


------------------------------------------------------------------------------

_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert
On Wed, 29 Oct 2014 23:29:45 -0700
sfeam <[hidden email]> wrote:

> On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> >
> > (This started as a discussion on heredocs, but
> > is really about a bigger-picture-issue. So, I'll
> > try to restart this thread again.)
> >

[snip]

> >
> > One more thing: scientists are not language
> > designers, and therefore tend to underestimate
> > the difficulties in designing a consistent
> > and maintainable language.
>
> I'm not sure history bears you out there.

I am sorry - I really, REALLY, REALLY do not want
to start a language war!

>
> Some of the most successful computer languages,
> starting with Fortran, were designed by scientists.

My horror stories are scientific languages that
were never designed, but that grew. The two
biggest contenders are matlab and R.

>From a language point of view, everything about
them is wrong.


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert
In reply to this post by sfeam
On Wed, 29 Oct 2014 23:29:45 -0700
sfeam <[hidden email]> wrote:

> On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> >
> > (This started as a discussion on heredocs, but
> > is really about a bigger-picture-issue. So, I'll
> > try to restart this thread again.)
> >
> > Recently, gnuplot has begun to acquire features
> > that are typical of a programming language:
> >
> > - loops and conditionals
>
>   Yes, loops are new.
>
>   The only thing new about conditionals is that the
>   introduction of bracketed clauses means that you
>   no longer have to stuff the entire content on a
>   single input line.
>
>   IHMO both of these are significant improvements
>   in usability.
>
> > - 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!

An iterable data type will surely follow:
otherwise the loop construct is living in
a vacuum.

>
> > - statefulness and persistence.

Heredocs, again. You now maintain state (=data)
in the session.

And as my (naive!) questioning shows, people
will want to persist that state (now that it
is there).

>
>   You said this before but I do not understand what you are
>   referring to.  Could you give an example?
>
> You don't mention the one programming-language feature added a
> while back that I do regret:  macros.

I have no problem with macros. They may be a
bad idea (I am not even sure they are), but
they are harmless - because the don't beget
more and more features.

Did you see my implementation of Newton's
method in gnuplot? Which I can do, given
that I now have a proper looping construct?

But it relies on global variables, doesn't
it? Wouldn't it make sense to introduce
variables that are local to the body of a
loop, a conditional (both now have bodies!)
or a function? By the way - shouldn't we
have multi-line functions?

And once we will have that array data
structure, it's only a matter of time
before someone implements an FFT in
gnuplot.

> Since you raise the issue of backing out bad ideas,
> could we start by deprecating macros?  

I am less concerned about killing off bad
ideas that are going to whither and die by
themselves. I am concerned about features
that have heavy long-term effects. Again,
I come back to loops: once you have loops,
it is natural to have an iterable data
type. Once you have loops AND an iterable
data type, you basically have a complete
programming environment, so now it makes
sense to ask for things like local scope.

Each idea by itself is useful and even
harmless - but I suggest that we also
take their long-term costs into account.

Best,

                Ph.
 

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Plotter-2
In reply to this post by sfeam
On 10/30/14 07:29, sfeam wrote:

> Yes, loops are new.
>
> The only thing new about conditionals is that the
>
> introduction of bracketed clauses means that you
>
> no longer have to stuff the entire content on a
>
> single input line.
>
> IHMO both of these are significant improvements
>
> in usability.
>

They are indeed significant improvements, many thanks for adding these
features.

Being able to structure blocks of code properly and iterate are some of
the most useful things since you implemented my suggestion of being able
to assign a variable, which you remarkably did in under 24h.  Amazing
responsiveness in gnuplot devel.

There is some sense in idea of taking a step back to look at overall
design of these kind of scripting language features. Making it top down
instead of growing piecemeal.

I find the loop commands useful but the rather unusual and specific
syntax may be inconvenient at some point in the future. 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.

That said, being able to add functions opens up huge possibilities that
avoids needing to pre-process data for trivial things like diff and
integration and other simple needs. Bulk data processing is still better
done outside of the plotting utility in tested code suites in compiled
code but this remains an incredibly useful feature.

I don't think there is a need to view this as 'taking on" other
languages or "loosing" to them. If I had a scripting task to do I would
use an existing tool not a plotting program, but if I need manipulate or
tweak  some data I'm plotting, having that ability built-in is has a lot
of merit. Documentation and archiving being a key argument: all is in
one file.

A number of times, I've found the lack of indexed arrays rather
frustrating and I keep trying to use x+=1 type syntax before remembering
it is not defined.

my2c, Peter.







------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Petr Mikulik
In reply to this post by Philipp K. Janert
> And once we will have that array data
> structure, it's only a matter of time
> before someone implements an FFT in
> gnuplot.

I think you can achieve it this way:

plot "<octave --silent --eval \"a=load('a.dat'); disp(imag(fft(a)));\"" with image

I like all new features, including macros and strings.

Anyway, a nice discussion, which hilights achievements done recently.

But nobody wants to replace Octave or Python, as gnuplot is/can be used by
them.

---
PM

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert
In reply to this post by Plotter-2

[snip]

> That said, being able to add functions opens up huge possibilities
> that avoids needing to pre-process data for trivial things like diff
> and integration and other simple needs. Bulk data processing is still
> better done outside of the plotting utility in tested code suites in
> compiled code but this remains an incredibly useful feature.

With huge possibilities come huge complexities.
If not today, then eventually.

Do we want them in gnuplot? Or should we keep
scripting with scripting languages and plotting
with gnuplot?

Do we want differentiation and integration -
in a PLOTTING program??? My answer is: hell, no!

Keep the numerical routines in Python or Octave
or wherever. Let's keep the plotting stuff in
gnuplot.

>
> I don't think there is a need to view this as 'taking on" other
> languages or "loosing" to them. If I had a scripting task to do I

I am not arguing from a developer's point of view,
but from a user's one.

Gnuplot's advantage over R or matlab was it's simplicity:
just plot a file - all there is to it. Once this simplicity
is gone, what is gnuplot's advantage (or niche)?

> would use an existing tool not a plotting program, but if I need
> manipulate or tweak  some data I'm plotting, having that ability
> built-in is has a lot of merit. Documentation and archiving being a
> key argument: all is in one file.

[snip]

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Plotter-2
On 10/30/14 15:41, Philipp K. Janert wrote:

>
>
> [snip]
>
>> That said, being able to add functions opens up huge possibilities
>> that avoids needing to pre-process data for trivial things like diff
>> and integration and other simple needs. Bulk data processing is still
>> better done outside of the plotting utility in tested code suites in
>> compiled code but this remains an incredibly useful feature.
>
> With huge possibilities come huge complexities.
> If not today, then eventually.
>
> Do we want them in gnuplot? Or should we keep
> scripting with scripting languages and plotting
> with gnuplot?
>
> 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.

If I want to subtract the previous plot point from the current one to
plot the first difference ( numerical approximation to the differential)
I do not want to have to set up and external script for such a trivial
task and then try to synchronise  the archiving of whatever external
scripts I have with the gnuplot script I'm using to plot it.

Same with integration, it's a trivial case of successive addition of
current point. It would be more effort to write a one-liner awk script
to do this and then call the scritp before plotting from gnuplot, than
to have a trivial gnuplot fn, and that would also mean duplication of
the data file which may itself be substantial, ie an awful waste of
effort all round.

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

Peter.



>
> Keep the numerical routines in Python or Octave
> or wherever. Let's keep the plotting stuff in
> gnuplot.
>
>>
>> I don't think there is a need to view this as 'taking on" other
>> languages or "loosing" to them. If I had a scripting task to do I
>
> I am not arguing from a developer's point of view,
> but from a user's one.
>
> Gnuplot's advantage over R or matlab was it's simplicity:
> just plot a file - all there is to it. Once this simplicity
> is gone, what is gnuplot's advantage (or niche)?
>
>> would use an existing tool not a plotting program, but if I need
>> manipulate or tweak  some data I'm plotting, having that ability
>> built-in is has a lot of merit. Documentation and archiving being a
>> key argument: all is in one file.
>
> [snip]
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert

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

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert
In reply to this post by Plotter-2

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

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Plotter-2
In reply to this post by Philipp K. Janert
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
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

sfeam
In reply to this post by Philipp K. Janert
On Thursday, 30 October, 2014 00:29:42 Philipp K. Janert wrote:

> On Wed, 29 Oct 2014 23:29:45 -0700
> sfeam <[hidden email]> 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
 


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert

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!


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

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

Karl-Friedrich Ratzsch-2
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


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

sfeam
In reply to this post by Plotter-2
On Thursday, 30 October, 2014 12:58:54 [hidden email] 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

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Plotter-2
On 10/30/14 22:42, Ethan A Merritt wrote:

>
> On Thursday, 30 October, 2014 12:58:54 [hidden email] 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.


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Philipp K. Janert
On Fri, 31 Oct 2014 17:38:00 +0100
[hidden email] wrote:

> On 10/30/14 22:42, Ethan A Merritt wrote:
> >
> > On Thursday, 30 October, 2014 12:58:54 [hidden email] 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
> [hidden email]
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

sfeam
In reply to this post by Plotter-2
On Friday, 31 October, 2014 17:38:00 [hidden email] wrote:

> On 10/30/14 22:42, Ethan A Merritt wrote:
> >
> > On Thursday, 30 October, 2014 12:58:54 [hidden email] 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.


------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Daniel J Sebald
In reply to this post by Philipp K. Janert
[Wrote this more than a week ago, then set in aside in draft box.]

On 10/29/2014 06:52 PM, Philipp K. Janert wrote:

>
> (This started as a discussion on heredocs, but
> is really about a bigger-picture-issue. So, I'll
> try to restart this thread again.)
>
> Recently, gnuplot has begun to acquire features
> that are typical of a programming language:
>
> - loops and conditionals
> - structured data types
> - statefulness and persistence.
>
> I don't think this is a good trend, and I'd like
> to raise awareness for what's happening.
>
> Gnuplot used to be a simple plotting tool - that
> was its weakness, but also its strength.
>
> Now, gnuplot has begun to become a programming
> environment. This will make gnuplot more
> complicated: more complicated to learn, but
> eventually also more complicated to develop for.

Point taken about the simplicity of the language, but I think that
argument is disconnected from the development aspect of gnuplot for a
couple reasons.

First, gnuplot is still one of the most compact programs I've seen.  It
compiles in about 45 seconds on my system and making changes and
recompiling is extremely fast.  Other significant programs can take tens
of minutes to compile because of overheads for libraries, definitions,
macros, etc.  In some bigger programs I'm sometimes hesitant to touch a
header file because it will mean minutes of recompiling.

Second, and the more significant point, maintenance of these small
features pales in comparison to the overall organization of the code.  A
little more OOP concepts would aid development far more than the burden
of the small features.  (The code has actually improved over the years.
  E.g., barely any global variables left.)  The internal storage of data
with the 2D version and 3D version is a bit of a headache.  Trying to
keep track of whether z is being used for dimension or color comes to
mind.  I wish 2D data was pretty much the same as 3D but with one
dimension zero.  Overall data flow from input to processing to plotting
could maybe be cleaner and more flexible.  The gains from code cleanup
and layout would outweigh these small features, and help for new bigger
features.

Dan


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Should gnuplot become a programming environment?

Plotter-2
On 11/12/14 07:11, Daniel J Sebald wrote:
>> Now, gnuplot has begun to become a programming
>> >environment. This will make gnuplot more
>> >complicated: more complicated to learn, but
>> >eventually also more complicated to develop for.

If it's too complicated to learn the available programming features,
don't learn them.

You are then at the same point as if the features were not available and
gnuplot becomes easier to learn again. ;)

If you can't  cope with those features, don't  use them when "developing
for" gnuplot.

If reversing a car is "complicated" and beyond your capabilities, your
just drive around the block and stop a further up the road. You don't
start campaigning for the removal of reverse gear from all cars.

This is a non argument.

Peter.


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
12