matplotlib-devel Mailing List for matplotlib

Jeff Klukas wrote:
> When plotting multiple data with one Axes.hist call, the method's
> interface allows you to specify a list of labels to the 'label' kwarg
> to distinguish between the datasets.  To get different colors,
> however, you cannot give a list of colors to 'color'; instead, you
> have to leave out the 'color' kwarg and change the color cycle.
> 
> Is there any reason why the color kwarg can't work like label?  I
> spent an hour or two trying to debug a script before I realized that
> 'color' wasn't being interpreted as I expected.  I realize that there
> is some ambiguity since a color argument can be an rgb or rgba
> sequence.  My proposal would be that 'color' would be interpreted as a
> list of distinct colors only when multiple datasets are given as input
> and len(color) equals the number of datasets.
> 
> I find it hard to imagine a case where you would want to set all
> datasets to be the same color, so I don't think the ambiguity would be
> a major issue.  I would be happy to write and submit an implementation
> if others think this is a reasonable idea.

Sounds good to me.  I agree that it makes no sense to have to set the 
color cycle for hist (although using the color cycle as a default is 
reasonable), and I think it is just an artifact of the way hist has evolved.

Eric

> 
> Cheers,
> Jeff
> 
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://www.hep.wisc.edu/~jklukas/
> 

When plotting multiple data with one Axes.hist call, the method's
interface allows you to specify a list of labels to the 'label' kwarg
to distinguish between the datasets.  To get different colors,
however, you cannot give a list of colors to 'color'; instead, you
have to leave out the 'color' kwarg and change the color cycle.

Is there any reason why the color kwarg can't work like label?  I
spent an hour or two trying to debug a script before I realized that
'color' wasn't being interpreted as I expected.  I realize that there
is some ambiguity since a color argument can be an rgb or rgba
sequence.  My proposal would be that 'color' would be interpreted as a
list of distinct colors only when multiple datasets are given as input
and len(color) equals the number of datasets.

I find it hard to imagine a case where you would want to set all
datasets to be the same color, so I don't think the ambiguity would be
a major issue.  I would be happy to write and submit an implementation
if others think this is a reasonable idea.

Cheers,
Jeff

|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/

Just wanted to let you all know that Packt Publishing just sent us
their first donation for Sandro Tosi's  Matplotlib for Python
Developers, which is part of their quarterly revenue sharing program
-- the first quarter amount was $320 after paypal fees

  http://www.packtpub.com/matplotlib-python-development/book?utm_source=matplotlib.sourceforge.net&utm_medium=link&utm_content=pod&utm_campaign=mdb_002124

This brings our current donations total to $975, which is not yet
enough for a sprint but is starting to be enough to sponsor conference
travel, a developer laptop or build machine, educational materials or
something along those lines.  My preference is to save for a sprint,
but if you have a need or an idea float it by us.

JDH

On Mon, Mar 29, 2010 at 12:30 PM, Jeff Klukas <kl...@wi...> wrote:
> # Create BrokenAxes with bottom from 0 to 5 and top from 30 to 35
> ax = plt.broken_axes(ybounds=[0.,5.,30.,35.])
> # Plot a line onto BOTH subaxes
> ax.plot(range(35),range(35))
>
> The call to plot would get routed through __getattribute__, which
> would then call plot for each of the subaxes.  This would be much more
> intuitive than my existing breaky solution, where you have to loop
> over all subaxes and plot on each individually.
>

How do you want to handle

l1, = ax.plot(range(35), range(35))
l1.set_color("r")

then?

I think keeping two (or more) separate artists for each axes while an
user think there is only one artist (because only one axes is exposed
to the user) is not a good idea.

Regards,

-JJ

I haven't heard a response back about the proposal I posted for broken
axes.  Hopefully that just means people are busy :).   If there are
concerns about the method or interface, I'm certainly open to hearing
them.

In the meantime, I've been thinking about the interface, and I think
the more correct and more ambitious thing to do would be to create a
new BrokenAxes class that inherits from Axes.  The class could
redefine __getattribute__ to pass most function calls straight to the
subaxes.  So in the end a session could look like the following:

# Create BrokenAxes with bottom from 0 to 5 and top from 30 to 35
ax = plt.broken_axes(ybounds=[0.,5.,30.,35.])
# Plot a line onto BOTH subaxes
ax.plot(range(35),range(35))

