matplotlib-devel Mailing List for matplotlib (Page 4)

On Tue, Oct 12, 2010 at 9:23 AM, John Hunter <jd...@gm...> wrote:
> On Tue, Oct 12, 2010 at 10:55 AM, Keith Goodman <kwg...@gm...> wrote:
>> Thanks for the code. I added matplotlib's yahoo historical quote code
>> to my labeled array package, la. While doing so I noticed a couple of
>> possible bugs:
>>
>> - The doc string for parse_yahoo_historical says that the volume is
>> adjusted. But I don't see a line of code that does the adjustment.
>
> We don't do the adjustment, Yahoo does.  Eg, take a look at CROX
> around their 6/15/07 split.
>
>  http://finance.yahoo.com/q/hp?s=CROX&a=05&b=1&c=2007&d=06&e=1&f=2007&g=d
>
> IDC reports consolidated volume on 6/14/07 (pre-split) was 4,366,319
> shares.  Yahoo reports 8,726,000 -- which is close to 2x the raw
> volume (I assume the difference is in how some of the shares
> transacted on non-primary exchanges are counted).  Likewise,  on
> 6/13/07, IDC reports
> 7,852,268 and Yahoo reports 15,544,200, which is close to 2x.  So it
> appears they are backward split adjusting the volume.

I knew it was worth it (to me) to report what I thought was a bug. Thanks.

Well, then perhaps the doc string needs tweaking?

    *adjusted*
      If True (default) replace open, close, high, low, and volume with
      their adjusted values.
      The adjustment is by a scale factor, S = adjusted_close/close.
      Adjusted volume is actual volume divided by S;
      Adjusted prices are actual prices multiplied by S.  Hence,
      the product of price and volume is unchanged by the adjustment.

It does state that volume is adjusted by S (where S contains dividend
info). I take it that volume is the same whether adjusted is True or
False, which means that dollar volume is not unchanged.

On Tue, Oct 12, 2010 at 10:55 AM, Keith Goodman <kwg...@gm...> wrote:
> Thanks for the code. I added matplotlib's yahoo historical quote code
> to my labeled array package, la. While doing so I noticed a couple of
> possible bugs:
>
> - The doc string for parse_yahoo_historical says that the volume is
> adjusted. But I don't see a line of code that does the adjustment.


We don't do the adjustment, Yahoo does.  Eg, take a look at CROX
around their 6/15/07 split.

  http://finance.yahoo.com/q/hp?s=CROX&a=05&b=1&c=2007&d=06&e=1&f=2007&g=d

IDC reports consolidated volume on 6/14/07 (pre-split) was 4,366,319
shares.  Yahoo reports 8,726,000 -- which is close to 2x the raw
volume (I assume the difference is in how some of the shares
transacted on non-primary exchanges are counted).  Likewise,  on
6/13/07, IDC reports
7,852,268 and Yahoo reports 15,544,200, which is close to 2x.  So it
appears they are backward split adjusting the volume.

> quotes_historical_yahoo builds an error message from a variable
> named "url" which doesn't exist in the scope of the function

Fixed -- this was a legacy error message when we used to pass in urls
but now pass in filehandles

> "import time" and "from matplotlib.cbook import is_string_like" are not used

Fixed.

Thanks for the report -- fixed on the branch (8742) and will be merged
to the trunk when MD resuscitates svnmerge....

JDH

Thanks for the code. I added matplotlib's yahoo historical quote code
to my labeled array package, la. While doing so I noticed a couple of
possible bugs:

- The doc string for parse_yahoo_historical says that the volume is
adjusted. But I don't see a line of code that does the adjustment.
- quotes_historical_yahoo builds an error message from a variable
named "url" which doesn't exist in the scope of the function
- "import time" and "from matplotlib.cbook import is_string_like" are not used

I stripped down the code keeping only what I needed:

http://github.com/kwgoodman/la/blob/master/la/external/matplotlib.py

