matplotlib-devel Mailing List for matplotlib

2010年12月31日 余亮罡 <nu...@16...>
> Dear all,
> I have a quesstion about change the width of the ylabel.You know the
> width of the ylabel is relaete to the x axi,how can i change the width of
> the ylabel not depend on the width of the x-axis?
> Thank you!
> George
>
>
>
>
Maybe I am not understanding. The height of the y-axis label text (which is
then rotated 90 degrees) is dependent upon the font size, and should already
be completely independent of the x-axis. Can you show some examples of what
you mean?
Ben Root

2010年12月31日 John Hunter <jd...@gm...>:
> I don't know what the situation is now, but the last version of OS X I
> installed was 10.4 and X11 was a separate installation from xcode, if I
> recall correctly. Are you sure it is on by default?
I'm not completely sure, but really quite sure. I don't think it's
coming from Xcode on 10.6. E.g. Inkscape runs on X11, and it ran from
the beginning. I don't think they'll distribute binaries depending on
an Xcode installation. To be sure, I'll soon have probably the
opportunity to reinstall some both 10.5 and 10.6 machines, so I can
have a look. And I heard before about the libpng libraries in
/usr/X11/lib/, and I just verified. Developer stuff goes to
/Developer/.
> I don't mind using system libs
>
>  * if we are sure they are there
>
>  * they are in a consistent location
>
> The reason we switched to static builds was there was so much variation in
> where these libs were coming from (macports, fink, system libs) and some of
> the versions were out of date, it was almost impossible to ship usable
> binaries.
I agree, and I personally would prefer static libs for binary
distribution, since we would be limited to the 10.5 libs, or, more
strictly, one could say that binaries should also run on 10.4. I
think it's mainly targeting people who want to build their mpl
themselves, let it be for bug tracking, but are frightened by the
dependencies atm.
> Russell will have to take the lead on this if he thinks it is a good idea,
> as he is the OSX build master.
I agree fully.
Friedrich

On Fri, Dec 31, 2010 at 10:00 AM, Friedrich Romstedt <
fri...@gm...> wrote:
> > I've been meaning to publish my installation instructions for
> > numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a
> > while, but that will have to wait for another day... I've tried to
> > trim down my installation procedure to the minimum steps that will
> > guarantee a working system without introducing extra libraries /
> > Pythons / etc, so there might be some interest in it.
>
>
> So we should team up in improving our docs :-)
>
We'd be happy to have a doc contribution to the installing page or to the
FAQ.
JDH

On Fri, Dec 31, 2010 at 9:54 AM, Friedrich Romstedt <
fri...@gm...> wrote:
> > Also, not everyone has X11 installed (or does everyone now?)
>
>
> One can opt X11 out at installation time IIRC. But it's a rare case I
> believe.
>
>
I don't know what the situation is now, but the last version of OS X I
installed was 10.4 and X11 was a separate installation from xcode, if I
recall correctly. Are you sure it is on by default?
I don't mind using system libs
 * if we are sure they are there
 * they are in a consistent location
The reason we switched to static builds was there was so much variation in
where these libs were coming from (macports, fink, system libs) and some of
the versions were out of date, it was almost impossible to ship usable
binaries.
Russell will have to take the lead on this if he thinks it is a good idea,
as he is the OSX build master.
JDH
**