The call to plot would get routed through __getattribute__, which
would then call plot for each of the subaxes.  This would be much more
intuitive than my existing breaky solution, where you have to loop
over all subaxes and plot on each individually.

The more ambitious thing to do would be to also define a BrokenAxis
class that inherits from Axis and would redefine get_ticklabel_extents
to look as each subaxis and push the axis label far enough out to
clear the ticklabels on all subaxes.

Does that new interface sound like a good idea?  Are there any
show-stopping problems that seem apparent.  If it sounds like
something worth trying, I could take a stab at writing an
implementation.

Cheers,
Jeff

|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/



On Thu, Mar 18, 2010 at 1:38 PM, Jeff Klukas <kl...@wi...> wrote:
> I have implemented breakx and breaky methods for the Axes class and
> attached the diff for axes.py to this message.
>
> You can test out the function with the following examples:
> ------------------
> import numpy as np
> import matplotlib as mpl
> import matplotlib.pyplot as plt
>
> # Broken y
> fig = plt.figure()
> main_axes = plt.axes()
> plt.title('Broken x-axis example')
> plt.xlabel('x-axis label')
> subaxes = main_axes.breaky([0., 1.9, 5.1, 6.9, 9.1, 12])
> for axes in subaxes:
>    axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
> plt.ylabel('y-axis label')
> plt.show()
>
> ------------------
> import numpy as np
> import matplotlib as mpl
> import matplotlib.pyplot as plt
> # Broken x
> fig = plt.figure()
> main_axes = plt.axes()
> plt.title('Broken x-axis example')
> plt.ylabel('y-axis label')
> subaxes = main_axes.breakx([0., 1.9, 5.1, 6.9, 9.1, 12])
> for axes in subaxes:
>    axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
> plt.xlabel('x-axis label')
> plt.show()
> ---------------------
>
> I've included in the docstrings some of the TODO items, but this is
> pretty stable in its current form.
>
> Cheers,
> Jeff
>
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://www.hep.wisc.edu/~jklukas/
>
>
> On Tue, Mar 16, 2010 at 1:08 PM, Jeff Klukas <kl...@wi...> wrote:
>>> What would be great is if you could refactor the basic functionality
>>> into a matplotlib.Axes.breaky method (and possibly breakx but most
>>> people request a broken y axis), which would resize the "self" axes
>>> and return the broken compliment which could be plotted onto.  Then
>>> you could provide a thin pyplot wrapper much like pyplot.twinx, so
>>> that pyplot as well as API users could benefit.
>>
>> I can try to do this.  I think I would prefer, however, not to resize
>> the "self" axes and continue with my current approach of creating two
>> new axes within the original axes.  On the user end, I think it makes
>> more sense to set the title and ylabel of the main axes, rather than
>> setting them for the individual upper and lower axes.  More on that
>> below.
>>
>>>> The only real problems here is that you need to
>>>> explicitly plot things on both the upper and lower axes, and then I haven't
>>>> figured out how to push out the y-axis label of the main axes object so it
>>>> doesn't overlap with the tick labels of the upper and lower axes.  So, I
>>>> instead moved the y-labels of the upper and lower axes so that they appear
>>>> at the center of the axis, but this is problematic.  Any thoughts on how to
>>>> do that part better?
>>>
>>> klukas, I'm afraid I don't understand your issue... Can you explain using it differently?
>>
>> In my approach, you end up with a main axes object that is invisible,
>> and then two visible axes objects (upper and lower) within the main
>> axes.  I would ideally like to have the y label display in the middle
>> of the main y-axis, independent of where the break lies.  If I place a
>> y label on the main axes (which has ticks or tick labels), though, it
>> appears right up against the axis line.  I'd like it to be placed
>> further to the left, clear of the tick labels that appear on the upper
>> and lower axes.  So, I'd like to be able to access whatever algorithm
>> is used to choose the offset of the axis label, and explicitly set the
>> offset of the ylabel for the main axes so that it clears the tick
>> labels.
>>
>> // Jeff
>>
>

please find attached the 2 patched files and the diff vs trunk.

the legend only appears if there is at least one curve label which
doesn't start by "_"


