All graph data entries must have a x and y coordinates.
It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.
Just as users (e.g. me) of a cmd line plotting routine
expect to call
$ bozoplot results.dat
with two columns entries:
0 1
1 3 etc
and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.
Francisco.
Logged In: YES
user_id=405853
Couldn't you do this within your bozoplot command? The point is that
graph.data.file and the like do not know anything about the column
names they need to fill with data. It's designed the other way around.
You provide some data and the graph styles (by the help of the axis
names available in the graph) will tell you, whether this is a valid
request. I do not want to stress that too much, especially since we
currently have an xy graph only, but the axis names could be completely
different in an polar plot, a 3-d plot etc. And other graph styles like text,
arrow, errorbars etc. want other data as well. I would not like to see a
semi-guessing solution in PyX. Comments?
Logged In: YES
user_id=390410
I agree with Andr. Such a policy should not be part
of the data component. In order to support quick&easy
plotting, a wrapper providing some standard plot types as
suggested recently by Michael Hagemann on the pyx-user is
the way to go.
Logged In: YES
user_id=576554
making one myself.
I have some code that already works as a wrapper but it's
scathered and as I need to deliver a thesis chapter by the
end of this month, I haven't actually started putting the
code pieces together.
faster and a wrapper won't help much at it. When drawing
some illustrative didactic graphs for my thesis, I end up
calling data.list 4 or 5 times in a file, (and that's using
attr.changelist([a,b,c]) to avoid extra calls as in:
g.plot([ data.list(i, x=1, y=2, text=3) for i in [pts, pts1,
pts2] ],
[st.line([attr.changelist(
[linewidth.thick, linewidth.normal,linewidth.normal] ),
attr.changelist(
[linestyle.solid, linestyle.dashdotted, linestyle.dashdotted
] )]),
st.text(textdx=0.5, textdy=0)])
Perhaps allow setting default values at a data.list instance
initialization and then allow more instances to be created
from this one?
dlst = data.list(None, x=1, y=2, dy=3) # setting default values.
g.plot(dlst(d1, text=4), style1)
g.plot(dlst(d2, stacked=4), style2)
I don't know exactly how this should be implemented, as you
seem to need different data.list objects to process, the
class object would have to became a object factory
separating the current data.list.init method into
init and call. Hackish solutions in this direction
would be easy to implement and a more clean version
shouldn't be too much of a problem.
Logged In: YES
user_id=405853
Sure, many things could be done. But we do not use call too much.
(There is a use case in the attribute modification and thats fine but I
don't know whether its appropriate at an data instance. May be ... could
be. It would be kind of a convenience method.)
But back to your problem: You could just "decorate" an arbitrary callable
thing by some additional keyword argument (when they are not
overwritten). This could look like that:
def decorate(callable, addkwargs):
def decorator(*args, kwargs):
fullkwargs = addkwargs.copy()
fullkwargs.update(kwargs)
callable(args, *fullkwargs)
return decorator
def test(args, *kwargs):
print args, kwargs
test(1, 2, a=1, b=2)
testdeco = decorate(test, b=-2, c=-3)
testdeco(1, 2, a=1, b=2)
A way to go for you?
Beside that, Jrg, what's your opinion about making a data instance
callable to create a new data instance out of an existing one. Thats what
graph.data.data is for right now. But using graph.data.data we do not
keep the old columns ...
Logged In: YES
user_id=405853
Still, data.data is the proposed solution here. Anyway, I've modified its
behaviour to (by default) keep the original columns with their names. This
adds additional flexibility and you now can give the axis names in the data
files without repeating them in PyX. I think its about all we should do.