Here's a demo of how I use it:

    >>> from la.data.yahoo import quotes
    >>> lar = quotes(['aapl', 'msft'], (2010,10,1), (2010,10,5))
    >>> lar
    label_0
        aapl
        msft
    label_1
        open
        close
        high
        low
        volume
    label_2
        2010-10-01
        2010-10-04
        2010-10-05
    x
    array([[[  2.86150000e+02,   2.81600000e+02,   2.82000000e+02],
            [  2.82520000e+02,   2.78640000e+02,   2.88940000e+02],
            [  2.86580000e+02,   2.82900000e+02,   2.89450000e+02],
            [  2.81350000e+02,   2.77770000e+02,   2.81820000e+02],
            [  1.60051000e+07,   1.55256000e+07,   1.78743000e+07]],

           [[  2.47700000e+01,   2.39600000e+01,   2.40600000e+01],
            [  2.43800000e+01,   2.39100000e+01,   2.43500000e+01],
            [  2.48200000e+01,   2.39900000e+01,   2.44500000e+01],
            [  2.43000000e+01,   2.37800000e+01,   2.39100000e+01],
            [  6.26236000e+07,   9.80868000e+07,   7.80329000e+07]]])

    >>> close = lar.lix[:,['close']]
    >>> close
    label_0
        aapl
        msft
    label_1
        2010-10-01
        2010-10-04
        2010-10-05
    x
    array([[ 282.52,  278.64,  288.94],
           [  24.38,   23.91,   24.35]])

    Calculate the log return from the close prices:

    >>> ret = close / close.lag(1, axis=-1)
    >>> ret = ret.log()
    >>> ret
    label_0
        aapl
        msft
    label_1
        2010-10-04
        2010-10-05
    x
    array([[-0.01382872,  0.03629843],
           [-0.01946634,  0.01823507]])

Hello Eric and Fernando,

thank you very much for your answers.  It helped :-/  I think I was a
bit too fast here.  Eric, you are precisely right, I should have done
more investigation before.  I think this issue (my issue) should be
clarified now.  I was just alert by the feedback of other users about
hang-ups, I don't know if it was a good idea to bring this to the
list, though.  My apologises.  Just had too many hidden hang-ups in my
own threaded Tkinter code.

Talking is cheap :-/

Friedrich

2010/10/10 Fernando Perez <fpe...@gm...>:
> Two things to note:
>
> - ipython, even in the 0.10 series, uses threads for the Qt, Gtk and
> Wx backends, but *not* for Tk, because python automatically pumps the
> Tk event loop when the console blocks on reading (via the C API
> PyOSInputHook call).  So there is exactly *zero* threading added by
> ipython in the specific case of a Tk backend.

This is very interesting, I always asked myself how this works.

> - in the 0.11 ipython series, we abandoned threading altogether (it's
> just too brittle) and moved to a model similar to the Tk one for *all*
> backends, we now use PyOSInputHook with all mpl backends.
>
> hth,
>
> f

Hello,

I needed to use "stem" for complex impulse vectors and found that it
was too much work to make it behave.  I therefore wrote "cstem" which
is intended for complex impulse vectors.  It takes x (optional) and z
vectors, and a small number of special keyword parameters -- remaining
keywords are handed off to "plot" during plotting.

I've tried making it as similar to "stem" as I found useful, but it is
not a drop-in replacement.  It is written as a function, not an axis
method, but if found useful to others, changing it over should not be
difficult.

The code has ReST docstring including example of use:


    >>> z = np.random.uniform(size=10) + 1j*np.random.uniform(size=10)
    >>> cstem(z)

    or, using explicit x axis and keeping handles

    >>> x = np.r_[1:3:10j]
    >>> r_mark, i_mark, r_line, i_line, baseline = cstem(x, z)

License: anything BSD-ish that is broadly used in matplotlib already.

Enjoy!  Comments/suggestions welcome.
-- 
Tom Grydeland
  <Tom.Grydeland@(gmail.com)>