On Sun, Mar 28, 2010 at 2:12 PM, Peter Butterworth <bu...@gm...> wrote:
> I've done a few minor enhancements and corrections to the qt4_editor
> (interactive plot options popup). Should I submit them to matplotlib
> or directly to the original author Pierre Raybaut ?
>
> What plot options do you think can be added to the qt4_editor ?
> I've added a basic Legend option to the Axes tab and a Visible option
> to the Curves tab.
>
>
> formlayout.py:
> validate color strings (for matplotlib)
>
> figureoptions.py:
> corrected marker=='none' bug
> corrected matplotlib green in COLORS ('g': '#008000')
> missing ',' and incorrect naming of some MARKERS
> LINESTYLES are sorted. 'steps' removed from linestyles

I've done a few minor enhancements and corrections to the qt4_editor
(interactive plot options popup). Should I submit them to matplotlib
or directly to the original author Pierre Raybaut ?

What plot options do you think can be added to the qt4_editor ?
I've added a basic Legend option to the Axes tab and a Visible option
to the Curves tab.


formlayout.py:
validate color strings (for matplotlib)

figureoptions.py:
corrected marker=='none' bug
corrected matplotlib green in COLORS ('g': '#008000')
missing ',' and incorrect naming of some MARKERS
LINESTYLES are sorted. 'steps' removed from linestyles


On Sun, Mar 21, 2010 at 5:22 AM, Peter Butterworth wrote:
> Correction: '0.99.3rc1' does not include the qt4_editor code, so you
> do need to get the source files from svn.
>
> The feature is a nice addition to matplotlib..

Greetings everyone,

This year, there will be two days of tutorials (June 28th and 29th) before the
main SciPy 2010 conference. Each of the two tutorial tracks (intro, advanced)
will have a 3-4 hour morning and afternoon session both days, for a total of 4
intro sessions and 4 advanced sessions.

The main tutorial web page for SciPy 2010 is here:

http://conference.scipy.org/scipy2010/tutorials.html

We are currently in the process of planning the tutorial sessions. You
can help us in two ways:

Brainstorm/vote on potential tutorial topics
============================================

To help us plan the tutorials, we have setup a web site that allow everyone in
the community to brainstorm and vote on tutorial ideas/topics.

The website for brainstorming/voting is here:

http://conference.scipy.org/scipy2010/tutorialsUV.html

The tutorial committee will use this information to help select the tutorials.
Please jump in and let us know what tutorial topics you would like to see.

Tutorial proposal submissions
=============================

We are now accepting tutorial proposals from individuals or teams that would
like to present a tutorial. Tutorials should be focused on covering a well
defined topic in a hands on manner. We want to see tutorial attendees coding!

We are pleased to offer tutorial presenters stipends this year for the first
time:

    * 1 Session: $1,000 (half day)
    * 2 Sessions: $1,500 (full day)

Optionally, part of this stipend can be applied to the presenter's
registration costs.

To submit a tutorial proposal please submit the following materials
to 201...@sc... by April 15:

* A short bio of the presenter or team members.
* Which track the tutorial would be in (intro or advanced).
* A short description and/or outline of the tutorial content.
* A list of Python packages that attendees will need to have installed to
  follow along.

Eric,

I just hit a problem with using quiver with Basemap when when
angles='xy'.  Because Basemap's x,y units are in meters, you end up
with angles that are quantized due to floating point truncation
(30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
problem, but it probably should be automatically scaled, as noted in
the comments:

        elif self.angles == 'xy' or self.scale_units == 'xy':
            # We could refine this by calculating eps based on
            # the magnitude of U, V relative to that of X, Y,
            # to ensure we are always making small shifts in X, Y.

I managed to fix the problem locally by setting:

            angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
self.XY.max())

but I'm not sure if you would want a different fix. If you're happy
with this fix, I'll go ahead an check in.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Greetings everyone,

This year, there will be two days of tutorials (June 28th and 29th) before the
main SciPy 2010 conference. Each of the two tutorial tracks (intro, advanced)
will have a 3-4 hour morning and afternoon session both days, for a total of 4
intro sessions and 4 advanced sessions.

The main tutorial web page for SciPy 2010 is here:

http://conference.scipy.org/scipy2010/tutorials.html

We are currently in the process of planning the tutorial sessions. You
can help us in two ways:

Brainstorm/vote on potential tutorial topics
============================================

