steps in plot()

doing this would be to incorporate it into the plot()

    > command. Perhaps adding an option 'steps' (following
    > gnuplot's convention could have steps equal 'histeps',
    > 'fsteps' or just 'steps' - see link above.. None could mean
    > regular plot() behavior). I would say this would be the
    > most elegant option, but probably would call for John (or
    > someone else from the core developers) to make the
    > changes. Alternatively we could use above and wrap it in a
    > plot_step() function.

    > Any interest in this? If so which way do we want to go?

It might be easiest to make this a line style. Then you could use the
builtin kwarg linestyle

  plot(x, y, linestyle='steps')

It shouldn't be too hard to modify lines.py to support this. If you
want to take a stab at it, I'd be happy to include it. The nice thing
about making it a line style is that the changes required would all be
contained to the lines.py file which is simple and clear. If you
change how plot processes its arguments, it's easy to foul things up.

The only potential problem I see is this would prevent you from, for
example, having a dashed stepped line, since dash is itself a line
style. But who needs a dashed stepped line, for heaven's sake?

JDH

John Hunter wrote:

"Peter" == Peter Groszkowski <pgroszko@...84...> writes:

   > doing this would be to incorporate it into the plot()
   > command. Perhaps adding an option 'steps' (following
   > gnuplot's convention could have steps equal 'histeps',
   > 'fsteps' or just 'steps' - see link above.. None could mean
   > regular plot() behavior). I would say this would be the
   > most elegant option, but probably would call for John (or
   > someone else from the core developers) to make the
   > changes. Alternatively we could use above and wrap it in a
   > plot_step() function.

   > Any interest in this? If so which way do we want to go?

It might be easiest to make this a line style. Then you could use the
builtin kwarg linestyle

plot(x, y, linestyle='steps')

It shouldn't be too hard to modify lines.py to support this. If you
want to take a stab at it, I'd be happy to include it.

Alrgith.. .this is my version of it.. just modifies lines.py (i'm using 0.60.2 by the way).. :

    def _draw_steps(self, renderer, gc, xt, yt):
        siz=len(xt)
        if siz<2: return
        xt2=ones((2*siz,), xt.typecode())
        xt2[0:-1:2], xt2[1:-1:2], xt2[-1]=xt, xt[1:], xt[-1]
        yt2=ones((2*siz,), yt.typecode())
        yt2[0:-1:2], yt2[1::2]=yt, yt
        gc.set_linestyle('solid')
        gc.set_capstyle('projecting')
        renderer.draw_lines(gc, xt2, yt2)

also changed:

class Line2D(Artist):
    _lineStyles = {
        '-' : '_draw_solid',
        '--' : '_draw_dashed',
        '-.' : '_draw_dash_dot',
        ':' : '_draw_dotted',
        'steps': '_draw_steps',
        'None' : '_draw_nothing'}
   and:

lineStyles = {'-':1, '--':1, '-.':1, ':':1, 'steps':1, 'None':1}

maybe a more memory friendly way to do this would be to loop through the arrays xt,yt and create extra points on the fly; then draw lines separately, but from my testing this current way seems (by far) the fastest.. im got lots of RAM and am in 'need for speed', so this works for me..

The nice thing
about making it a line style is that the changes required would all be
contained to the lines.py file which is simple and clear. If you
change how plot processes its arguments, it's easy to foul things up.

yeah.. now that i know how things work a little better - i agree..

The only potential problem I see is this would prevent you from, for
example, having a dashed stepped line, since dash is itself a line
style. But who needs a dashed stepped line, for heaven's sake?

could always add.. 'steps--' if needed.. althought that's a little ugly!..