matplotlib-devel Mailing List for matplotlib (Page 5)

Michael Droettboom wrote:
> John Hunter wrote:
>   
>> On Fri, Jun 20, 2008 at 8:13 AM, Michael Droettboom <md...@st...> wrote:  
>>     
>>   Also, the start and end of the arrow locations is
>> pretty unsatisfying.  You would think they could hit the box edges...
>>   
>>     
> Yes.  That is surprising.  Even for arrows that are straight and axis 
> aligned it doesn't seem to always work.  PDF output isn't any better, 
> suggesting it's not just a low-level rendering issue.
>   
Google found me dot2tex:

http://www.fauskes.net/code/dot2tex/documentation/

which seems to produce much nicer arrow head alignment, since it uses 
PGF/TikZ for that.  I don't think it's a viable alternative, however, 
given the number of moving parts.

If you're a graph layout geek, though, you might appreciate some of the 
examples in the docs.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I was reading through custom_projection_example.py  and I noticed that  
the cla() method was defined twice (with the exact same code) for the  
same class. Here's a patch with one of the cla() methods (the one with  
fewer comments) deleted.

Thanks.  Obviously just an editing error.  Fixed in r5617.

Cheers,
Mike

Tony S Yu wrote:
> I was reading through custom_projection_example.py  and I noticed that 
> the cla() method was defined twice (with the exact same code) for the 
> same class. Here's a patch with one of the cla() methods (the one with 
> fewer comments) deleted.
>
>
>
>
> -Tony
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Jun 20, 2008 at 10:20 AM, Charlie Moad <cw...@gm...> wrote:
> Can we shoot for Sunday night?  It would be much more convenient for me at
> least.

Absolutely.  I suggested Monday because I thought it would be better,
but Sunday works fine too.  I'll do a round of testing Sunday morning.

JDH

Can we shoot for Sunday night?  It would be much more convenient for me at
least.

- Charlie

On Fri, Jun 20, 2008 at 10:20 AM, John Hunter <jd...@gm...> wrote:

> Sandro has been working hard packaging matplotlib 0.98.0 for debian
> ahead of the next major debian feature freeze, and says he can get
> 0.98.1 in if we release it by June 24th.  Charlie, can you do a
> release on Monday?  All developers, please take some time to fix any
> bugs you are aware of and let's release 0.91.4 and 0.98.1 on Monday
> pending Charlie's availability.  These major debian releases only
> happen once every couple of years so we want to get good versions in.
>
> JDH
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I was reading through custom_projection_example.py  and I noticed that  
the cla() method was defined twice (with the exact same code) for the  
same class. Here's a patch with one of the cla() methods (the one with  
fewer comments) deleted.

John Hunter wrote:
> On Fri, Jun 20, 2008 at 8:13 AM, Michael Droettboom <md...@st...> wrote:
>
>   
>> The current version of graphviz uses either cairo or gd (the default being
>> cairo on most modern installations.)
>>     
>
>   
>> Now that you've uploaded the docs, I see that the font you're getting isn't
>> as nice as mine.  I was setting "fontname" to "sans", which is supposed to
>> get the default sans serif font on the system.  It appears, from testing,
>> one can provide a list of fonts to dot, so I'll change it to try good fonts
>> first, with sans as the last resort fallback.
>>     
>
> I'm building and uploading the docs in a nightly cron on a linux box
> that Fernando maintains.  Can you tell him what package(s) need to be
> installed to insure cairo rendering so he can update the box?
My understanding is that gd doesn't support antialiasing at all, so if 
you're seeing antialiasing you're using Cairo.  To be absolutely certain 
you're using Cairo, you can change the "-Tpng" to "-Tpng:cairo" (though 
I don't know if we should do that in general, since it will break for 
users who don't have Cairo, if such users exist...). 

With my latest updates, you should ensure that there is a decent-looking 
font, such as Vera Sans, on the fontconfig path.  You should also make 
sure that libpango is being used by your graphviz.  It's optional in 
graphviz, but is used by the pre-built packages on Debian Etch and 
Ubuntu Hardy at least.