2010年12月10日 Ludwig Schwardt <lud...@gm...>:
> For the record, I set the following environment variables in
> ~/.profile on Snow Leopard:
>
>  # These compiler flags ensure 32-bit + 64-bit code generation, as
> Snow Leopard produces 64-bit code by default
>  export MACOSX_DEPLOYMENT_TARGET=10.6
>  export CFLAGS="-arch i386 -arch x86_64 -isysroot
> /Developer/SDKs/MacOSX10.6.sdk"
>  export LDFLAGS="-arch i386 -arch x86_64
> -syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
>  export FFLAGS="-m32 -m64"
> CFLAGS=${CFLAGS}" -I/usr/X11/include -I/usr/X11/include/freetype2"
> LDFLAGS=${LDFLAGS}" -L/usr/X11/lib" python setupegg.py bdist_egg
Python normally chooses those -arch flags which were chosen for Python
at compile time.
It's not a good idea to set CFLAGS and LDFLAGS with distutils I
learned. They do not stack with the compilation time CFLAGS etc., but
completely override. Better adapt the pathes in setupext.py.
> I've been meaning to publish my installation instructions for
> numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a
> while, but that will have to wait for another day... I've tried to
> trim down my installation procedure to the minimum steps that will
> guarantee a working system without introducing extra libraries /
> Pythons / etc, so there might be some interest in it.
So we should team up in improving our docs :-)
Friedrich

2010年12月10日 Christopher Barker <Chr...@no...>:
> On 12/9/10 11:57 PM, Ludwig Schwardt wrote:
>> This patch reminded me to ask why the builtin libpng, zlib and
>> libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
>
> It may be because we still want to support OS-X 10.4 .
I was not aware of the presence of libfreetype so far. I'm +1 on
using the libraries shipped with OS X. It should be possible to
deliver an extra package which just installs these libs on 10.4 (in
/usr/local/). But, I don't know when and if I'll finally find the
"time" to look into it definitely.
Anyway, this all would apply only to persons who build from source on
OS X, right? The binaries still have to use static linkage, or am I
wrong?
> Also, not everyone has X11 installed (or does everyone now?)
One can opt X11 out at installation time IIRC. But it's a rare case I believe.
> I also notice that they are in: MacOSX10.4u.sdk (under X11) -- so maybe
> the static libs in there could be used.
This is a question to Russell it seems to me.
Friedrich

Dear all,
 I have a quesstion about change the width of the ylabel.You know the width of the ylabel is relaete to the x axi,how can i change the width of the ylabel not depend on the width of the x-axis?
 Thank you!
 George

Hi,
I need to generate svg (for web browser display) from latex using
mathtext. I see that mathtext.MathTextParser has a to_png method. Is
there a way of doing the equivalent of to_svg? I see there is an svg
Mathtext backend, but it is not clear what it produces.
Thanks!
Brian

The patch is applied to the maintenance branch (r8846) and the trunk (r8847).
-JJ
On Wed, Dec 22, 2010 at 11:49 PM, Stan West <sta...@nr...> wrote:
>> From: Jae-Joon Lee [mailto:lee...@gm...]
>> Sent: Monday, December 13, 2010 05:24
>>
>> Attached is a preliminary fix. So, please test it if you can.
>
> Thank you. Your fix seems to do the trick.
>
>> I personally think it is better to use "offset points" for these cases
>> which makes the internal logic much simpler.
>
> I can see that, and that's what I was using as a work-around.
>
>

> From: Jae-Joon Lee [mailto:lee...@gm...] 
> Sent: Monday, December 13, 2010 05:24
> 
> Attached is a preliminary fix. So, please test it if you can.
Thank you. Your fix seems to do the trick.
> I personally think it is better to use "offset points" for these cases
> which makes the internal logic much simpler.
I can see that, and that's what I was using as a work-around.

On Thu, Dec 16, 2010 at 11:13 AM, Benjamin Root <ben...@ou...> wrote:
> I have been working on a new feature for mplot3d. It is a bit of a hack
> but with this patch the offset information in a tick formatter can now be
> displayed. The offset text is located so that the offset texts for two
> jointed axis are not co-located, and is placed at the same distance away
> from the axis as the axis label. The text is aligned so that it should
> always be "tucked" underneath the axis as one rotates the plot. There are a
> few edge cases as one rotates where an offset text will "stick out", but
> they should be very infrequent.
>
> I have attached a patch to enable this feature and also an example script
> that showcases it.
>
> This is how it should look:
> http://dl.dropbox.com/u/7325604/mplot3d_offsettest.png
>
> Let me know what you think, and if all is good, I will add it to the
> development branch soon.
>
> Ben Root
>
Since there haven't been any objections, I will commit this to the
development branch today.
Ben Root

