Re: Plotting with variable point size

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>There is a big problem, however, and it's one that you and I
>have both been complaining about already.  The current code has
>hardwired assumptions about what quantity is in which column.
>Imagine a new keyword "sized"
>Then
>	splot "starchart" using 1:2:3:4:5 with points sized palette,
>              "" using 1:2:3:4 with points sized,
>              "" using 1:2:3:4 with points palette    
>
>will have problems because the contents of columns 4 and 5 are not
>consistent for the three variants.  Indeed I think this is still
>a problem even if we introduce a new plot style "sizepoints".
>

Yeah, "sizepoints" is a good concept, but not a good "with" 
specification, or name, or whatever.  It really isn't something uniquely 
different from "points", but more a property of the point.

With "image" and "rgbimage", for example, those are similar, but 
distinctly different items.  Originally, before Petr suggested that 
alternative, I had one "image" and the color/palette image was assumed 
from the context of what is supplied.  That just isn't nice from the 
user's perspective.

I hear what you are saying about all this.  I find the syntax slightly 
limiting.  Well, not limiting because one can have up to seven or eight 
columns.  But several things are problematic.  Even programming is quite 
involved.  So many if's and switches.  Looking through plot2d.c and 
plot3d.c is quite difficult.  And then there are some styles for which 
the method is a tad different than the manner used elsewhere.

As a side note, instead of so many lengthy switches and such, it reaches 
a point where tables of properties and/or functions has an advantage.

And one thing I particularly don't like is that if one wants to use one 
property of a style, but it follows a different property that is 
supposed to come before it because of the mandatory columns and meaning 
rule, then you have to supply that column, even though it could be 
extraneous.

Maybe the following would be too much, but in some sense I'd prefer a 
syntax where after the style could be a list of keywords to go along 
with that style.  These keywords could be aspects unique to that style 
and column information unique to that style.  (What I'm proposing here 
is just a brainstorming sort of thing, not an idea I've had in mind.) 
 Let me use a hypothetical "points".  For example:

1) plot 'foo' using 1:2:3 with points color=red x:y:size
2) plot 'foo' using 2:1:3 with points size=1.5 x:y:color
3) plot 'foo' using 1:2:3 with points size=1.5 y:x:color

You see a natural relationship here between the "using" and the 
"properties mapping" that follows the points.  Here, 2 and 3 are exactly 
the same, so there is redundancy, but big deal.  There could be some 
defaults if you wish, which boil down to the current assumptions about 
column meanings.  The nice thing about such a syntax is that it is 
obvious just what is being plotted by looking at the command.  Compare

plot 'foo' using 1:2:3 with points color=red x:y:size

with

plot 'foo' using 1:2:3:4 with points

where in the data file the user must place a third column that always 
stands for red.  (I guess that's not true.  One could put a constant 
inside of the using string instead of putting an extraneous column in 
the file.  But still, it's the same principle, the user has to fill in 
an obscure column having an assigned meaning.)

This seems like a bit of work, but once one sets up a table or two, 
things would roll along.  For example, the using spec tells how the 
v[0], v[1], v[2], are filled in, and the "properties" spec tells how the 
v[0], v[1], etc get mapped into the points[i] array.

prop_table points[] = {
   {"x", 0},
   {"y", 1},
   {"col$er", 2},
   {"si$ze", 3}
};

Then there could be a table of defaults for the above table that can be 
overridden with things like "size = 4", "color=blue", etc. after the 
style.  My guess is that the code to go this route would be cleaner than 
so many "if # columns is this and style is this and etc."

That would be a long, long term project.  I think first it would be wise 
to make plot2d.c and plot3d.c more similar.

Dan