>   The
> anti-aliasing on some of the arrows looks pretty poor -- eg the arrow
> from matplotlib.text.Text -> matplotlib.text.Annotation at
> http://matplotlib.sourceforge.net/doc/html/api/artist_api.html.  Is it
> better on your box?
No.  Not any better.
>   Also, the start and end of the arrow locations is
> pretty unsatisfying.  You would think they could hit the box edges...
>   
Yes.  That is surprising.  Even for arrows that are straight and axis 
aligned it doesn't seem to always work.  PDF output isn't any better, 
suggesting it's not just a low-level rendering issue.
> Is there a way to inform dot/graphiz to not exceed a certain width?
> If so, I think we should set it so the images are not wider than some
> reasonable browser window for the html.
>   
Yes.  You can change the "size" graph option which is given in inches 
(with a default dpi for png of 96).  I've set this to 8, which should 
work for resolutions of 1024x768, accounting for the left margin of the 
webpage.  Note that if the size exceeds this, the layout doesn't change, 
it is just scaled down.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Jun 20, 2008 at 8:13 AM, Michael Droettboom <md...@st...> wrote:

> Now that you've uploaded the docs, I see that the font you're getting isn't
> as nice as mine.  I was setting "fontname" to "sans", which is supposed to
> get the default sans serif font on the system.  It appears, from testing,
> one can provide a list of fonts to dot, so I'll change it to try good fonts
> first, with sans as the last resort fallback.

Hey, these things are proving useful already.  I was looking at the
inheritance graph at
http://matplotlib.sourceforge.net/doc/html/api/collections_api.html
and noticed a redundant ScalarMappable inheritance in the
LineCollection.  (fixed in svn)

Sandro has been working hard packaging matplotlib 0.98.0 for debian
ahead of the next major debian feature freeze, and says he can get
0.98.1 in if we release it by June 24th.  Charlie, can you do a
release on Monday?  All developers, please take some time to fix any
bugs you are aware of and let's release 0.91.4 and 0.98.1 on Monday
pending Charlie's availability.  These major debian releases only
happen once every couple of years so we want to get good versions in.

JDH

On Thu, Jun 19, 2008 at 11:52 AM, Olle Engdegård <ol...@fy...> wrote:
>
> Here is a patch to add linestyles to patches.py. I have tried it with
> unfilled step histograms (important for b/w print and colour blind people).
>
> What do you think?

I'm happy to include this, but we need to make sure it is supported in
PS, PDF, SVG and Agg.  Can you check these backends to make sure they
are respecting the new parameter?

Thanks,
JDH

On Fri, Jun 20, 2008 at 8:13 AM, Michael Droettboom <md...@st...> wrote:

> The current version of graphviz uses either cairo or gd (the default being
> cairo on most modern installations.)

> Now that you've uploaded the docs, I see that the font you're getting isn't
> as nice as mine.  I was setting "fontname" to "sans", which is supposed to
> get the default sans serif font on the system.  It appears, from testing,
> one can provide a list of fonts to dot, so I'll change it to try good fonts
> first, with sans as the last resort fallback.

I'm building and uploading the docs in a nightly cron on a linux box
that Fernando maintains.  Can you tell him what package(s) need to be
installed to insure cairo rendering so he can update the box?  The
anti-aliasing on some of the arrows looks pretty poor -- eg the arrow
from matplotlib.text.Text -> matplotlib.text.Annotation at
http://matplotlib.sourceforge.net/doc/html/api/artist_api.html.  Is it
better on your box?  Also, the start and end of the arrow locations is
pretty unsatisfying.  You would think they could hit the box edges...

Is there a way to inform dot/graphiz to not exceed a certain width?
If so, I think we should set it so the images are not wider than some
reasonable browser window for the html.

JDH

Have you updated Sphinx from SVN lately?  I have r64374.

Sphinx should have dumped a full traceback into a tmp file (and told you 
where it is, which I don't see in your log output).  Can you send that?

Cheers,
Mike

Charlie Moad wrote:
> Python2.5 on OSX.5
>
> On Thu, Jun 19, 2008 at 11:14 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     What version of Python are you running?  All I can think from
>     looking at the code is that something in the regex is behaving
>     differently for you than me (on Python 2.5).
>
>     If you just want the docs to build (minus the inheritance
>     diagrams), you can put a "return []" at the top of
>     "inheritance_diagram_directive_run" in inheritance_diagram.py
>
>     Cheers,
>     Mike
>
>     Charles Moad wrote:
>
>         Just jumped into the new docs to take a look and immediately
>         having  problems building.  I am hoping someone can make a
>         quick fix so I  don't have to debug.
>
>         quaternion:doc cmoad$ ./make.py html
>         Sphinx v0.3, building html
>         trying to load pickled env... not found
>         building [html]: targets for 45 source files that are out of date
>         updating environment: 45 added, 0 changed, 0 removed
>         reading... api/artist_api Exception occurred:
>           File "/Users/cmoad/workspace/matplotlib/doc/sphinxext/
>         inheritance_diagram.py", line 78, in _import_class_or_module
>             "Invalid class '%s' specified for inheritance diagram" % name)
>         ValueError: Invalid class 'matplotlib.patches' specified for
>          inheritance diagram
>
>         Thanks,
>                Charlie
>
>         -------------------------------------------------------------------------
>         Check out the new SourceForge.net Marketplace.
>         It's the best place to buy or sell services for
>         just about anything Open Source.
>         http://sourceforge.net/services/buy/index.php
>         _______________________________________________
>         Matplotlib-devel mailing list
>         Mat...@li...
>         <mailto:Mat...@li...>
>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>          
>
>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Python2.5 on OSX.5