On Wed, Dec 15, 2010 at 4:47 PM, Justin Peel <jp...@gm...> wrote:
> I decided to revisit this briefly and found another pretty easy change
> that gives a fairly significant speed boost for a large number of
> points. Basically, I just used two list comprehensions instead of
> looping.
>
>
Justin,
I finally had a chance to test this out and it does seem to give a slight
speedup. It also does make for some cleaner code as well, which is always a
plus! I still think the main clog, though, is the double for-loops that the
code is contained in. I will probably take a closer look at it in January
to see if there is a different way to accomplish the same thing.
Ben Root

I built a binary installer for matplotlib trunk rev 8843 (because it 
leaks memory less than 1.0.0 release). I built it the same way I built 
the 1.0.0 binary 
<http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably 
6).
The binary is available here:
<http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
843-python.org-py2.6-macosx10.3.dmg>
It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import 
pylab almost always segfaults (and the few times I've gotten it to work 
on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and 
running Python again). I've tried it on newly created accounts and it 
segfaults. Another user of Snow Leopard first reported the problem. So 
it's not just me.
I've appended part of a crash log.
I built this binary the same way I built the matplotlib 1.0.0 binary, 
which has no problems.
Any ideas?
-- Russell
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
abort() called
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x90e1b176 __kill + 10
1 libSystem.B.dylib 0x90e1b168 kill$UNIX2003 + 32
2 libSystem.B.dylib 0x90ead89d raise + 26
3 libSystem.B.dylib 0x90ec39bc abort + 93
4 org.python.python 0x004e3e99 Py_FatalError + 73
5 libSystem.B.dylib 0x90e2046b _sigtramp + 43
6 ??? 0000000000 0 + 0
7 libSystem.B.dylib 0x90e29378 
_Unwind_GetLanguageSpecificData + 24
8 libstdc++.6.dylib 0x940c4d86 __gxx_personality_v0 + 120
9 libgcc_s.1.dylib 0x0389f476 _Unwind_Backtrace + 278
10 libgcc_s.1.dylib 0x0389f890 _Unwind_Resume + 112
11 ft2font.so 0x03d5c3a3 
FT2Font::FT2Font(std::string) + 4385
12 ft2font.so 0x03d5c805 
ft2font_module::new_ft2font(Py::Tuple const&) + 505
13 ft2font.so 0x03dc89c2 
Py::ExtensionModule<ft2font_module>::invoke_method_varargs(void*, 
Py::Tuple const&) + 90
14 ft2font.so 0x03d7170c 
method_varargs_call_handler + 342
15 org.python.python 0x004bcd25 PyEval_EvalFrameEx + 19429
16 org.python.python 0x004bee9d PyEval_EvalCodeEx + 2109
17 org.python.python 0x004bcf0c PyEval_EvalFrameEx + 19916

Hey all,
Can we please have a 1.0.1 release? It would be really nice to finally
have official 1.0 packages for ubuntu/debian.
Cheers,
- Ben

Hi,
As part of SciPy India project, I figured out an easy way to delete
multiple-lines in a subplot with help of John Hunter. On his advice i would
like to post as an FAQ.
The following is the URL where i have uploaded the .diff file.
https://gist.github.com/746422
I kindly request you to check it and let me know i need to make any changes.
Thanking You.
Regards,
Sandeep Reddy.

Hi,
As part of Scipy India sprint I wrote a code for Sierpinski's gasket. I
uploaded the file at the website http://gist.github.com. The URL of the
code is:
 https://gist.github.com/746409
Please let me know if i need to made any changes before this is accepted.
Thanks,
Atmakuri.venkata trinath

Hi Mike,
the patch resolved my problem. Thanks a lot!
Greetings,
Dieter

Can you try applying the attached patch and let me know if it resolves 
the problem for you?
Mike
On 12/17/2010 04:22 AM, Dieter Weber wrote:
> Hi Mike,
> sorry, I forgot my platform in my last mail!
>
> I am running Ubuntu 10.04.1 LTS x86_64
>
> Python: 2.6.5, Ubuntu
> matplotlib: svn trunk, revision 8841
>
> All other dependencies of matplotlib are installed as "normal" packages
> of the distribution. Versions can be found here:
> http://packages.ubuntu.com/lucid/python/
>
> Would you like more information or should I run more tests?
>
> Greetings,
> Dieter
>
> Am Donnerstag, den 16.12.2010, 15:40 -0500 schrieb Michael Droettboom:
>> What platform are you on? It "works for me" on Fedora 14, RHEL 5 and
>> Cygwin.
>>
>> Mike
>>
>> On 12/16/2010 10:59 AM, Dieter Weber wrote:
>>> #!/usr/bin/env python
>>> # -*- coding: utf-8 -*-
>>> import matplotlib
>>> import matplotlib.pyplot as pp
>>> import tempfile
>>> import cStringIO as StringIO
>>>
>>> matplotlib.rcParams['svg.embed_char_paths'] = False
>>>
>>> pp.plot([1, 2], [1, 2], label=u"äöü")
>>> pp.legend()
>>>
>>> # works
>>> pp.savefig('test.svg')
>>>
>>> # breaks
>>> with open('test2.svg', 'wb') as ofile:
>>> pp.savefig(ofile, format='svg')
>>>
>>> # breaks
>>> ostr = StringIO.StringIO()
>>> pp.savefig(ostr, format='svg')
>

Hi Mike,
sorry, I forgot my platform in my last mail!
I am running Ubuntu 10.04.1 LTS x86_64
Python: 2.6.5, Ubuntu
matplotlib: svn trunk, revision 8841
All other dependencies of matplotlib are installed as "normal" packages
of the distribution. Versions can be found here:
http://packages.ubuntu.com/lucid/python/
Would you like more information or should I run more tests?
Greetings,
Dieter
Am Donnerstag, den 16.12.2010, 15:40 -0500 schrieb Michael Droettboom:
> What platform are you on? It "works for me" on Fedora 14, RHEL 5 and 
> Cygwin.
> 
> Mike
> 
> On 12/16/2010 10:59 AM, Dieter Weber wrote:
> > #!/usr/bin/env python
> > # -*- coding: utf-8 -*-
> > import matplotlib
> > import matplotlib.pyplot as pp
> > import tempfile
> > import cStringIO as StringIO
> >
> > matplotlib.rcParams['svg.embed_char_paths'] = False
> >
> > pp.plot([1, 2], [1, 2], label=u"äöü")
> > pp.legend()
> >
> > # works
> > pp.savefig('test.svg')
> >
> > # breaks
> > with open('test2.svg', 'wb') as ofile:
> > pp.savefig(ofile, format='svg')
> >
> > # breaks
> > ostr = StringIO.StringIO()
> > pp.savefig(ostr, format='svg')
> 

What platform are you on? It "works for me" on Fedora 14, RHEL 5 and 
Cygwin.
Mike
On 12/16/2010 10:59 AM, Dieter Weber wrote:
> #!/usr/bin/env python
> # -*- coding: utf-8 -*-
> import matplotlib
> import matplotlib.pyplot as pp
> import tempfile
> import cStringIO as StringIO
>
> matplotlib.rcParams['svg.embed_char_paths'] = False
>
> pp.plot([1, 2], [1, 2], label=u"äöü")
> pp.legend()
>
> # works
> pp.savefig('test.svg')
>
> # breaks
> with open('test2.svg', 'wb') as ofile:
> pp.savefig(ofile, format='svg')
>
> # breaks
> ostr = StringIO.StringIO()
> pp.savefig(ostr, format='svg')