To help us plan the tutorials, we have setup a web site that allow everyone in
the community to brainstorm and vote on tutorial ideas/topics.

The website for brainstorming/voting is here:

http://conference.scipy.org/scipy2010/tutorialsUV.html

The tutorial committee will use this information to help select the tutorials.
Please jump in and let us know what tutorial topics you would like to see.

Tutorial proposal submissions
=============================

We are now accepting tutorial proposals from individuals or teams that would
like to present a tutorial. Tutorials should be focused on covering a well
defined topic in a hands on manner. We want to see tutorial attendees coding!

We are pleased to offer tutorial presenters stipends this year for the first
time:

   * 1 Session: $1,000 (half day)
   * 2 Sessions: $1,500 (full day)

Optionally, part of this stipend can be applied to the presenter's
registration costs.

To submit a tutorial proposal please submit the following materials
to 201...@sc... by April 15:

* A short bio of the presenter or team members.
* Which track the tutorial would be in (intro or advanced).
* A short description and/or outline of the tutorial content.
* A list of Python packages that attendees will need to have installed to
 follow along.

Cheers,

Brian Granger
SciPy 2010, Tutorial Chair

On 22 March 2010 12:48, Jae-Joon Lee <lee...@gm...> wrote:
> I guess I misunderstood your original issue.
> I think I fixed this in r8210. So please give it a try.

Ah, thank you, that does appear to have solved it. (I'll double-check
when I don't have to run it through an ssh tunnel, but the display
looks good.)

Thanks,
Anne

> Regards,
>
> -JJ
>
>
> On Sun, Mar 21, 2010 at 6:42 PM, Anne Archibald
> <aar...@ph...> wrote:
>> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>>
>>>
>>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>>> wrote:
>>>>
>>>> Often when I want to
>>>> zoom in, I want to change only (say) the upper x and y limits.
>>>
>>> I pushed a change into the svn that enables this, but in a different way
>>> than you suggested.
>>> The behavior I implemented is similar to the current behavior of the "pan"
>>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>>> is updated. Same for "y" key.
>>> I hope this is good for your needs also.
>>
>> Well, it's an interesting feature, but it doesn't address the problem
>> I'm seeing.
>>
>> What I'd like to be able to do is, say, to change only the upper x and
>> y limits, simply click where I want those limits to be and drag right
>> off the corner of the plot. This actually works, but when I do this
>> the drag rectangle freezes the moment my pointer leaves the axes, so
>> that it does not represent the area being zoomed to.
>>
>> I've attached a screenshot illustrating the bug. Note where the
>> pointer is and where the "to be zoomed" rectangle is.
>>
>> I use Linux, with the default backend, whatever that is.
>>
>> Anne
>>
>>> Regards,
>>> -JJ
>>>
>>
>

On Mon, Mar 22, 2010 at 11:50 AM, Jörgen Stenarson
<jor...@bo...> wrote:

> Would it be possible to put the draw in the ipython_prompt hook. That
> way it is always called after you have done something.

I like this approach better, because one problem with doing it in the
mpl Artist layer is that one artist setter may call another, and
trigger a series of calls to draw for what is only a single draw at
the interactive prompt.  ipython knows when an interactive call is
made, and can issue a draw.  The trick will be to manage something
like a "needdraw" flag for all mpl figures, which is set when any
property contained in that fiugure changed and flushed when any call
to draw is made.  If we maintain this flag on all mpl setters and
flush it after all mpl draws, the ipython prompt hook could check the
flag and draw if needed when interactive is True.

Not sure it is worth the effort, since like JJ I tend to mostly use
the pyplot functions when working from the interactive shell and don't
mind calling "draw" when using the API.  I don't think API usage
should be encouraged for the interactive prompt -- but I don't think
it should be discouraged either -- it's just that in practice most
experienced users use the state machine in this case because it is
less typing and we needn't be pedantic, even when teaching <wink>.

JDH