I push the new example in r8740.
Thanks.

-JJ


On Sat, Oct 9, 2010 at 12:15 AM, Stan West <sta...@nr...> wrote:
> Greetings. I initially encountered some difficulty following the
> multiple_yaxis_with_spines example, especially regarding what the functions
> make_patch_spines_invisible and make_spine_invisible were doing to the par2
> axes and why. For example, make_spine_invisible is really making one of the
> spines visible. I'd like to offer the attached modifications, which mainly
> simplify the manipulations and add explanatory comments. Minor changes
> include removing access to a global variable in make_patch_spines_invisible
> and removing a duplicated set_xlabel. The generated figure is unchanged.
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Sun, Oct 10, 2010 at 12:49 PM, Friedrich Romstedt
<fri...@gm...> wrote:
>
> Second, I would be very interested in more information about the
> ipython -pylab threading.  What do you mean with "running all user
> code in a single separate thread"?  When it's not the thread importing
> Tkinter, the problem persists.
>

Two things to note:

- ipython, even in the 0.10 series, uses threads for the Qt, Gtk and
Wx backends, but *not* for Tk, because python automatically pumps the
Tk event loop when the console blocks on reading (via the C API
PyOSInputHook call).  So there is exactly *zero* threading added by
ipython in the specific case of a Tk backend.

- in the 0.11 ipython series, we abandoned threading altogether (it's
just too brittle) and moved to a model similar to the Tk one for *all*
backends, we now use PyOSInputHook with all mpl backends.

hth,

f

On 10/10/2010 09:49 AM, Friedrich Romstedt wrote:
> 2010/10/2 Eric Firing<ef...@ha...>:
>> On 10/01/2010 09:40 AM, Friedrich Romstedt wrote:
>>> There were several question on the user's list in the recent past
>>> reporting hangs and similar when using TkAgg backend&    interactive
>>> mode.
>>>
>>> It is known that Tkinter doesn't play well with threading, as long as
>>> one isn't done very carefully.
>>>
>>> It could be that matplotlib has implemented it in a way not safe for
>>> Tkinter.  This applies if there are Tkinter methods called from
>>> threads other than those which imported Tkinter.
>>>
>>> It results in unpredicatable behaviour with exactly the features
>>> reported: Hang-ups, blankening, partial hangup of part of the threads.
>>>
>>> Is a rewrite of the Tk interactive code necessary?
>>
>> I don't see any use of the threading module in backend_tkagg.py or
>> backend_bases.py.  Is that what you are referring to?
>>
>> Ipython -pylab does use threads (version 0.10), but is intended to avoid
>> problems by running all user code in a single separate thread.
>
> I just dived a bit into the matplotlib source code, and come up with
> partial answers:
>
> When interactive mode is on, the mainloop isn't running at all (see
> backend_bases.py:ShowBase).  This explains hang-ups when using
> interactive mode in a non-shell Python call.

No, I don't think it does.  Before going farther, I suggest that you 
provide specific test cases that fail with mpl from svn.  As far as I 
know, everything works--in or out of interactive mode, in or out of a 
script, in or out of ipython.  There may be problems with some other 
environments (idle?).

>
> Second, I would be very interested in more information about the
> ipython -pylab threading.  What do you mean with "running all user
> code in a single separate thread"?  When it's not the thread importing
> Tkinter, the problem persists.

It is the thread importing Tkinter (via the user code), and there is 
generally no problem.

>
> Tkinter is always cumbersome and needs lots of care ... (at least as
> soon as the program wants to do something useful :-)
>
> Also, I cannot see (with reasonable effort) how Threads play a role in
> matplotlib.  I see there is the Scheduler class in cbook.py, and in
> backends/backend_tkagg.py there is "a dict from func->  cbook.Scheduler
> threads", but I have no idea how this works.  A small hint in the
> correct direction would be appreciated!  I think it's just a lot
> faster although I'm borrowing your time for writing the answer ... I
> cannot find any reference to ``.sourced`` in any matplotlib code.
> Maybe it's simply dead?

