matplotlib-devel Mailing List for matplotlib

On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> I've been keeping more or less up on the .11 development ipython,
> under Ubuntu 9.10 (10.4 when I get around to it...).  For each of the
> backends I do the following in an interactive session that starts with
> no profile or -pylab or anything::
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('whateverbackend')
>
> from matplotlib.pyplot import scatter,show
> from numpy.random import randn
>
> %gui -a whateverguiname

Aha!

Please leave out the -a.  It is harmful, not helpful, for mpl.  This may 
mean we need to change mpl and/or ipython, or the documentation, to 
prevent problems with the -a option; but I think you will find that if 
you leave out that option, the behavior will be more consistent and the 
need for Ctrl-C will go away.  Without %gui, there will still be an 
inconsistency between wx and the others--but that's what the %gui magic 
is for, to make wx use PyOS_InputHook like the others.

Eric

>
> scatter(*randn(2,100))
> show()
>
> that "%gui" bit is the new trick in ipython .11 that you use to
> initiate the event loop, so that the --pylab flag is superfluous. I
> try it both with, and without that line.  Below are my results for the
> various backends:
>
> *wx:
> w/o %gui: nothing appears until show(),  show() correctly blocks until
> the window closes.
> w/ %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
>
> *qt4:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(),  show() does NOT block.
>
> *gtk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
> w/ %gui: identical behavior
>
> *tk:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
>
>
> So it seems the interactive case of using the %gui magic works in all
> cases for interactive mode, but show is still not consistent in
> ipython .11 ...
>
> On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing<ef...@ha...>  wrote:
>> All,
>>
>> John noticed that my changes to show() prior to 1.0 had broken a use
>> case with tkagg and ipython -pylab, so I fixed that yesterday in
>> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
>> refactoring to try to make show() behavior more understandable across
>> backends, and easier to modify if necessary.  Specifically, we need to
>> work with the ipython people to make sure the ipython 0.11 refactoring
>> of interactive support works as intended.  I haven't done any testing
>> with the development version of 0.11 yet.
>>
>> At present, all interactive backends start a blocking mainloop only if
>> ipython has not attached a _needmain flag to show(), and if mpl is not
>> in interactive mode.
>>
>> Under all script and ipython conditions, multiple calls to show in a
>> session or script are permitted.
>>
>> All interactive backends behave the same when run with ipython -pylab,
>> version 0.10: show is non-blocking, regardless of whether it is executed
>> on the command line (completely unnecessary) or is found in a script.
>>
>> Under raw ipython (no -pylab or other threading flags provided), with
>> mpl in non-interactive mode, all backends behave the same: show() is
>> needed and blocks, but may be called multiple times.  With mpl in
>> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
>> qt4agg behave the same as in -pylab mode, so there so no longer any real
>> need for the special threading modes; but wx* and qtagg do not behave in
>> a useful way, so they still need the special threading.
>>
>> All of the above is based on quick tests with my own system, ubuntu
>> 10.04.  I expect it will be the same for other supported systems, with
>> the exception that behavior in raw ipython mode, with mpl in interactive
>> mode, may not work with some earlier versions of gui toolkits--but I
>> suspect we will not actually encounter this for supported versions.
>>
>> I have not built or tested anything under Windows or OS X.  For the
>> latter, testing of the macosx backend is needed.  I expect cocoaagg to
>> behave differently than the others, but no differently than it did
>> before my changes.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> I've been keeping more or less up on the .11 development ipython,
> under Ubuntu 9.10 (10.4 when I get around to it...).  For each of the
> backends I do the following in an interactive session that starts with
> no profile or -pylab or anything::
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('whateverbackend')
>
> from matplotlib.pyplot import scatter,show
> from numpy.random import randn
>
> %gui -a whateverguiname
>
> scatter(*randn(2,100))
> show()
>
> that "%gui" bit is the new trick in ipython .11 that you use to
> initiate the event loop, so that the --pylab flag is superfluous. I
> try it both with, and without that line.  Below are my results for the
> various backends:
>
> *wx:
> w/o %gui: nothing appears until show(),  show() correctly blocks until
> the window closes.
> w/ %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
>
> *qt4:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(),  show() does NOT block.
>
> *gtk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
> w/ %gui: identical behavior
>
> *tk:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
>
>
> So it seems the interactive case of using the %gui magic works in all
> cases for interactive mode, but show is still not consistent in
> ipython .11 ...

Erik,

Thanks for the testing.  I was also starting to test with ipython 0.11 
yesterday, and had reached the opposite conclusion--but I was using a 
different procedure.  So I will track down the difference.  My results 
were quite different...

Please verify: were you using the latest mpl from svn?

Eric

