Re: [matplotlib-devel] mplot3d broken?

[Eric Firing]

On 07/24/2010 04:01 PM, Benjamin Root wrote:
> On Sat, Jul 24, 2010 at 5:08 PM, Eric Firing  > wrote:
>
> While running backend_driver.py on the maintenance branch, I found that
> the mplot3d examples were not working.  Here is an example:
>
> efir...@manini:~/programs/py/mpl/mpl_v1_0_maint/examples/mplot3d$ python
> wire3d_demo.py
> Traceback (most recent call last):
>File "wire3d_demo.py", line 6, in 
>  ax = fig.add_subplot(111, projection='3d')
>File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
> line 675, in add_subplot
>  projection_class = get_projection_class(projection)
>File
> 
> "/usr/local/lib/python2.6/dist-packages/matplotlib/projections/__init__.py",
> line 61, in get_projection_class
>  raise ValueError("Unknown projection '%s'" % projection)
> ValueError: Unknown projection '3d'
>
> Eric
>
>
> Double-check your axes3d.py file.  The Axes3D class should have a member
> variable called "name" at the very beginning of it, and the very end of
> the axes3d.py file should have two lines of code that registers the
> axes3d object with the projection system.

Bitten by distutils again.  Attempting to get a complete clean rebuild, 
I was deleting dist-packages/matplot*, but not 
dist-packages/mpl_toolkits/.  Of course, doing that blows away basemap, 
which is not really what I want.

It would be simpler if everything installed by matplotlib's setup.py, 
and nothing else, would land in a single tree (package).  Having several 
things land in mpl_toolkits, and having other things also land there, is 
a pain.  Maybe we are stuck with it.  Or maybe things like basemap 
should be packages in their own right, parallel to matplotlib, instead 
of being inside mpl_toolkits.

Eric

>
> Ben Root


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in 'weights' in axes.hist

[Benjamin Root]

On Tue, Jul 20, 2010 at 9:21 AM, Jeff Klukas  wrote:

> Hello,
>
> The documentation for hist seems to indicate that you should be able
> to send a list of values through the 'weights' parameter in axes.hist,
> and this worked in previous versions.  In 1.0, however, this produces
> an error.  I've attached a diff (also pasted below) that I believe
> produces the expected behavior.
>
> It can be tested with:
> plt.hist([1,2,3], weights=[1,2,3])
>
> The above fails in the development version, but works with the diff.
> Could someone add this fix?
>
> Thanks,
> Jeff
>
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
> || http://klukas.web.cern.ch/
>
>
> Index: lib/matplotlib/axes.py
> ===
> --- lib/matplotlib/axes.py  (revision 8565)
> +++ lib/matplotlib/axes.py  (working copy)
> @@ -7587,7 +7587,12 @@
> else:
> raise ValueError("weights must be 1D or 2D")
> else:
> -w = [np.array(wi) for wi in weights]
> +try:
> +weights[0][0]
> +except TypeError:
> +w = [np.array(weights)]
> +else:
> +w = [np.array(wi) for wi in weights]
>
> if len(w) != nx:
> raise ValueError('weights should have the same shape as x')
>
>
Good catch, Jeff.  Looking over the code, looks like both the input data, x,
and the weights get similar pre-processing done to ready it for
histogramming. It appears that a fix was made to how x was being processed,
but the same was not done to weights.  I have a patch that fixes the
pre-processing of weights, and also  adds comments to both blocks of code to
remind future developers to make sure changes are made to both chunks of
code.

The functional part of the change was to check if the first element of
weights was an iterable or not.  Before, the weights array as in the given
example would be considered 1-element weights for 3 datasets, rather than
3-element weights for 1 dataset.

Ben Root
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py	(revision 8574)
+++ lib/matplotlib/axes.py	(working copy)
@@ -7551,6 +7551,8 @@
 'hist now uses the rwidth to give relative width '
 'and not absolute width')
 
+# Massage 'x' for processing.
+# NOTE: Be sure any changes here is also done below to 'weights'
 if isinstance(x, np.ndarray) or not iterable(x[0]):
 # TODO: support masked arrays;
 x = np.asarray(x)
@@ -7577,8 +7579,9 @@
 if len(color) != nx:
 raise ValueError("color kwarg must have one color per dataset")
 
+# We need to do to 'weights' what was done to 'x'
 if weights is not None:
-if isinstance(weights, np.ndarray):
+if isinstance(weights, np.ndarray) or not iterable(weights[0]) :
 w = np.array(weights)
 if w.ndim == 2:
 w = w.T
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] mpl, ipython, and gui interaction

[Eric Firing]

Please refer to the messages under "Detecting GUI mainloop running in 
IPython" on http://news.gmane.org/gmane.comp.python.ipython.devel.

At least at the moment, they are not showing up as a single thread; 
maybe it takes a little time for the thread logic to sort out the messages.

I hope that someone with better understanding than mine of gui mechanics 
will join the discussion on the ipython-dev list.  The IPython people 
have been making changes, and have more in mind.  This involves critical 
mpl functionality.

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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel