matplotlib-devel Mailing List for matplotlib

etc for producing images at various scales)
Reply-To: 
In-Reply-To: <20110121232036.GA26739@ykcyc>
X-PGP-Key: http://pirsquared.org/PaulIvanov0F3E28F7.asc
Paul Ivanov, on 2011年01月21日 15:20, wrote:
> I'm almost certain that one *can* write a function to do this
> pro grammatically (without having to hand tweak anything), by
> looking at say, the .get_window_extent() but I haven't found the
> time to scratch that itch, yet.
> 
> If someone wants to beat me to it, here's the sort of thing that
> you can do:
> 
> def show_labels_by_shrinking(ax):
> " adjust subplot parameters to fit the yaxis label"
> f = ax.figure
> textwidth = ax.yaxis.get_label().get_window_extent().width
> labelwidth = max([lab.get_window_extent().width for lab in ax.get_yticklabels()])
> plt.subplots_adjust(left=(textwidth+labelwidth+3*ax.yaxis.labelpad)/f.get_window_extent().width)
> # the 3 *ax.yaxis.labelpad is just a fudge factor for now, need
> # to look into the sourcecode to figure out what the
> # appropriate placement is normally, to know how to adjust
> # properly
> 
> 
> ax.set_ylabel('foo')
> show_labels_by_shrinking(ax)
> ax.set_ylabel("a\nmulti\nline\nexample")
> show_labels_by_shrinking(ax)
I should add that along with doing a similar thing for the xaxis,
this would need to be extended for the multiple subplot case, to
also adjust the wspace and hspace parameters accordingly. 
this is important functionality currently missing from matplotlib
out-of-the-box at the moment, so I'll try my crack at it this out
this weekend. 
CCing the devel list in case someone has more opinions.
best, 
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

2011年1月17日 Eoghan Harrington <eo...@gm...>
> Hi,
>
> I noticed some erroneous behaviour when using a
> LinearSegmentedColormap with an "under" color and different numbers of
> color levels. The attached script replicates the behaviour, whereby
> lowering the number of colors causes less of the values to be
> considered "under" the vmin. I tracked the problem back to the
> Colormap class where the results of Normalize are multiplied by the
> number of color levels (N) and casted as an int to be used as indices
> in the color array. The expected behaviour would be that all negative
> values should be considered "under", however the results of the cast
> means that anything between 0 and -0.5 will be set to 0 and therefore
> will be in the normal color range for the colormap. The attached patch
> overcomes this by setting all negative values to -1 before applying
> the cast.
>
> Thanks for your help,
> Eoghan
>
>
Thanks for catching this one. Blindly casting to int is wrong (which has a
problem for values between -1 and 0, not just -0.5 and 0). This has been
committed in v1_0_maint as r8931 and in the development trunk as r8932.
Ben Root

On Sat, Jan 8, 2011 at 6:36 PM, Benjamin Root <ben...@ou...> wrote:
> I just tried running a test in matplotlib and I got the following error:
>
> ======================================================================
> ERROR: Failure: IOError ([Errno 2] No such file or directory:
> '/home/ben/Programs/matplotlib/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png')
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.6/nose/loader.py", line 224, in generate
> for test in g():
> File
> "/home/ben/Programs/matplotlib/matplotlib/lib/matplotlib/testing/decorators.py",
> line 91, in compare_images_generator
> shutil.copyfile(src,dst)
> File "/usr/lib/python2.6/shutil.py", line 50, in copyfile
> with open(src, 'rb') as fsrc:
> IOError: [Errno 2] No such file or directory:
> '/home/ben/Programs/matplotlib/matplotlib/lib/matplotlib/tests/baseline_images/test_axes/canonical.png'
>
> Anybody know anything about this particular test?
>
> Ben Root
>
Re-pinging this question....
Ben Root

