Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1 default args for data.(list|file)(x=1,y=2)

closed
nobody
5
2012-10-16
2005-02-07
No

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.

Discussion

  • Andre Wobst
    Andre Wobst
    2005-02-08

    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?

     
  • Jörg Lehmann
    Jörg Lehmann
    2005-02-08

    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

    1. I think a wrapper would be nice and I thought about
      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.

    1. Yet, I still would like to be able to code some things
      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.

     
  • Andre Wobst
    Andre Wobst
    2005-02-10

    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 ...

     
  • Andre Wobst
    Andre Wobst
    2005-03-24

    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.