Fernando Perez skrev 2010-03-22 01:10:
> On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee<lee...@gm...>  wrote:
>> On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez<fpe...@gm...>  wrote:
>>> I wonder if it's possible to put things like a draw_if_interactive()
>>> call at the end of the OO methods... I realize that pyplot was the
>>> only one meant to do that, but if we are to encourage using the OO api
>>> more, then it's going to have to be as pleasant to use as pyplot...  I
>>> don't know the codebase well enough to mess with this right now, so I
>>> hope someone who's more versed in that part of the code can make a fix
>>> for this whose  impact isn't too severe on the runtime of OO code.
>>
>> I'm not very inclined to this but I'll wait to hear what others think.
>> I use oo api in the interactive mode but I still prefer to call draw()
>> explicitly.
>> Of course, we can make it optional.
>
> Mmh, back to this one: I do think it would be something useful to have
> somewhere, because typing draw() after *every* operation when working
> interactively does get tiresome, it seems to me...  If we encourage
> calling subplots() for new teaching, then we do want it to be as
> pleasant as pyplot to use interactively, I think...
>

Would it be possible to put the draw in the ipython_prompt hook. That 
way it is always called after you have done something.

/Jörgen

I guess I misunderstood your original issue.
I think I fixed this in r8210. So please give it a try.

Regards,

-JJ


On Sun, Mar 21, 2010 at 6:42 PM, Anne Archibald
<aar...@ph...> wrote:
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
>

Rectangle selection also kind of bugs out when you reach the edge of the axes.  I looked into fixing this a while ago and had a partial solution.  The rectangle selector does some inaxes checking and relies on the xdata and ydata values.  These are invalid outside the axes, but you can fake it by using the pixel values and a the axes transform.  It might be worth adding a parameter to the rectangle selector to allow or disallow the rectangle to go outside of the axes.
-Ben


-----Original Message-----
From: Anne Archibald [mailto:per...@gm...] 
Sent: Monday, March 22, 2010 11:39 AM
To: Drain, Theodore R (343P)
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot

On 22 March 2010 11:32, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I'd like to throw another vote in for this feature as well.  We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.

I'd just like to point out that it's the UI that's deceptive: you can
actually zoom to the edges by doing just what you'd expect, but the
box showing where you're zooming to is wrong.

Anne

> Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure).  When the mouse is released, the limits are reduced by the current axes values before applying the zoom.  Something like:
>
> - mouse click outside the figure - handle like normal
> - mouse click inside the figure - start zooming
> - mouse drag - draw zoom box
> - mouse leaves figure - keep drawing zoom box (change from current havior)
> - mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
> - zoom
>
> Hope that helps...
>
> Ted
> ________________________________________
> From: Anne Archibald [aar...@ph...]
> Sent: Sunday, March 21, 2010 3:42 PM
> To: Jae-Joon Lee
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
>
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sun, Mar 21, 2010 at 8:10 PM, Fernando Perez <fpe...@gm...> wrote:
> Mmh, back to this one: I do think it would be something useful to have
> somewhere, because typing draw() after *every* operation when working
> interactively does get tiresome, it seems to me...  If we encourage
> calling subplots() for new teaching, then we do want it to be as
> pleasant as pyplot to use interactively, I think...
>

I think the first issue that needs to be addressed is whether we want
to encourage OO api in the interactive mode (I mean, when a user
expect the figure gets updated as soon as a command is executed).

Using *subplots* does not necessarily mean that we need to use OO api,
since we now have *sca* in the pyplot namespace.

So. how other developers think?
Are we going to encourage OO api in the interactive mode?

Regards,

-JJ

You're correct - not sure what I was thinking of. 

I'm going to claim that it must have been this way in an older version and been fixed to make myself feel better...

________________________________________
From: Anne Archibald [per...@gm...]
Sent: Monday, March 22, 2010 8:39 AM
To: Drain, Theodore R (343P)
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot

On 22 March 2010 11:32, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I'd like to throw another vote in for this feature as well.  We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.

I'd just like to point out that it's the UI that's deceptive: you can
actually zoom to the edges by doing just what you'd expect, but the
box showing where you're zooming to is wrong.

Anne

> Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure).  When the mouse is released, the limits are reduced by the current axes values before applying the zoom.  Something like:
>
> - mouse click outside the figure - handle like normal
> - mouse click inside the figure - start zooming
> - mouse drag - draw zoom box
> - mouse leaves figure - keep drawing zoom box (change from current havior)
> - mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
> - zoom
>
> Hope that helps...
>
> Ted
> ________________________________________
> From: Anne Archibald [aar...@ph...]
> Sent: Sunday, March 21, 2010 3:42 PM
> To: Jae-Joon Lee
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
>
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 22 March 2010 11:32, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I'd like to throw another vote in for this feature as well.  We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.