>
> On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing<ef...@ha...>  wrote:
>> All,
>>
>> John noticed that my changes to show() prior to 1.0 had broken a use
>> case with tkagg and ipython -pylab, so I fixed that yesterday in
>> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
>> refactoring to try to make show() behavior more understandable across
>> backends, and easier to modify if necessary.  Specifically, we need to
>> work with the ipython people to make sure the ipython 0.11 refactoring
>> of interactive support works as intended.  I haven't done any testing
>> with the development version of 0.11 yet.
>>
>> At present, all interactive backends start a blocking mainloop only if
>> ipython has not attached a _needmain flag to show(), and if mpl is not
>> in interactive mode.
>>
>> Under all script and ipython conditions, multiple calls to show in a
>> session or script are permitted.
>>
>> All interactive backends behave the same when run with ipython -pylab,
>> version 0.10: show is non-blocking, regardless of whether it is executed
>> on the command line (completely unnecessary) or is found in a script.
>>
>> Under raw ipython (no -pylab or other threading flags provided), with
>> mpl in non-interactive mode, all backends behave the same: show() is
>> needed and blocks, but may be called multiple times.  With mpl in
>> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
>> qt4agg behave the same as in -pylab mode, so there so no longer any real
>> need for the special threading modes; but wx* and qtagg do not behave in
>> a useful way, so they still need the special threading.
>>
>> All of the above is based on quick tests with my own system, ubuntu
>> 10.04.  I expect it will be the same for other supported systems, with
>> the exception that behavior in raw ipython mode, with mpl in interactive
>> mode, may not work with some earlier versions of gui toolkits--but I
>> suspect we will not actually encounter this for supported versions.
>>
>> I have not built or tested anything under Windows or OS X.  For the
>> latter, testing of the macosx backend is needed.  I expect cocoaagg to
>> behave differently than the others, but no differently than it did
>> before my changes.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

On 07/19/2010 11:10 AM, Sandro Tosi wrote:
> Hello,
> you know this question might seems strange, but I'd like to avoid some
> examples to be built when creating documentation.
>
> Those examples are the one using mpl.cbook.get_sample_data() to
> retrieve data files from the remote svn. In Debian we are not allowed
> to prepare a package that downloads "stuff" from the web, so I have to
> avoid this.

Good policy!

>
> The fastest solution I see is to actually exclude them from the list
> of the examples to build (but still install them, for users to use),
> but I didn't understand how :)
>
> Another solution would be for you to ship those datafile into the
> released tarball, so that it's all consistent and then point the
> example to those files, but how? if you find this in some way
> unacceptable, I can also download those files separately and add them
> when preparing the Debian package, but I have to find a way to tell
> get_sample_data() to point to that location...
>
> ...and so I'm asking you: what would you feel to be the best solution?

I think we should include any necessary data, and also eliminate the 
downloading from the examples run by the standard backend_driver.  The 
caching doesn't seem to work right, and there are long timeouts.  This 
was a problem for me recently when I was out on a ship, working on mpl 
on a computer without a live internet connection.

It would be OK to retain some examples with live downloading, but they 
should not be required for doc generation or for basic testing of mpl.
They don't contribute anything essential to either.

Eric

>
> Thanks in advance for your help and suggestions,

Hello,
you know this question might seems strange, but I'd like to avoid some
examples to be built when creating documentation.

Those examples are the one using mpl.cbook.get_sample_data() to
retrieve data files from the remote svn. In Debian we are not allowed
to prepare a package that downloads "stuff" from the web, so I have to
avoid this.

The fastest solution I see is to actually exclude them from the list
of the examples to build (but still install them, for users to use),
but I didn't understand how :)

Another solution would be for you to ship those datafile into the
released tarball, so that it's all consistent and then point the
example to those files, but how? if you find this in some way
unacceptable, I can also download those files separately and add them
when preparing the Debian package, but I have to find a way to tell
get_sample_data() to point to that location...

...and so I'm asking you: what would you feel to be the best solution?

Thanks in advance for your help and suggestions,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...).  For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::

import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')

from matplotlib.pyplot import scatter,show
from numpy.random import randn

%gui -a whateverguiname

scatter(*randn(2,100))
show()

that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line.  Below are my results for the
various backends:

*wx:
w/o %gui: nothing appears until show(),  show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show()  blocks
until the window closes.

*qt4:
w/o %gui: the window appears on the call to scatter(), show()  blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(),  show() does NOT block.

*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior

*tk:
w/o %gui: the window appears on the call to scatter(), show()  blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.


So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...

On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing <ef...@ha...> wrote:
> All,
>
> John noticed that my changes to show() prior to 1.0 had broken a use
> case with tkagg and ipython -pylab, so I fixed that yesterday in
> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
> refactoring to try to make show() behavior more understandable across
> backends, and easier to modify if necessary.  Specifically, we need to
> work with the ipython people to make sure the ipython 0.11 refactoring
> of interactive support works as intended.  I haven't done any testing
> with the development version of 0.11 yet.
>
> At present, all interactive backends start a blocking mainloop only if
> ipython has not attached a _needmain flag to show(), and if mpl is not
> in interactive mode.
>
> Under all script and ipython conditions, multiple calls to show in a
> session or script are permitted.
>
> All interactive backends behave the same when run with ipython -pylab,
> version 0.10: show is non-blocking, regardless of whether it is executed
> on the command line (completely unnecessary) or is found in a script.
>
> Under raw ipython (no -pylab or other threading flags provided), with
> mpl in non-interactive mode, all backends behave the same: show() is
> needed and blocks, but may be called multiple times.  With mpl in
> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
> qt4agg behave the same as in -pylab mode, so there so no longer any real
> need for the special threading modes; but wx* and qtagg do not behave in
> a useful way, so they still need the special threading.
>
> All of the above is based on quick tests with my own system, ubuntu
> 10.04.  I expect it will be the same for other supported systems, with
> the exception that behavior in raw ipython mode, with mpl in interactive
> mode, may not work with some earlier versions of gui toolkits--but I
> suspect we will not actually encounter this for supported versions.
>
> I have not built or tested anything under Windows or OS X.  For the
> latter, testing of the macosx backend is needed.  I expect cocoaagg to
> behave differently than the others, but no differently than it did
> before my changes.
>
> Eric
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sun, Jul 18, 2010 at 6:16 PM, Benjamin Root <ben...@ou...> wrote:
> A few corrections.  First, I wrong, it is unusual.  The second axes that I
> noticed in a 2d case came from a colorbar being added.  Second, in the 3d
> case, it was the Axes3DSubplot object being added twice, not the regular
> object like I originally said.
>
> The cause of this is due to the Axes3D initializer adding itself to the
> figure object being passed in.  This initializer is called when
> add_subplot() is called, so add_subplot also adds the axes when it is
> finished making it.  For normal projections, the initializer does not add
> itself to the axes.
>
> Removing the add_axes in the Axes3D initializer would "solve" the issue
> outright, however, there are plenty of legacy code where Axes3D is called
> with a figure passed in in order to create the axes, and this would break
> that use pattern.

I think the fact that add_axes will just blindly add a duplicate axes
is a bug. So why not have add_axes do something like the following:

if ax not in axes_list:
  axes_list.append(ax)
  <more stuff>

Anyone see anything wrong with this approach?

Ryan

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

On Fri, Jul 16, 2010 at 10:21 AM, Ryan Wagner <Rya...@ro...> wrote:
> (Michael Droettboom)
>
>>> The display at the bottom that says "Cursor at: X, Y" is in pixels, not
>>> in
>
>>> data units. ?It would be great if this could display data units, though
>
>>> being general enough to support custom scales (eg. log) and projections
>>> (eg.
>
>>> polar) may be tricky without making a round-trip to the server.
>
>
>
> (Simon Ratcliffe)
>
>>As you mentioned, the trick is in giving the client some view on how
>
>>pixels should map to data values without fetching these for each mouse
>
>>movement. For simple cartesian plots this is probably pretty
>
>>straightforward. It is something we need to get working for our
>
>>internal use so it should get solved at some stage.
>
>
>
> I have accomplished this in one of my applications as follows:
>
>
>
> Axes =figure.get_axes()
>
> #The transform used in this axis is Composite Generic Transform, so get the
> two affine transformation matricies
>
> MatrixA  = axes[0].transData.inverted()._a.get_matrix()
>
> MatrixB  = axes[0].transData.inverted()._b.get_matrix()
[...]
> The simple affine transformation can be accomplished by leaving off the
> MatrixB part. Non affine will probably be similar to the above followed by a
> log or exponential operation.

The other option, which would be somewhat less accurate but would
avoid reimplementing every projection in javascript, would be to build
a mesh (e.g., a grid) over the client's viewport region, sample the
value of the projection at each point on the grid, send that to the
client, and then let the client do linear interpolation to estimate
points in between grid points.

-- Nathaniel

I noticed some odd behavior when trying to set ticks on 3d plots made
using mplot3d.Axes3D ... specifically, if you tries to access any of
the 3D axes and change the ticks, it would result in a plot all
squashed to one side (indicating some sort of projection problem).
After a bit of digging, I discovered the source of the problem:
axis.XAxis, the base of the 3D Axis class, calls set_view_interval,
which is not overridden in mplot3d.axis3d.Axis, causing the wrong
interval to get the range assigned when ticks were added.  So the
solution was to implement set_view_interval on the 3D Axis.  That fix
is attached as a diff against the current svn in mpl3d-ticks-fix.diff
.  Now setting ticks seems to work just fine, so I've included another
diff that additionally implements set_?ticks3d and get_?ticks3d
methods for Axes3D - that's attached as
mpl3d-ticks-fix-add-methods.diff .

-- 
Erik Tollerud