On Thu, Jun 19, 2008 at 11:14 PM, Michael Droettboom <md...@st...>
wrote:

> What version of Python are you running?  All I can think from looking at
> the code is that something in the regex is behaving differently for you than
> me (on Python 2.5).
>
> If you just want the docs to build (minus the inheritance diagrams), you
> can put a "return []" at the top of "inheritance_diagram_directive_run" in
> inheritance_diagram.py
>
> Cheers,
> Mike
>
> Charles Moad wrote:
>
>> Just jumped into the new docs to take a look and immediately having
>>  problems building.  I am hoping someone can make a quick fix so I  don't
>> have to debug.
>>
>> quaternion:doc cmoad$ ./make.py html
>> Sphinx v0.3, building html
>> trying to load pickled env... not found
>> building [html]: targets for 45 source files that are out of date
>> updating environment: 45 added, 0 changed, 0 removed
>> reading... api/artist_api Exception occurred:
>>   File "/Users/cmoad/workspace/matplotlib/doc/sphinxext/
>> inheritance_diagram.py", line 78, in _import_class_or_module
>>     "Invalid class '%s' specified for inheritance diagram" % name)
>> ValueError: Invalid class 'matplotlib.patches' specified for  inheritance
>> diagram
>>
>> Thanks,
>>        Charlie
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>

Michael Droettboom wrote:
> John Hunter wrote:
>>   Of course, the rendering is also somewhat painful
>> to me, after years of looking at agg rendering.  Maybe I need to write
>> a dot output renderer....
>>     
The current version of graphviz uses either cairo or gd (the default 
being cairo on most modern installations.)

Now that you've uploaded the docs, I see that the font you're getting 
isn't as nice as mine.  I was setting "fontname" to "sans", which is 
supposed to get the default sans serif font on the system.  It appears, 
from testing, one can provide a list of fonts to dot, so I'll change it 
to try good fonts first, with sans as the last resort fallback.

It still makes the error of not pixel-aligning the rectangles, which 
makes the edges look fuzzy.  That should probably be fixed.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Olle Engdegård wrote:
> hist(histtype="step") worked fine in rev5412, but in the latest I get
> 
>>>> hist(randn(1000), histtype="step")
> Traceback (most recent call last):
> /.../
>      raise TypeError, 'There is no patch property "%s"'%key
> TypeError: There is no patch property "closed"
> 
> 
> Changing
> closed = kwargs.get('closed', True)
> back to
> closed = kwargs.pop('closed')
> 
> in axes.py helps (but there was probably a reason for the change in the 
> first place)
> 
> Cheers,
> Olle
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi Olle,

   thanks for the report. This is fixed now in r5609.

Manuel

John Hunter wrote:
> On Thu, Jun 19, 2008 at 3:05 PM, Michael Droettboom <md...@st...> wrote:
>   
>> I just committed support for inheritance graphs in the docs like the one
>> attached.  In the docs themselves, an image map is included so clicking on a
>> node hyperlinks to the class docs.
>>
>> It uses "dot" to render the graph, and therefore you must have graphviz
>> installed.  If it isn't, the directive *should* insert warnings in the docs
>> and not hard fail, but please let me know if it does.  We can just as easily
>> change that behavior so it doesn't even insert the warnings.
>>     
>
> I think these will be really useful. I hope we can tweak the layout
> somewhat -- I think some of these graphs are too wide, for example (eg
> the artist graph).
One cheap way to deal with the width might be to just use the class 
name, not "matplotlib.artist. ...".  But in general, if you have four 
levels of nesting, you're guaranteed four columns with the dot algorithm 
(excepting manual tweaks).
>   Of course, the rendering is also somewhat painful
> to me, after years of looking at agg rendering.  Maybe I need to write
> a dot output renderer....
>
> But aside from these minor stylistic nits which we can improve, the
> functionality is great and I suspect sphinx will be interested in
> including this....  Gee, we sure are acting like typical developers:
> spending all our time working on the doc *system* rather than the
> boring old docs themselves :-)
>   
Yep... ;)

Mike

What version of Python are you running?  All I can think from looking at 
the code is that something in the regex is behaving differently for you 
than me (on Python 2.5).

If you just want the docs to build (minus the inheritance diagrams), you 
can put a "return []" at the top of "inheritance_diagram_directive_run" 
in inheritance_diagram.py

Cheers,
Mike

Charles Moad wrote:
> Just jumped into the new docs to take a look and immediately having  
> problems building.  I am hoping someone can make a quick fix so I  
> don't have to debug.
>
> quaternion:doc cmoad$ ./make.py html
> Sphinx v0.3, building html
> trying to load pickled env... not found
> building [html]: targets for 45 source files that are out of date
> updating environment: 45 added, 0 changed, 0 removed
> reading... api/artist_api Exception occurred:
>    File "/Users/cmoad/workspace/matplotlib/doc/sphinxext/ 
> inheritance_diagram.py", line 78, in _import_class_or_module
>      "Invalid class '%s' specified for inheritance diagram" % name)
> ValueError: Invalid class 'matplotlib.patches' specified for  
> inheritance diagram
>
> Thanks,
> 	Charlie
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

Just jumped into the new docs to take a look and immediately having  
problems building.  I am hoping someone can make a quick fix so I  
don't have to debug.

quaternion:doc cmoad$ ./make.py html
Sphinx v0.3, building html
trying to load pickled env... not found
building [html]: targets for 45 source files that are out of date
updating environment: 45 added, 0 changed, 0 removed
reading... api/artist_api Exception occurred:
   File "/Users/cmoad/workspace/matplotlib/doc/sphinxext/ 
inheritance_diagram.py", line 78, in _import_class_or_module
     "Invalid class '%s' specified for inheritance diagram" % name)
ValueError: Invalid class 'matplotlib.patches' specified for  
inheritance diagram

Thanks,
	Charlie

I believe there is a bug in the figimage handling when multiple images
are present.  It looks like there is a negative sign in the
transformation that shouldn't be there.  It is common to get upside
down in mpl, since bottom is 0 for us and usually bottom is top

Uncomment out the second figimage call to see the problem in the example below::

import numpy as np
import matplotlib.mathtext as mathtext
import matplotlib.pyplot as plt

parser = mathtext.MathTextParser("Bitmap")

parser.to_png('test2.png',
r'$\left[\left\lfloor\frac{5}{\frac{\left(3\right)}{4}}
y\right)\right]$', color='green', fontsize=14, dpi=100)


rgba1, depth1 = parser.to_rgba(r'IQ: $\sigma_i=15$', color='blue',
fontsize=20, dpi=200)
rgba2, depth2 = parser.to_rgba(r'some other string', color='red',
fontsize=20, dpi=200)

fig = plt.figure()
fig.figimage(rgba1.astype(float)/255., 100, 100)
#ig.figimage(rgba2.astype(float)/255., 100, 300)

plt.show()

On Thu, Jun 19, 2008 at 3:05 PM, Michael Droettboom <md...@st...> wrote:
> I just committed support for inheritance graphs in the docs like the one
> attached.  In the docs themselves, an image map is included so clicking on a
> node hyperlinks to the class docs.
>
> It uses "dot" to render the graph, and therefore you must have graphviz
> installed.  If it isn't, the directive *should* insert warnings in the docs
> and not hard fail, but please let me know if it does.  We can just as easily
> change that behavior so it doesn't even insert the warnings.

I think these will be really useful. I hope we can tweak the layout
somewhat -- I think some of these graphs are too wide, for example (eg
the artist graph).  Of course, the rendering is also somewhat painful
to me, after years of looking at agg rendering.  Maybe I need to write
a dot output renderer....

But aside from these minor stylistic nits which we can improve, the
functionality is great and I suspect sphinx will be interested in
including this....  Gee, we sure are acting like typical developers:
spending all our time working on the doc *system* rather than the
boring old docs themselves :-)

JDH

