Re: Problem and solution: Patch for new "stats" command

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

> > The tangent about Perl was intended to be in the same vein as Ethan's
> > comment that gnuplot is not MatLab or Mathematica or MathCad or R, and
> > we shouldn't try to be.
>
> The wasn't me. I think it's silly to rule out a useful addition on
> that basis. I think we should seriously consider any addition
> that strengthens gnuplot's ability to create plots.  I do want to hear a
> strong case, however, that the stats command needs to be an internal part
> of gnuplot rather than an external script.  I currently do this sort of
> thing in an external perl script (or in R). But using R to calculate the
> min/mean/max is ridiculous overkill, and I'd still have to get the
> information back into gnuplot in order to generate the plots.

Strong case is always a little in the eye of the beholder.
But here are my arguments:

1) Convenience
I do this stuff w/ external scripts, too, and I always find it
annoying that I have to pop up a different window, run my
little script, copy and paste the results back into gnuplot...

2) Multiplatform
Exactly how do you do any of this if you are NOT on Linux?
(I admit this is a pretty weak argument, but it is not entirely
baseless. People are much less likely to have Perl/Python
installed on their Win box, compared to a standalone gnuplot
binary.)

3) Stand-alone Scripting
Running a separate script from gnuplot is a pain. Cutting
and pasting values manually is not an option for scripts.
Having stuff assigned to variables w/in the gnuplot session
is therefore desirable.

4) Input Parsing
Gnuplot's input parsing is very robust and flexible. It can
eat a lot. My problem with external scripts is that it is more
difficult to make them as robust, which means that I don't
have any "pre-canned" - I write them ad-hoc for each file
format that I am dealing with. But that makes it inconvenient
in the long run. On the other hand, I don't want to own and
maintain my own stats script, when I might as well have this
functionality included in gnuplot (where it also benefits 
everybody else).

I think some of the reluctance comes from the fact that the
set of capabilities of the current stats command is fixed. 

There are two answers to this:

- Should we extend the set of values calculated? Personally,
	the values that we have included cover approximately
	92.5% of what I need. I think that's a pretty good ratio!
	I would also argue that it covers those values that are
	most important for PLOTTING. But I am willing to take
	suggestions for additional quantities. (We can also look
	at what other packages like R do in their "summary"
	functions.)

- Should gnuplot (deep breath) develop a "plugin" architecture?
	So that you could run an external script and assign the
	returns to gnuplot vars in a transparent and convenient
	fashion? 

I think the latter idea is worth a thought, but it is clearly a much
bigger project (not the coding, but designing a good user 
interface). But it seems a little like overkill for what we are trying
to accomplish here.

There is no claim that the stats command will save the world.
But I do claim that it provides enough of a convenience (see
above) to have it included. 

Counter-argument: I'd like to hear a strong argument why it
should NOT be included. ;-)

Best,

		Ph.