Hi Mike,
the error only occurs if the output file is specified as a file(-like)
object instead of a file name. This is necessary for me in order to add
a matplotlib-generated file to a tar archive via a safe temporary file.
Greetings,
Dieter

Unfortunately, this isn't a complete solution. The purpose of the "escape_xml_chars" function is to escape characters that have special meaning in XML, e.g. "&" -> "&amp;", "<" -> "&lt;" etc. The "xmlcharrefreplace" option on encode() does not do that.
I am surprised that you got this traceback, as the SVG is output using a UTF-8 EncodedFile object, which should be able to handle any unicode characters you throw at it. Can you provide a short, standalone example that reproduces the error, and some information about your platform, so I can examine further?
As for your suggestion to encode mathematical characters as unicode, unfortunately that would only partially. In order to layout the mathematical expressions, we must have the same font available at generation and rendering time to know the size of the characters and therefore how to place them next to each other correctly. That said, if you use the STIX fonts (set "mathtext.fontset" to "STIX"), those do use a Unicode-based encoding rather than the arbitrary one used by the Bakoma Computer Modern fonts. Of course, generating a math expression using the STIX fonts and rendering it using a different Unicode math font is not guaranteed to work well -- you are almost certain to get overlapping or misplaced glyphs.
Mike

Hi,
I tried to use matplotlib.rcParams['svg.embed_char_paths'] = False in
order to have editable text in exported SVG, but there was an encoding
issue and the file data could not be written (traceback appended).
Therefore I exchanged the XML character escaping from sax in
backend_svg.py with python's native XML escape capability (see appended
diff), and voilà it works!
The conversion of mathtext to SVG is still not so nice because specific
fonts (cmmi10, cmr10, cmsy10) are used that encode mathematic symbols
with other unrelated characters. The formula display will totally break
if these fonts aren't installed, and editing is a pain. It would
therefore be great if unicode characters were used so that the correct
display is not so much dependent on those specific fonts. Would this
introduce other problems and where would be the best point to make that
change?
Greetings,
Dieter