That's the point--threading does not play any role in mpl by default. 
It looks like John thought about using cbook.Scheduler in backend_tkagg, 
but ended up not doing so.  Hence Scheduler (and its two subclasses, 
Timeout and Idle) is just a miscellaneous tool in cbook, available to 
users, but not used in any backend.  Yes, that "sourced" attribute is 
dead; I have now deleted the associated dead code from svn trunk.

Eric

>
> Friedrich

2010/10/2 Eric Firing <ef...@ha...>:
> On 10/01/2010 09:40 AM, Friedrich Romstedt wrote:
>> There were several question on the user's list in the recent past
>> reporting hangs and similar when using TkAgg backend&  interactive
>> mode.
>>
>> It is known that Tkinter doesn't play well with threading, as long as
>> one isn't done very carefully.
>>
>> It could be that matplotlib has implemented it in a way not safe for
>> Tkinter.  This applies if there are Tkinter methods called from
>> threads other than those which imported Tkinter.
>>
>> It results in unpredicatable behaviour with exactly the features
>> reported: Hang-ups, blankening, partial hangup of part of the threads.
>>
>> Is a rewrite of the Tk interactive code necessary?
>
> I don't see any use of the threading module in backend_tkagg.py or
> backend_bases.py.  Is that what you are referring to?
>
> Ipython -pylab does use threads (version 0.10), but is intended to avoid
> problems by running all user code in a single separate thread.

I just dived a bit into the matplotlib source code, and come up with
partial answers:

When interactive mode is on, the mainloop isn't running at all (see
backend_bases.py:ShowBase).  This explains hang-ups when using
interactive mode in a non-shell Python call.

Second, I would be very interested in more information about the
ipython -pylab threading.  What do you mean with "running all user
code in a single separate thread"?  When it's not the thread importing
Tkinter, the problem persists.

Tkinter is always cumbersome and needs lots of care ... (at least as
soon as the program wants to do something useful :-)

Also, I cannot see (with reasonable effort) how Threads play a role in
matplotlib.  I see there is the Scheduler class in cbook.py, and in
backends/backend_tkagg.py there is "a dict from func-> cbook.Scheduler
threads", but I have no idea how this works.  A small hint in the
correct direction would be appreciated!  I think it's just a lot
faster although I'm borrowing your time for writing the answer ... I
cannot find any reference to ``.sourced`` in any matplotlib code.
Maybe it's simply dead?

Friedrich

--- On Sun, 10/10/10, Eric Firing <ef...@ha...> wrote:
> Do you know anything about how Enthought packages their
> python and mpl for the Mac?  Would it be as a framework?

Sorry, no idea. I haven't used the Enthought packages.

> If you think there is something that really should be fixed
> for the Mac  to prevent future problems, and if it can be
> fixed without creating more problems, please do so.  Your
> suggestion above could be implemented in the svn trunk, at
> your discretion.  I'm not going to do it because I 
> don't understand it and can't test it.

I think it's possible, but I would like to hear from people who ran into this problem if Python not being a framework install is really the cause. It may also be that enthought packages an older version of matplotlib, which doesn't check for framework installs. If that is the case, then from a matplotlib perspective the problem has been fixed already.

--Michiel.


      

On 10/09/2010 06:43 PM, Michiel de Hoon wrote:
> The problem described in that bug report sounds similar to what happens if Python was not installed as a framework. The Mac OS X backend checks for that automatically, but the other backends do not as far as I know. If this is indeed the problem, we should consider checking this when importing matplotlib. I believe
>
>>>> import sysconfig
>>>> sysconfig.get_config_var("WITH_NEXT_FRAMEWORK")
>
> should do the job.
>
> --Michiel.

Michiel,

Thanks to you, Tony, and Matthew for your quick responses.  I am going 
to close the ticket.

Do you know anything about how Enthought packages their python and mpl 
for the Mac?  Would it be as a framework?

If you think there is something that really should be fixed for the Mac 
to prevent future problems, and if it can be fixed without creating more 
problems, please do so.  Your suggestion above could be implemented in 
the svn trunk, at your discretion.  I'm not going to do it because I 
don't understand it and can't test it.

Eric

>
>
>
> --- On Sat, 10/9/10, Eric Firing<ef...@ha...>  wrote:
>
>> From: Eric Firing<ef...@ha...>
>> Subject: [matplotlib-devel] SourceForge.net: matplotlib: Modify: 2973874 - Text box, Save dialog for mac
>> To: "matplotlib development list"<mat...@li...>
>> Date: Saturday, October 9, 2010, 10:30 PM
>> https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720
>>
>> Would someone with a Mac please look at this bug and say
>> whether it is
>> occurring with our release of mpl?  If not, I will
>> close the ticket.
>>
>> Thank you.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9
>> supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and
>> DOM L2&  L3.
>> Spend less time writing and  rewriting code and more
>> time creating great
>> experiences on the web. Be a part of the beta today.
>> http://p.sf.net/sfu/beautyoftheweb
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>

The problem described in that bug report sounds similar to what happens if Python was not installed as a framework. The Mac OS X backend checks for that automatically, but the other backends do not as far as I know. If this is indeed the problem, we should consider checking this when importing matplotlib. I believe 

>>> import sysconfig
>>> sysconfig.get_config_var("WITH_NEXT_FRAMEWORK")

should do the job.

--Michiel.



--- On Sat, 10/9/10, Eric Firing <ef...@ha...> wrote:

> From: Eric Firing <ef...@ha...>
> Subject: [matplotlib-devel] SourceForge.net: matplotlib: Modify: 2973874 - Text box, Save dialog for mac
> To: "matplotlib development list" <mat...@li...>
> Date: Saturday, October 9, 2010, 10:30 PM
> https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720
> 
> Would someone with a Mac please look at this bug and say
> whether it is 
> occurring with our release of mpl?  If not, I will
> close the ticket.
> 
> Thank you.
> 
> Eric
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9
> supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and
> DOM L2 & L3.
> Spend less time writing and  rewriting code and more
> time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 


      

On Oct 9, 2010, at 10:46 PM, Matthew Brett wrote:

> Hi,
> 
> On Sat, Oct 9, 2010 at 7:30 PM, Eric Firing <ef...@ha...> wrote:
>> https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720
>> 
>> Would someone with a Mac please look at this bug and say whether it is
>> occurring with our release of mpl?  If not, I will close the ticket.
> 
> Not for me (python.org 2.6 32 bit, mpl 1.0.0) with the macosx backend
> or the tkagg backend.  I don't have a 64 bit python / matplotlib to
> test with - maybe that's the trick?  Or maybe it was for a different
> backend?
> 
> Best,
> 
> Matthew

Works fine on my system: python 2.6 64 bit (system install), mpl svn r8726 with macosx, tkagg, and qt4agg.

Best,
-Tony

Hi,

On Sat, Oct 9, 2010 at 7:30 PM, Eric Firing <ef...@ha...> wrote:
> https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720
>
> Would someone with a Mac please look at this bug and say whether it is
> occurring with our release of mpl?  If not, I will close the ticket.

Not for me (python.org 2.6 32 bit, mpl 1.0.0) with the macosx backend
or the tkagg backend.  I don't have a 64 bit python / matplotlib to
test with - maybe that's the trick?  Or maybe it was for a different
backend?

Best,

Matthew

https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720

Would someone with a Mac please look at this bug and say whether it is 
occurring with our release of mpl?  If not, I will close the ticket.

Thank you.

Eric

On Thu, Oct 7, 2010 at 12:25 PM, braingram <bra...@gm...> wrote:

> Thanks for the tips on adding 3d subplots. I tested to see if the
> points bled over into the other subplots and they do not. When I was
> referring to the points not being clipped I was talking about the the
> points falling outside of the drawn 3d axes within the subplot, not
> falling outside of the subplot.
>
> I tested the subplot clipping out with the TkAgg and MacOSX backends
> (two subplots side-by-side) with the these results:
> 1. the 3d points in one subplot do not extend into the other subplot
> (the unseen points: [2,2], [3,3], [4,4] in the left subplot do not
> appear in the right subplot)
> 2. the 3d points in a single subplot can appear outside of the drawn
> 3d axes (as seen in the right subplot)
>
> The clipping error (2 above) within a given subplot is not related to
> the panning code (the attached plot was not panned) and occurs
> whenever the axis limits are changed from their autoscaled values
> (either by set_xlim etc, by zooming, or by panning).
>
>
Right, this concurs with my observations when I was fiddling around with
mplot3d code over the summer.  I am not exactly sure exactly where the fault
lies, but it is related to the Agg backend renderer either not being told
what should be clipped out, or is not understanding the information coming
from mplot3d to know what should be clipped.  This will happen in any sort
of situation that moves the plot from the original view.

Ben Root

Thanks for the tips on adding 3d subplots. I tested to see if the
points bled over into the other subplots and they do not. When I was
referring to the points not being clipped I was talking about the the
points falling outside of the drawn 3d axes within the subplot, not
falling outside of the subplot.

I tested the subplot clipping out with the TkAgg and MacOSX backends
(two subplots side-by-side) with the these results:
1. the 3d points in one subplot do not extend into the other subplot
(the unseen points: [2,2], [3,3], [4,4] in the left subplot do not
appear in the right subplot)
2. the 3d points in a single subplot can appear outside of the drawn
3d axes (as seen in the right subplot)

The clipping error (2 above) within a given subplot is not related to
the panning code (the attached plot was not panned) and occurs
whenever the axis limits are changed from their autoscaled values
(either by set_xlim etc, by zooming, or by panning).

On Thu, Oct 7, 2010 at 11:28 AM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Oct 7, 2010 at 10:19 AM, braingram <bra...@gm...> wrote:
>>
>> Thanks for catching that! I added the changes to mouse_init and
>> improved the panning so it works more consistently at different 'zoom'
>> levels and attached an updated patch.
>>
>> I tried to sort out the clipping issue you mentioned but failed to
>> wrap my head around how to clip the 3d data. It looks like (at least
>> in the svn trunk) there is no clipping of the 3d data (I tried
>> panning, zooming, and changing the axis limits and saw no clipping).
>> I'm also unsure how to make 3d subplots. I might just be too lost to
>> fix this one but if I make any progress I'll pass it along.
>>
>
> Ok, so you do see that the 3d image is not clipped when panning?  I believe
> this is an issue with the backend's interface with mplot3d's special axes,
> and it is certainly not trivial.  Until such issue is resolved, it is
> probably best to continue disabling the pan feature.
>
> By the way, subplotting 3d figures is a new feature made available in
> version 1.0.  It is very easy.  While you still have to use the same import
> command as before, you can now create a subplot axes of type 3d by doing:
>
> fig = plt.figure()
> ax = fig.add_subplot(1, 1, 1, projection='3d')
>
> As for the issue with the MacOSX backend, you might need to file a separate
> trouble ticket for that.
>
> Thank you for helping to improve matplotlib!
> Ben Root
>
>

On Thu, Oct 7, 2010 at 10:19 AM, braingram <bra...@gm...> wrote:

> Thanks for catching that! I added the changes to mouse_init and
> improved the panning so it works more consistently at different 'zoom'
> levels and attached an updated patch.
>
> I tried to sort out the clipping issue you mentioned but failed to
> wrap my head around how to clip the 3d data. It looks like (at least
> in the svn trunk) there is no clipping of the 3d data (I tried
> panning, zooming, and changing the axis limits and saw no clipping).
> I'm also unsure how to make 3d subplots. I might just be too lost to
> fix this one but if I make any progress I'll pass it along.
>
>
Ok, so you do see that the 3d image is not clipped when panning?  I believe
this is an issue with the backend's interface with mplot3d's special axes,
and it is certainly not trivial.  Until such issue is resolved, it is
probably best to continue disabling the pan feature.

