|
From: Tait <gnu...@t4...> - 2010-07-20 01:59:06
|
> ...
> But gnuplot provides some programming functionality and some string
> functions for it - strlen, strstrt, substr etc. - so I think one function
> for doing string replacements would be useful. ...
Gnuplot is a plotting program, not a scripting (or data manipulation)
language. Where then, to draw the line between the two?
This is just my opinion, but the further we go toward scripting, the
more difficult we make it for ourselves. Nobody developing gnuplot is a
language designer I suspect, and scripting is done far better by any number
of other utilities, from fortran to Perl to the GNU scientific computing
libraries. I find the scripting-like syntax and utilities available now in
gnuplot (e.g. for and string variables) to be brittle and unintuitive. It's
limited to specific pre-conceived use cases and users will always find new,
unexpected usages. Gnuplot adapts to these poorly. If we want script-like
utility, we'd be better to make gnuplot interface easily to existing tools,
instead of re-inventing the wheel ourselves.
It's common that people ask whether gnuplot can internally sort their data;
extract parameters from the data, to be used in other aspects of the plot;
do complicated logic evaluation; or to repeat the same thing slightly
differently for data sets involving thousands of plots. Once past a low
level of complexity, I always advise these people to stop treating gnuplot
like a language and start treating it like a purpose-specific tool. Use
a more flexible, general-purpose tool like Ruby to handle sorting,
data analysis, and logic. Have Ruby generate a script file gnuplot
can understand, and use the Ruby layer to handle all the arbitrary
complexity. This works better, because Ruby has access to more inputs
(filesystem, network, ...) and can support unlimited abstraction,
arbitrary expressions, logic, and linking into other utilities in a way
gnuplot never will. I've picked Ruby rather arbitrarily here; plenty of
other languages can do the same.
data (mess) -> scripting language -> plot file -> gnuplot -> output
rather than
data (mess) -> plot file (try to handle mess) -> gnuplot -> output
String replacement is a low hurdle at which to require introducing the
scripting language layer, but there are many more potential uses of
search-and-replace than just substitution within a string variable
like var2=replace(var1, "foo", "bar"). Take string substitution
within commands for example, set title font replace(<stuff>), or set
key autotitle columnheader replace(<stuff>). The scope of the change
quickly becomes significant, with potential to misparse a legit command
increasing. Limiting string substitution to the first example invites
questions from confused users about why it works in one context and not
another, a type of question I see too often already. Pushing gnuplot a
little closer to being a poor scripting language is not the right answer
here, I think.
|