-- In the process of clearing out patch backlog --
This patch has been committed to the trunk in r8930. I am not going to
commit this to 1.0.x unless I am absolutely certain that this patch doesn't
break any other use-cases.
Ben Root
On Fri, Jan 7, 2011 at 9:28 PM, Benjamin Root <ben...@ou...> wrote:
> Hello,
>
> I have been noticing odd behaviors when plotting polygons and surfaces
> using mplot3d. Some polygon faces were being slightly transparent, for
> example when you rotate the sphere in the 'surface3d_demo2.py' example.
> Some faces were completely missing, for example in the 'hist3d_demo.py'
> example. In the surface3d_demo3.py example, I wasn't fully happy with the
> appearance of the plot and I was fairly sure it wasn't 100% correct.
>
> I believe I have the problem tracked down to the "_shade_colors()" method
> in axes3d.py. I have a patch and it needs to be applied to both the
> development branch and one for the release candidate. However, I am almost
> certain that it could break some others 3d display code and I would like
> people to check it out first before it gets applied.
>
> The 'mplot3d_vectshade.patch' can be used against the current development
> branch, while 'mplot3d_vectshade_rc2.patch' can be used against the latest
> in the maintenance branch.
>
> Thanks, and I would greatly appreciate your input!
> Ben Root
>
>
>

Binaries:
Build with static libs from most recent source distribution. Since we
want a click-and-working installer, it's not effordable to request
installing X11 (10.4) or similar.
Home Builds:
Libraries:
1) From X11. Seems to be the most simple way.
2) From most recent source distribution. Where to install? Maybe:
Static linkage against libraries built and installed in the mpl build
dir. This would avoid overwriting the user's system-wide libraries.
It would also have the advantage to support non-root builds.
3) From binary distribution package including just those libraries.
This seems not a bright idea.
4) From separately user-compiled and system wide installed source
distributions of the libraries.
X11:
10.3.9: ??
10.4: Looks like that X11 has to be opted in. (John)
10.5: Unknown
10.6: X11 very much probably included (opt-out at OS install point).
Installed in /usr/X11/lib/. (Friedrich)
=> A build system should detect the native OS X libraries (way (1)).
If they are not present, it's up to the user to decide what to do, if
to go route (2), (3), or (4). Build system could use Paver (as numpy
does).
Friedrich

Hi,
I feel your pain on the issue of eggs...
> - Is there some way to name the eggs to disambiguate between 32-bit
> Python 2.7 (which works on all versions of Mac OS X) and 64-bit Python
> 2.7 (which only works on 10.6) that is compatible with easy_install?
> In the past if the eggs had strange names easy_install misbehaved.
When I built the readline package on the Mac, I ran into similar
issues. To keep things simple (or so I thought), I built one universal
egg. On Leopard with Apple Python 2.5 (see
http://pypi.python.org/pypi/readline/2.5.1) and the setuptools at the
time (May 2008), the egg was named *-fat.egg. Since there is no
architecture called "fat", easy_install refused to select it for
installation. So I renamed it to the explicit architectures
(*-i386.egg, *-ppc.egg, *-ppc64.egg, *-x86_64.egg), but this was
another saga, since PyPI refused to upload identical files with
different names. I then tweaked each egg slightly to bypass this...
Very silly, as you can see.
The latest version of the readline package
(http://pypi.python.org/pypi/readline) has an egg for Leopard and Snow
Leopard built against the default Apple Python on each system. On Snow
Leopard and Python 2.6, the egg is now called *-universal.egg and
seems to work with the latest easy_install. To avoid repeating the
silly tweaking of eggs, I renamed the Leopard *-fat.egg to *-i386.egg
only, as that is pretty much the dominant architecture which will keep
most easy_install users happy (70% of the downloads of the 2.5.1
Leopard version with four eggs picked the i386 egg).
To get back to your question, I would venture something like
matplotlib-1.0.1-py2.7-macosx-10.3-i386.egg and
matplotlib-1.0.1-py2.7-macosx-10.6-x86_64.egg (ditto for the ppc
architectures).
Regards,
Ludwig
P.S.
> So my recommendation is not to Python 2.5 on a Mac.
I have been running matplotlib on Apple Python 2.5 on Leopard mostly
with the TkAgg backend (on Apple Tk) for a few years now - maybe it's
time to upgrade ;-)