By the way, subplotting 3d figures is a new feature made available in
version 1.0.  It is very easy.  While you still have to use the same import
command as before, you can now create a subplot axes of type 3d by doing:

fig = plt.figure()
ax = fig.add_subplot(1, 1, 1, projection='3d')

As for the issue with the MacOSX backend, you might need to file a separate
trouble ticket for that.

Thank you for helping to improve matplotlib!
Ben Root

doh! I hate to spam the mailing list, but I didn't respond to your
other question.

I tested this out on the MacOSX and TkAgg backends (the only ones I
have available on this  machine). The MacOSX backend suffered from the
bug I mentioned earlier (no 'motion_notify_event' for click+drag
middle mouse) but the TkAgg worked fine.

On Thu, Oct 7, 2010 at 11:19 AM, braingram <bra...@gm...> wrote:
> Thanks for catching that! I added the changes to mouse_init and
> improved the panning so it works more consistently at different 'zoom'
> levels and attached an updated patch.
>
> I tried to sort out the clipping issue you mentioned but failed to
> wrap my head around how to clip the 3d data. It looks like (at least
> in the svn trunk) there is no clipping of the 3d data (I tried
> panning, zooming, and changing the axis limits and saw no clipping).
> I'm also unsure how to make 3d subplots. I might just be too lost to
> fix this one but if I make any progress I'll pass it along.
>
> On Wed, Oct 6, 2010 at 4:57 PM, Benjamin Root <ben...@ou...> wrote:
>> On Wed, Oct 6, 2010 at 3:45 PM, braingram <bra...@gm...> wrote:
>>>
>>> I fiddled around with the mplot3d axes3d panning today with some
>>> useful results. I've never submitted a patch before so please let me
>>> know if I did so incorrectly.
>>>
>>> On a related note, I noticed that middle mouse click+drags were not
>>> triggering 'motion_notify_event' events with the mac osx backend.
>>> However, when I Option(Alt) left mouse click+dragged The events were
>>> being triggered. I'm not sure if this is a osx thing or something to
>>> do with how the backend is passing on the event.
>>>
>>
>> Thanks for this, but if I recall, the panning feature was disabled because
>> of problems with (not) clipping the image outside the viewing area (which is
>> noticeable when doing subplots).  Which backends have you tested this for?
>> Note, I haven't time to test patches to mplot3d for another 2 weeks.
>>
>> As an additional request, the mouse_init() function should have another
>> keyword argument added for pan_btn=2, and then use that to initialize
>> self._pan_btn in the function.  Then, instead of checking if the button
>> number is equal to 2, it should compare against self._pan_btn.
>>
>> Ben Root
>>
>>
>

Thanks for catching that! I added the changes to mouse_init and
improved the panning so it works more consistently at different 'zoom'
levels and attached an updated patch.

I tried to sort out the clipping issue you mentioned but failed to
wrap my head around how to clip the 3d data. It looks like (at least
in the svn trunk) there is no clipping of the 3d data (I tried
panning, zooming, and changing the axis limits and saw no clipping).
I'm also unsure how to make 3d subplots. I might just be too lost to
fix this one but if I make any progress I'll pass it along.

