Re: Suggestion to improve usability of plot command

[Keir M. <ke...@cs...>]

On Sat, Oct 07, 2006 at 02:55:40PM -0400, Daniel J Sebald wrote:
> Hans-Bernhard Br?ker wrote:
> 
> >>gnuplot> plot 'file1' with points 'red squares'
> >>gnuplot> plot 'file2' with points 'blue crosses'
> >>gnuplot> plot 'file1' with points 'orange octagons'
> 
> Call this the Lucky Charms design principle.  (I probably used that joke 
> already... for which many of you likely don't know that Lucky Charms is a 
> brand of cereal.)
> 
> I'm actually kind of partial to this syntax.  Could maybe even change it to 
> read like
> 
> gnuplot> plot 'file1' with red square points
> 
> The one problem is that to describe some of these symbols can get lengthy, 
> e.g., "filled square" vs. "empty square".  However, we could limit the 
> number of symbol names to be six or eight, i.e., just "square" (could get 
> the filled square using the numbers).

I actually wrote this as my proposed syntax first, but decided it would be too
controversial because 'red' could be a variable.

As long as a condensed syntax is available, then lengthy names are just fine.
When not excessively verbose, syntax which needs no documentation good.
 
> >>The symbols are:
> >>       's' : square
> >>       'o' : circle
> >>       '^' : triangle up
> 
> or this.  Not as easy to remember, but condensed syntax.

I became firmly convinced, when I heard a story from my friend David about
MATLAB plotting syntax (he is an IDL user): the first time he encountered it, a
friend of his was plotting some data in MATLAB. He said that at the end of the
plot command was this mysterious 'r.', yet when the plot came up he instantly
understood the syntax: red dots! Apparently this happened years ago, yet he
still remembers the syntax today. (And never uses MATLAB)
 
> >is the same: they completely ignore one central design principle of 
> >gnuplot: script compatibility across terminal drivers.  Your proposal
> >fails to address the question what gnuplot should do with a plot script 
> >that requests some point symbol the current driver simply can't generate.
> 
> The driver would map to another symbol and issue a warning.  (And we could 
> write an algorithm so that it isn't mapped to an already used symbol 
> number.)

Yes. I believe in keeping easy things easy, and hard things possible.
 
> I keep a file on my computer with such numbers:
> 
> Symbol translation for Octave to "pslatex" terminal:
> 
> 1 - plus
> 2 - x
> 3 - asterisk
> 4 - open square
> 5 - solid square
> 6 - open circle
> 7 - solid circle
> 8 - open triangle
> 9 - solid triangle
> 
> I don't know if the problem is so much the use of numbers for me.  The 
> problem is the fact that the numbers don't produce the same symbols across 
> drivers.  Why couldn't those be mapped to be similar symbols?  It is very 
> frustrating to create a plot on the screen, then save it as PostScript to 
> find the symbols are different.  In that sense, I'd say gnuplot isn't 
> script compatible.

I think this is a pretty convincing argument to adopt the new syntax, or
something like it; it sounds as though the existing system is actually worse!

Besides -- this is 2006. Which terminal that is frequently used by the majority
of users can't support all of the symbol types? I'm pretty baffled.  Besides,
if a user is writing a gnuplot script with color arguments, they can hardly
expect it to look amazing in black and white or grayscale.  I understand not
all terminals have colors, but there's no reason we can't do something
reasonable in the face of black and white. If they user wants gorgeous plots
that work in black and white and color, then they can use the old numeric
style.

Cheers,
Keir