I'd just like to point out that it's the UI that's deceptive: you can
actually zoom to the edges by doing just what you'd expect, but the
box showing where you're zooming to is wrong.

Anne

> Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure).  When the mouse is released, the limits are reduced by the current axes values before applying the zoom.  Something like:
>
> - mouse click outside the figure - handle like normal
> - mouse click inside the figure - start zooming
> - mouse drag - draw zoom box
> - mouse leaves figure - keep drawing zoom box (change from current havior)
> - mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
> - zoom
>
> Hope that helps...
>
> Ted
> ________________________________________
> From: Anne Archibald [aar...@ph...]
> Sent: Sunday, March 21, 2010 3:42 PM
> To: Jae-Joon Lee
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot
>
> On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>>
>>
>> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
>> wrote:
>>>
>>> Often when I want to
>>> zoom in, I want to change only (say) the upper x and y limits.
>>
>> I pushed a change into the svn that enables this, but in a different way
>> than you suggested.
>> The behavior I implemented is similar to the current behavior of the "pan"
>> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
>> is updated. Same for "y" key.
>> I hope this is good for your needs also.
>
> Well, it's an interesting feature, but it doesn't address the problem
> I'm seeing.
>
> What I'd like to be able to do is, say, to change only the upper x and
> y limits, simply click where I want those limits to be and drag right
> off the corner of the plot. This actually works, but when I do this
> the drag rectangle freezes the moment my pointer leaves the axes, so
> that it does not represent the area being zoomed to.
>
> I've attached a screenshot illustrating the bug. Note where the
> pointer is and where the "to be zoomed" rectangle is.
>
> I use Linux, with the default backend, whatever that is.
>
> Anne
>
>> Regards,
>> -JJ
>>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I'd like to throw another vote in for this feature as well.  We have a lot of cases like this and not being able to zoom to the limits of the window is a real head ache.

Back in the old days (when we were maintaining our own plot library), we solved this by allowing the bounding rectangle to be drawn outside the figure (assuming the mouse started inside the figure).  When the mouse is released, the limits are reduced by the current axes values before applying the zoom.  Something like:

- mouse click outside the figure - handle like normal
- mouse click inside the figure - start zooming
- mouse drag - draw zoom box
- mouse leaves figure - keep drawing zoom box (change from current havior)
- mouse release - if mouse is outside figure zoom box started in, reduce zoom box to limits of axes (change from current behavior)
- zoom

Hope that helps...

Ted
________________________________________
From: Anne Archibald [aar...@ph...]
Sent: Sunday, March 21, 2010 3:42 PM
To: Jae-Joon Lee
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Selecting all the way to the edge of a plot

On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>
>
> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
> wrote:
>>
>> Often when I want to
>> zoom in, I want to change only (say) the upper x and y limits.
>
> I pushed a change into the svn that enables this, but in a different way
> than you suggested.
> The behavior I implemented is similar to the current behavior of the "pan"
> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
> is updated. Same for "y" key.
> I hope this is good for your needs also.

Well, it's an interesting feature, but it doesn't address the problem
I'm seeing.

What I'd like to be able to do is, say, to change only the upper x and
y limits, simply click where I want those limits to be and drag right
off the corner of the plot. This actually works, but when I do this
the drag rectangle freezes the moment my pointer leaves the axes, so
that it does not represent the area being zoomed to.

I've attached a screenshot illustrating the bug. Note where the
pointer is and where the "to be zoomed" rectangle is.

I use Linux, with the default backend, whatever that is.

Anne

> Regards,
> -JJ
>

I have two zorder-related complaints:

(1) The default zorder is not reasonable. If I plot a bar chart and then 
overlay a scatter diagram, the scatter diagram symbols are behind the 
bars. If I reverse the order, i.e., I generate the scatter diagram 
first, the scatter diagram symbols are still behind the bars. This 
doesn't make sense. Something that gets plotted later should be on top 
of whatever was plotted earlier.

(2) One really has to poke around to find the documentation for zorder. 
It would be great if the documentation for something as important as 
this were easier to find.

Thanks!

Phillip