On Thursday 19 June 2008 04:05:26 pm Michael Droettboom wrote:
> I just committed support for inheritance graphs in the docs like the one
> attached.  In the docs themselves, an image map is included so clicking
> on a node hyperlinks to the class docs.

Really cool, Mike.

> It uses "dot" to render the graph, and therefore you must have graphviz
> installed.  If it isn't, the directive *should* insert warnings in the
> docs and not hard fail, but please let me know if it does.  We can just
> as easily change that behavior so it doesn't even insert the warnings.
>
> I'm also interested in feedback on the usefulness of these graphs or
> ways they could be improved.  I personally find them quite helpful, as
> long as they aren't too large.  Rather than producing one graph for
> everything, it works pretty well to create graphs on the level of the
> current division of the API docs (artists, collections, transforms etc.)

I agree, it works well with some boundary conditions. In the old users guide, 
the inheritance diagram for backend FigureCanvases could have a big 
rubberstamp across it that reads "COMPLICATED". (No offense intended, but 
damn. :) )

Darren

On Thu, Jun 19, 2008 at 1:05 PM, Michael Droettboom <md...@st...> wrote:

> This directive suffers from the same shortcoming as mathpng.py -- the images
> are written to _static which probably isn't  a good place for generated
> files.  Once we have a solution to this, I'll fix it.  It may be worth
> collaborating with Georg Brandl et al. on a general solution for generated
> images.  That will also make this directive more valuable as a
> general-purpose (non-matplotlib) directive.

Epydoc has support for this if you have dot/graphviz installed, but
I'm MUCH happier with the sphinx output.  It would be really great if
you could bring all the remaining API-documentation features of epydoc
into sphinx, so we could finally have one tool to do it all.

Cheers,

f

I just committed support for inheritance graphs in the docs like the one 
attached.  In the docs themselves, an image map is included so clicking 
on a node hyperlinks to the class docs.

It uses "dot" to render the graph, and therefore you must have graphviz 
installed.  If it isn't, the directive *should* insert warnings in the 
docs and not hard fail, but please let me know if it does.  We can just 
as easily change that behavior so it doesn't even insert the warnings.

I'm also interested in feedback on the usefulness of these graphs or 
ways they could be improved.  I personally find them quite helpful, as 
long as they aren't too large.  Rather than producing one graph for 
everything, it works pretty well to create graphs on the level of the 
current division of the API docs (artists, collections, transforms etc.)

This directive suffers from the same shortcoming as mathpng.py -- the 
images are written to _static which probably isn't  a good place for 
generated files.  Once we have a solution to this, I'll fix it.  It may 
be worth collaborating with Georg Brandl et al. on a general solution 
for generated images.  That will also make this directive more valuable 
as a general-purpose (non-matplotlib) directive.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On the 0.91 branch, there was an example called clippedline.py that
> did a searchsorted on the xdata based on the xlim to cull out points
> far outside the view limits.  This is useful if you have a really long
> time series and want to navigate through it.
>
> This is broken on the trunk, but before I dive too deep into trying to
> fix it, I wanted to get some input about the best way to go about this
> given the new transforms/path infrastructure.  Michael, I know you did
> some work to make this kind of use more efficient by default, so I
> wanted to get your opinion on the best place to go about making this
> kind of optimization.
>   
This sort of culling happens automatically in the Agg backend now, 
without any data copies (see agg_py_path_iterator.h).  Unfortunately, 
that doesn't actually make it any easier to do this sort of thing from 
Python.

As for the bug in clippedline.py -- Line2D objects store _xorig, _yorig 
(the original data) and _x, _y (unit converted data).  The difference 
now is that _x and _y are computed less often, so they don't actually 
exist during the call to ClippedLine.set_data.  You can force their 
computation by calling self.recache() after the call to 
Line2D.set_data(), or we can restore the old behavior by calling 
recache() at the bottom of Line2D.set_data(), albeit with a performance 
penalty on panning/zooming due to the tick lines taking longer to move.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On the 0.91 branch, there was an example called clippedline.py that
did a searchsorted on the xdata based on the xlim to cull out points
far outside the view limits.  This is useful if you have a really long
time series and want to navigate through it.

This is broken on the trunk, but before I dive too deep into trying to
fix it, I wanted to get some input about the best way to go about this
given the new transforms/path infrastructure.  Michael, I know you did
some work to make this kind of use more efficient by default, so I
wanted to get your opinion on the best place to go about making this
kind of optimization.

JDH