On Wed, Oct 6, 2010 at 4:57 PM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Oct 6, 2010 at 3:45 PM, braingram <bra...@gm...> wrote:
>>
>> I fiddled around with the mplot3d axes3d panning today with some
>> useful results. I've never submitted a patch before so please let me
>> know if I did so incorrectly.
>>
>> On a related note, I noticed that middle mouse click+drags were not
>> triggering 'motion_notify_event' events with the mac osx backend.
>> However, when I Option(Alt) left mouse click+dragged The events were
>> being triggered. I'm not sure if this is a osx thing or something to
>> do with how the backend is passing on the event.
>>
>
> Thanks for this, but if I recall, the panning feature was disabled because
> of problems with (not) clipping the image outside the viewing area (which is
> noticeable when doing subplots).  Which backends have you tested this for?
> Note, I haven't time to test patches to mplot3d for another 2 weeks.
>
> As an additional request, the mouse_init() function should have another
> keyword argument added for pan_btn=2, and then use that to initialize
> self._pan_btn in the function.  Then, instead of checking if the button
> number is equal to 2, it should compare against self._pan_btn.
>
> Ben Root
>
>

> From: Eric Firing [mailto:ef...@ha...] 
> Sent: Wednesday, October 06, 2010 20:53
> 
> I modified it slightly and applied to the maintenance branch.  It will 
> get merged into the trunk eventually.
> 
> Your patch as submitted was not respecting the previously-set value of 
> self._tight, hence my modification.

Thank you for the review and correction, Eric.  Your modification clarified
for me another behavior of the prior and new implementations: The argument
tight=True is retained for future autoscaling calls with tight=None, but
tight=False doesn't stick; future calls use the automatic children-based
logic.  Does the Axes._tight attribute need to have three legal values
(corresponding to tight, loose, and children-based) to yield the documented
behavior?

On Wed, Jul 28, 2010 at 3:27 PM, Sandro Tosi <mo...@de...> wrote:
>
> I don't want to put pressure on this but... was there any progress? :)
> It would be nice to have this somehow fixed or worked-around, so that
> I can upload to debian (experimental branch) and get some testing
> there. The fact doc generation requires downloading datafiles from web
> it's the only thing left that holds upload of mpl.

Bump from this side...  Dav Clark just pointed this out to me:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/607395

and lo and behold, unfortunately for the upcoming maverick, Ubuntu
didn't update to mpl 1.0:

http://packages.ubuntu.com/hu/maverick/python-matplotlib

If an enterprising user who is knowledgeable in the ways of Debian
could contribute a patch for these data downloading calls to be
modified/disabled, it would be a great help.

It would be a shame to see mpl stuck at 0.99 for a long time just due to this...

Here's to hoping :)

Cheers,

f

On Wed, Oct 6, 2010 at 3:45 PM, braingram <bra...@gm...> wrote:

> I fiddled around with the mplot3d axes3d panning today with some
> useful results. I've never submitted a patch before so please let me
> know if I did so incorrectly.
>
> On a related note, I noticed that middle mouse click+drags were not
> triggering 'motion_notify_event' events with the mac osx backend.
> However, when I Option(Alt) left mouse click+dragged The events were
> being triggered. I'm not sure if this is a osx thing or something to
> do with how the backend is passing on the event.
>
>
Thanks for this, but if I recall, the panning feature was disabled because
of problems with (not) clipping the image outside the viewing area (which is
noticeable when doing subplots).  Which backends have you tested this for?
Note, I haven't time to test patches to mplot3d for another 2 weeks.

As an additional request, the mouse_init() function should have another
keyword argument added for pan_btn=2, and then use that to initialize
self._pan_btn in the function.  Then, instead of checking if the button
number is equal to 2, it should compare against self._pan_btn.

Ben Root

Hello,

I apologize in advance if this is not an appropriate question for the list.

I have relatively small project that I am stuck on a few (probably
small) points. Is anyone here is interested in earning a modest
consultation fee to "hold my hand" through the rough patches?

If so, please e-mail me directly -- lounds { } gmail -- and I will
send you additional details.

Thank you,

Jeremy

I fiddled around with the mplot3d axes3d panning today with some
useful results. I've never submitted a patch before so please let me
know if I did so incorrectly.

On a related note, I noticed that middle mouse click+drags were not
triggering 'motion_notify_event' events with the mac osx backend.
However, when I Option(Alt) left mouse click+dragged The events were
being triggered. I'm not sure if this is a osx thing or something to
do with how the backend is passing on the event.