I decided to revisit this briefly and found another pretty easy change
that gives a fairly significant speed boost for a large number of
points. Basically, I just used two list comprehensions instead of
looping.
On Mon, Dec 13, 2010 at 8:10 AM, Benjamin Root <ben...@ou...> wrote:
> On Tue, Nov 30, 2010 at 4:53 PM, Benjamin Root <ben...@ou...> wrote:
>>
>> On Wednesday, November 17, 2010, Benjamin Root <ben...@ou...> wrote:
>> > On Tue, Nov 16, 2010 at 5:20 PM, J P <jp...@gm...> wrote:
>> >
>> >
>> > Hi all, here's my first patch for matplotlib. Someone noticed at Stack
>> > Overflow that the plot_surface function in mplot3d wasn't especially fast
>> > for a lot of points (and small rstrides/cstrides) and using shading and a
>> > single color. I found some parts of the code that weren't vectorized. These
>> > are my changes so far.
>> >
>> > Summary of changes:
>> > 1. Changed from double looping over aranges to using xrange
>> > 2. Made the normalization of the normals and their dot product with the
>> > vector [-1,-1,0.5] to find the shading a vectorized operation.
>> > 3. Changed a list comprehension which calculated the colors using an
>> > iterative approach to using the already built-in vectorization of the
>> > Normalization class and using the np.outer function. The result is a numpy
>> > array rather than a list which actually speeds up things down the line.
>> > 4. removed the corners array from plot_surface which wasn't ever used or
>> > returned. It didn't really slow things down, but I'm thinking that it is
>> > cruft.
>> >
>> > For change number two, I made a separate function that generates the
>> > shades, but feel free to move that around if you prefer.. or maybe it should
>> > be a function that begins with a _ because it shouldn't be used externally.
>> > These changes give varying levels of speed improvement depending on the
>> > number of points and the rstrides/cstrides arguments. With larger numbers of
>> > points and small rstrides/cstrides, these changes can more than halve the
>> > running time. I have found no difference in output after my changes.
>> >
>> > I know there is more work to be done within the plot_surface function
>> > and I'll submit more changes soon.
>> >
>> > Justin
>> >
>> >
>> > Justin,
>> >
>> > Thank you for your efforts to improve the performance of mplot3d. I
>> > will take a look at the patches you have submitted and test them out. What
>> > I am probably going to do is break down the patches into smaller pieces and
>> > incorporate them piece-by-piece.
>> >
>> > I tried refactoring plot_surface once before to mixed results. The key
>> > feature I was trying to gain was compatibility with masked arrays. I wanted
>> > to duplicate the behavior of contourf and pcolor where masked out portions
>> > of the surface would not be created. I managed to get it to work for that
>> > particular use-case, but I broke a bunch of other use-cases along the way.
>> > I am curious to see if your patches make this easier/harder to do.
>> >
>> > Thank you for your efforts and thank you for using matplotlib!
>> >
>> > Ben Root
>> >
>> >
>>
>> I have looked through the patches, and there are definite
>> improvements. I have broken the work into four separate patches. The
>> first patch is essentially code cleanup and utilization of xrange
>> (plot_surface_cleanup.patch). This patch can be back-ported without
>> concern (although it doesn't fix any bug per se).
>>
>> The second patch does the vectorization of the shades. The original
>> patch that was submitted had some edge cases, but I have found that
>> just simply converting that for-loop that creates the shades into a
>> list comprehension (and then pass into np.array) yielded almost
>> identical speedups without changing the current code path. (Note: I
>> am a minimalist when it comes to patches). This is in
>> plot_surface_vectshading.patch.
>>
>> The third patch improves the calculation of the normals in
>> plot_surface by pre-allocating the arrays for calculating the vectors
>> and doing a final call to np.cross rather than appending on a list. I
>> deviated slightly from the original patch by calling "which" as
>> "which_pt", adding a couple of comments, and also added an else
>> condition to create a "normal" with an empty list. This last part is
>> to keep the code path as similar as it was before. It was
>> theoretically possible to utilize a variable called normal elsewhere
>> without all the same conditions holding, so this guarantees that
>> normal exists, which was the case before. This patch is
>> plot_surface_vectnorm.patch.
>>
>> Finally, the fourth patch utilizes numpy array functionality for
>> calculating the vertexes. This patch also forgoes the use of
>> transposed arrays. I took the original patch a step further and
>> eliminated the array transpose line earlier in the plot_surface
>> function. The array transpose was not being properly utilized here,
>> and I saw no speed penalty/speedup either way, so in favor of simpler
>> code, I eliminated its use. This patch is
>> plot_surface_vectvertex.patch.
>>
>> Of the four patches, the speedups are in mostly found in the second
>> patch (100% speedup). The first patch does provide noticeable
>> improvements. There is also a slight improvement with the third
>> patch. I am up in the air regarding speed improvements with the
>> fourth patch, but I wonder if there might be some memory improvements
>> here, or if any speedup is being hidden by the for-loop that the
>> vectorization is done in.
>>
>> I will let these patches be mulled over before applying them. Thanks
>> to JP for submitting the original patch.
>>
>> Ben Root
>
>
> Re-pinging, as I haven't heard any opinions on this. The key question is
> should any of these patch be put into the maintenance branch or should it
> only be in the development branch?
>
> Thanks,
> Ben Root
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I am on RHEL5 with QT 4.2.1 installed. I am stuck with that version of QT
and can't go up.
I have PyQt 4.4.4 with SIP 4.7.8. That seems to be one of the few
combinations that would build with this version of QT. It took forever for
me to find sources for the other versions. 
I tried installing matplotlib 1.0 and 0.99 but if I set the backend to
Qt4Agg, I get an error when I try "show()": 'ImportError: Warning:
formlayout requires PyQt4 >v4.3'
Can anyone help with this?
--
Enrico Ng