On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez <fpe...@gm...> wrote:
>> I wonder if it's possible to put things like a draw_if_interactive()
>> call at the end of the OO methods... I realize that pyplot was the
>> only one meant to do that, but if we are to encourage using the OO api
>> more, then it's going to have to be as pleasant to use as pyplot...  I
>> don't know the codebase well enough to mess with this right now, so I
>> hope someone who's more versed in that part of the code can make a fix
>> for this whose  impact isn't too severe on the runtime of OO code.
>
> I'm not very inclined to this but I'll wait to hear what others think.
> I use oo api in the interactive mode but I still prefer to call draw()
> explicitly.
> Of course, we can make it optional.

Mmh, back to this one: I do think it would be something useful to have
somewhere, because typing draw() after *every* operation when working
interactively does get tiresome, it seems to me...  If we encourage
calling subplots() for new teaching, then we do want it to be as
pleasant as pyplot to use interactively, I think...

Is it technically expensive to put in?

Cheers,

f

On 21 March 2010 18:10, Jae-Joon Lee <lee...@gm...> wrote:
>
>
> On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald <aar...@ph...>
> wrote:
>>
>> Often when I want to
>> zoom in, I want to change only (say) the upper x and y limits.
>
> I pushed a change into the svn that enables this, but in a different way
> than you suggested.
> The behavior I implemented is similar to the current behavior of the "pan"
> mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
> is updated. Same for "y" key.
> I hope this is good for your needs also.

Well, it's an interesting feature, but it doesn't address the problem
I'm seeing.

What I'd like to be able to do is, say, to change only the upper x and
y limits, simply click where I want those limits to be and drag right
off the corner of the plot. This actually works, but when I do this
the drag rectangle freezes the moment my pointer leaves the axes, so
that it does not represent the area being zoomed to.

I've attached a screenshot illustrating the bug. Note where the
pointer is and where the "to be zoomed" rectangle is.

I use Linux, with the default backend, whatever that is.

Anne

> Regards,
> -JJ
>

On Sun, Mar 21, 2010 at 6:07 PM, Eric Firing <ef...@ha...> wrote:

> I think your version would need an additional try/except or conditional,
> because a Figure doesn't necessarily have a canvas assigned to it, and a
> canvas doesn't necessarily have a manager.  Granted, the problem would arise
> only under odd circumstances involving a mixture of pyplot and OO
> styles--and maybe there is actually something that would prevent the problem
> from arising at all--but I would want to be sure the problem either was
> handled, or could not arise.  So, I think my version ends up being simpler,
> safer, and easier to understand--at least for me.
>

I see. Thanks!

-JJ

On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald
<aar...@ph...>wrote:

> Often when I want to
> zoom in, I want to change only (say) the upper x and y limits.
>

I pushed a change into the svn that enables this, but in a different way
than you suggested.
The behavior I implemented is similar to the current behavior of the "pan"
mode, i.e., if you hold the "x" key pressed during pan/zoom, only the x-axis
is updated. Same for "y" key.

I hope this is good for your needs also.

Regards,

-JJ

Jae-Joon Lee wrote:
> 
> 
> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
>         By the way, given that we now have "suplots" in the pyplot
>         namespace,
>         can we have sca also?
> 
> 
>     Done in svn 8205.
> 
> 
> 
> Eric,
> 
> A minor question. I wonder whether an explicit for-loop inside 
> pyplot.sca is necessary?
> Here is a slight variation w/o a for-loop (well, the for-loop is 
> implicitly done with the "in" operator I guess) that seems to work for 
> me, but I may be missing something.  
> 
>     managers = _pylab_helpers.Gcf.get_all_fig_managers()
>     if ax.figure.canvas.manager in managers and \
>            ax in ax.figure.axes:
>         _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager)
>         ax.figure.sca(ax)
>         return
>     raise ValueError("Axes instance argument was not found in a figure.")
> 
> Regards,
> 
> -JJ
> 

JJ,

I think your version would need an additional try/except or conditional, 
because a Figure doesn't necessarily have a canvas assigned to it, and a 
canvas doesn't necessarily have a manager.  Granted, the problem would 
arise only under odd circumstances involving a mixture of pyplot and OO 
styles--and maybe there is actually something that would prevent the 
problem from arising at all--but I would want to be sure the problem 
either was handled, or could not arise.  So, I think my version ends up 
being simpler, safer, and easier to understand--at least for me.

Eric