Menu
▾
▴
gnuplot-beta
|
From: Philipp K. J. <ja...@ie...> - 2014-10-29 23:53:01
|
(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. |
|
From: sfeam <sf...@us...> - 2014-10-30 06:32:10
|
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
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
|
|
From: Philipp K. J. <ja...@ie...> - 2014-10-30 07:29:34
|
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: > > > > (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. |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-30 07:29:50
|
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:
> >
> > (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.
|
|
From: Petr M. <mi...@ph...> - 2014-10-30 14:32:32
|
> 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
|
|
From: <pl...@pi...> - 2014-10-30 13:15:17
|
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. |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-30 14:41:58
|
[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] |
|
From: <pl...@pi...> - 2014-10-30 15:45:18
|
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 > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-30 16:32:14
|
> > 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?) |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-30 16:30:16
|
[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. |
|
From: <pl...@pi...> - 2014-10-30 19:31:27
|
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 > |
|
From: Ethan A M. <sf...@us...> - 2014-10-30 18:48:10
|
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
|
|
From: Ethan A M. <sf...@us...> - 2014-10-30 21:44:10
|
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
|
|
From: Philipp K. J. <ja...@ie...> - 2014-10-30 20:00:14
|
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! |
|
From: Karl R. <ra...@un...> - 2014-10-30 21:13:58
|
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 |
|
From: <pl...@pi...> - 2014-10-31 16:57:31
|
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. |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-31 17:10:46
|
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 |
|
From: Ethan A M. <sf...@us...> - 2014-10-31 17:28:18
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2014-11-12 06:11:24
|
[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 |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-13 16:58:32
|
One more question in the whole argument: Even if we agree that adding programming functionality to gnuplot is a good thing, it nevertheless leaves open the decision HOW this should be done. Is adding convenience features to the core language in an essentially ad-hoc manner the best strategy? Or would it make sense to invest some effort to have tighter integration with an existing programming environment (rather than reinventing loops, functions, data structures within gnuplot)? Or would it be possible to split functionality into a "core" (graphics) part and an "optional" part, with a clear separation of concerns? Or can one have an "extension" framework so that people can add features without having to hack gnuplot backend C code? The current strategy seems to be that there is none. That may give short term wins, but the end result is going to be a mess. Best, Ph. |
|
From: <pl...@pi...> - 2014-11-13 17:28:57
|
On 11/13/14 17:58, Philipp K. Janert wrote: > > One more question in the whole argument: > > Even if we agree that adding programming > functionality to gnuplot is a good thing, > it nevertheless leaves open the decision > HOW this should be done. > > Is adding convenience features to the core > language in an essentially ad-hoc manner > the best strategy? > > Or would it make sense to invest some effort > to have tighter integration with an existing > programming environment (rather than reinventing > loops, functions, data structures within gnuplot)? > > Or would it be possible to split functionality > into a "core" (graphics) part and an "optional" > part, with a clear separation of concerns? > > Or can one have an "extension" framework so > that people can add features without having > to hack gnuplot backend C code? > > The current strategy seems to be that there > is none. That may give short term wins, but > the end result is going to be a mess. > > Best, > > Ph. > Of course a bit of planning and a design strategy is better than bolt-on evolution. Since Ethan seems to do most of the work around here and it was he who started all this by implementing my variable assignment suggestion and IFAIK he has done all the other programming feature in gnuplot, maybe he has a fair idea where he's going and has given it some top-down planning but never saw the need to bother making a formal design study about it. He seems to have a fairly good idea where he's going with this. Unless I saw something going badly wrong or there was substantial input from others that required some team planning and a formal strategy, I'd not want start making demands. Peter. |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-13 18:17:24
|
[snip] > > Since Ethan seems to do most of the work around here and it was he > who started all this by implementing my variable assignment > suggestion and IFAIK he has done all the other programming feature > in gnuplot, maybe he has a fair idea where he's going and has given > it some top-down planning but never saw the need to bother making a > formal design study about it. I am uncomfortable with this line of argument, because of its personal nature. This is obviously not saying anything against Ethan - I think we all know how crucial he has been to gnuplot development over the last 10-15 years. (Thanks, Ethan! I really mean it - without you, gnuplot would be dead by now!) But I'd prefer to keep the argument centered on the technical merits of features, rather than on who conceived and implemented them. > > He seems to have a fairly good idea where he's going with this. With that in mind, I'd like engage Ethan (and everyone else) in this discussion. Do we have a good idea where we are going? Best, Ph. |
|
From: <pl...@pi...> - 2014-11-13 09:39:40
|
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. |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-13 16:15:09
|
On Thu, 13 Nov 2014 10:39:16 +0100 pl...@pi... wrote: > 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. This sounds so right, but I don't think it is. That argument rests on the assumptions that you CAN ignore "those features". That's true for (say) the new "set pointintervalbox" feature (very useful, by the way) - if you never knew it was there, your live won't be any different. What bothers me about those "programming features" is that they WILL start a paradigm shift in how gnuplot is used, and in what ways it will be developed. Today, you can "ignore" them. But my prediction is that before too long, you won't anymore, because that's simply "how it's done". Programming features have a tendency to beget more programming features. Look at almost any language out there - they all keep growing (C being the exception). The horror story here is Python - every single "clever" feature they introduced turned out to have edge cases that needed even more, even "cleverer" features to handle them properly. (C stayed small because it was designed to be small.) > > 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. Remember: the life you save may be your own. It's not each individual "programming feature" that I am concerned about, but their interactions, long term. Python (again) is a horror story of "unintended consequences". Individual arguments aside, I'd like to raise the strategic question: does gnuplot want to catch up to matlab, R, numpy - is that the right direction? (I don't think so, but that's not important. What IS important is that the matter is being discussed and pros and contras are being considered.) [snip] > This is a non argument. I don't think trying to shut down an exchange of ideas is a way to move the world forward. Or, to use your logic from above: "If you don't like the discussion, don't join it." Peter - you can do better than that! > > 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 > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: <pl...@pi...> - 2014-11-13 17:17:55
|
On 11/13/14 17:15, Philipp K. Janert wrote: > The horror story here is Python - every single > "clever" feature they introduced turned out to > have edge cases that needed even more, even > "cleverer" features to handle them properly. When it first looked at python and found out that indentation level was part of the language syntax I got out quick. It sounds like I was right and made a wise choice. Peter. |
