On Mon, 12 Jul 2004, Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:
> >I agree wholeheartedly that that code needs to be revamped in a major way.
> >But that has no relevance at all to the job to be done by datafile.c. As
> >long as the 'using' syntax is based on an unstructured list of expressions
> >rather than named columns like this
> >
> > plot 'data' using (x 1, y 2, yhigh 3, ylow 4)
[...]
> The above isn't such a bad idea in one sense; that is, it is more
> meaningful to the user *provided* the syntax makes sense. But that
> making sense part is the rub.
Please don't get all excited by that rough syntax sketch. It was really
just meant to point at the user interface syntax being the driving force
of how the datafile parsing code works, and especially why get_data() and
get_3ddata() work as they do. I'm by no means proposing we implement
anything like that example anytime soon. But as long as 'using' in
its current form exists, I don't see any way of actually getting rid
of the fiddling currently done by get_{3d,}data(). We can only hope
to structure it a bit better.
> Certainly, one can't expect the user to know there are these structure
> variables behind the curtain called "x", "y", "yhigh", "ylow", etc. and
> that it is their responsibility to know what goes where.
No. The above syntax doesn't require him to know "what goes where" ---
it's the existing code that does that. The above would just require the
user to know "what named values are there". I.e. they could just as well
have written
plot 'data' u (yhigh 3, y 2, ylow 4, x 1) w err
to express the exact same relation between data file and plot. As usual,
additional flexibility like that comes at a price: the command line gets
longer.
> If I'm not mistaken, there are plot types that use
> "yhigh", "ylow", etc. as just some variable which doesn't necessarily
> make sense to the context at hand.
Yes. I'm quite painfully aware of that, for all the grief it caused me
during the work on the 'axis branch'.
> So, right there you have moved the mess, pretty much in tact, from
> get_data() to somewhere else.
Not really. The mess we're talking about here (the mapping from data
values accessed a seris of 'using' specifiers to elements of 'struct
coordinate' (x,y,z,ylow,...) is currently a two-part one: part one is that
the number of specifiers changes the assignment from a position in the
using spec sequence to struct elements (e.g. errorbars: 3 columns mean
x:y:dy, 4 columns mean x:y:ylow:yhigh, i.e. the meaning of the third
specifier depends on whether there's a forth one or not). The *other*
aspect of the mess is that users have to memorize the order of using spec
for all plot styles. And as we keep adding plot styles and optional
values (acsplines, color mapping and whatnot), that's only getting worse.
[...]
> configuration inside a table. That is, there is the enumeration for the
> PLOT_STYLE and one could build tables off of that.
Or rather, I guess what we should consider is a re-organization of the
entire way plot styles are handled. The current 'enum with flags in'
approach of defining plot style indices as magic numbers is of rather
limited versatility, and more of a hack than a proper design.
Currently we have 9 switch() statements over the plot type, and about 90
other comparisons of the plot_style field with particular types, scattered
all across the 4 inner core modules (plot[23]d, graphics, graph3d) and
several others. I think this would all make a lot more sense if we
collected at least all code governed by those switch()es, but possibly
more, in one contiguous block of code *per plot style*. I.e. all special
code for handling the 'with yerrorbars' style should be in *one* place.
--
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.
|
