matplotlib-devel Mailing List for matplotlib

Is there a reason why Axis.get_label returns the label as a Text instance, or should there really be set_label/get_label methods that takes a string and set the text value of the Text instance and returns the string value of the Text instance?
Everywhere it is used in the code it is used in a two-step process to really just get and set the string value of the Text instance.
--James Evans

 
 --- the forwarded message follows ---

Comments below.
Nils Wagner wrote:
> Hi all,
>
> I tried to build the HTML documentation.
> Here are some failures
>
>
> matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py
> Traceback (most recent call last):
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
> runfile(fullpath)
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
> module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
> File "axes_divider.py", line 168
> rs, as = s.get_size(renderer)
> ^
> SyntaxError: invalid syntax
>
> warnings.warn(s)
> examples/pylab_examples/axes_grid 
> /home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py:190: 
> UserWarning: Exception running plot 
> /home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_grid.py
> Traceback (most recent call last):
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
> runfile(fullpath)
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
> module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
> File "axes_grid.py", line 5, in <module>
> File 
> "/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py", 
> line 168
> rs, as = s.get_size(renderer)
> ^
> SyntaxError: invalid syntax
> 
I can't reproduce this here. What version of matplotlib are you running?
> warnings.warn(s)
> Traceback (most recent call last):
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
> runfile(fullpath)
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
> module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
> File "geo_demo.py", line 9, in <module>
> File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/pyplot.py", 
> line 636, in subplot
> a = fig.add_subplot(*args, **kwargs)
> File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/figure.py", 
> line 690, in add_subplot
> a = subplot_class_factory(projection_class)(self, 
> *args, **kwargs)
> File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/axes.py", 
> line 7460, in __init__
> self._axes_class.__init__(self, fig, self.figbox, 
> **kwargs)
> File "custom_projection_example.py", line 35, in 
> __init__
> TypeError: expected string or Unicode object, NoneType 
> found
> oc/sphinxext/plot_directive.py:190: UserWarning: Exception 
> running plot 
> /home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/loadrec.py
> Traceback (most recent call last):
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
> runfile(fullpath)
> File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
> module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
> File "loadrec.py", line 14, in <module>
> File 
> "/home/nwagner/local/lib64/python2.6/site-packages/mpl_toolkits/exceltools.py", 
> line 31, in <module>
> raise ImportError('You must install xlwt or 
> pyExcelterator to use the exceltools')
> ImportError: You must install xlwt or pyExcelterator to 
> use the exceltools
> 
This is exactly as it says:
"You must install xlwt or pyExcelterator to 
use the exceltools"
Since that particular example uses the exceltools, and you haven't installed it's requirements, it can't generate the example. Worst case, however, it should continue to generate the rest of the docs without it.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

The current matplotlib Mac binary installer unfortunately reintroduces 
an old problem: it does not work if the user has a 3rd party Tcl/Tk 
installed (as anyone who uses Tkinter seriously would have).
The solution is simple: if one is building a matplotlib Mac binary 
installer then please, please install ActiveState Tcl/Tk first 
(preferably the latest version of 8.4 -- which is 8.4.19 last I 
checked). The resulting binary will work with the built-in Tcl/Tk as 
well as any user's 3rd party Tcl/Tk.
Without this "fix", the resulting binary will abort with any attempt to 
produce a graph using TkAgg and a 3rd party Tcl/Tk.
ISo...could I request a new Mac binary with this fix in place? Or at 
least that future Mac binaries will be built this way?
-- Russell
P.S. the situation could get "interesting" with a future version of 
MacOS X during the transition from Tcl/Tk 8.4 to 8.5. But for now just 
sticking with 8.4 is safe since it is the recommended version for Python 
2.5 and is also what comes with MacOS X.
P.P.S. I suspect (but have not confirmed) that Mac Python 2.5.4 has this 
same problem. Mac Python 2.5.2 is definitely OK.

Hi all,
I tried to build the HTML documentation.
Here are some failures
matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py
Traceback (most recent call last):
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
 runfile(fullpath)
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
 module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
 File "axes_divider.py", line 168
 rs, as = s.get_size(renderer)
 ^
 SyntaxError: invalid syntax
 warnings.warn(s)
examples/pylab_examples/axes_grid 
/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py:190: 
UserWarning: Exception running plot 
/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_grid.py
Traceback (most recent call last):
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
 runfile(fullpath)
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
 module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
 File "axes_grid.py", line 5, in <module>
 File 
"/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py", 
line 168
 rs, as = s.get_size(renderer)
 ^
 SyntaxError: invalid syntax
 warnings.warn(s)
 Traceback (most recent call last):
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
 runfile(fullpath)
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
 module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
 File "geo_demo.py", line 9, in <module>
 File 
"/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/pyplot.py", 
line 636, in subplot
 a = fig.add_subplot(*args, **kwargs)
 File 
"/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/figure.py", 
line 690, in add_subplot
 a = subplot_class_factory(projection_class)(self, 
*args, **kwargs)
 File 
"/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/axes.py", 
line 7460, in __init__
 self._axes_class.__init__(self, fig, self.figbox, 
**kwargs)
 File "custom_projection_example.py", line 35, in 
__init__
TypeError: expected string or Unicode object, NoneType 
found
oc/sphinxext/plot_directive.py:190: UserWarning: Exception 
running plot 
/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/loadrec.py
Traceback (most recent call last):
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
 runfile(fullpath)
 File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
 module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
 File "loadrec.py", line 14, in <module>
 File 
"/home/nwagner/local/lib64/python2.6/site-packages/mpl_toolkits/exceltools.py", 
line 31, in <module>
 raise ImportError('You must install xlwt or 
pyExcelterator to use the exceltools')
ImportError: You must install xlwt or pyExcelterator to 
use the exceltools
Nils

On Thu, Jan 29, 2009 at 12:07 PM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> while reading the doc, I've encountered some little errors I've fixed
> in the attached patch; nothing extremely difficult, but still worth
> fixing :)
>
> I'm even wondering if the svnmerge section in "Coding guide" is still
> valid, since I've seen some emails passing here about that, but that's
> too hard for me (as of now) :) .
Thanks Sandro -- applied to the branch and trunk. The merge docs are
up to date.
JDH

Hello,
while reading the doc, I've encountered some little errors I've fixed
in the attached patch; nothing extremely difficult, but still worth
fixing :)
I'm even wondering if the svnmerge section in "Coding guide" is still
valid, since I've seen some emails passing here about that, but that's
too hard for me (as of now) :) .
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Okay. Done.
--James
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> Sent: Wednesday, January 28, 2009 11:46 AM
> To: James Evans
> Cc: Eric Firing; matplotlib development list
> Subject: Re: [matplotlib-devel] Updated units.ConversionInterface
> 
> On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jre...@ea...> wrote:
> > Eric,
> >
> > I was looking at it from the perspective of most of the other API calls throughout matplotlib have
> the Axes or Axis as the first
> > argument. Typically this is because it is what wants the work to be done or is being worked on. I
> was just following suit. I can
> > see where you are coming from. I have no real strong argument for or against, so if I should swap
> them around as you had suggested,
> > then I have no problem changing it.
> 
> I tend to agree with Eric -- then people writing converters who don't
> care about the axis input can ignore it more easily.
> 
> JDH

I just completed some open-heart surgery on the path simplification code 
to resolve this and other issues. Though the integer overflow bug is on 
the maintenance branch, the proper solution was large enough and risky 
enough that I have only committed it to the development trunk.
Before, the path simplification code jumbled a number of discrete steps 
together in the code:
 1. Nan (nonfinite) handling
 2. Clipping
 3. Quantization
 4. Simplification
This has been rewritten (see path_converters.h) so each step is handled 
by a separate iterator class that can be independently switched on-and-off.
This refactoring made it much easier to rewrite the clipping algorithm 
to actually bisect line segments at the figure boundary, rather than (as 
before) simply removing vertices after crossing outside the boundary.
Additionally, nan-value-handling was formerly handled in both Python and 
C++, which was both double the maintenance and slower in Python. Now, 
the C++ version of the entire pipeline has been exposed to Python, so we 
have a single (and faster) code path to debug. (Note that whereas it 
behaves as an iterator in C++, it actually writes to a new array in the 
Python-wrapped version to avoid lots of tiny Python function calls). 
All backends now use this pipeline (through the use of 
Path.iter_segments). 
A side effect of this is that whereas before Python backends were forced 
to get clipping and simplification together, they now have independent 
control. This fixes two long-standing bugs in non-Agg backends:
 1. large values would cause integer overflow (causes the lines to
 appear to go in the wrong direction)
 2. clipping should be turned off for filled regions, but that
 wasn't previously possible without also losing simplification
Lastly, the threshold of angular similarity below which simplification 
will start removing vertices has been exposed to the user as an rcParam 
(path.simplify_threshold). It can also be set on an individual basis to 
any Path object.
The one remaining major piece is to get the native Cocoa backend to 
support this infrastructure. Right now, it reimplements its own 
nan-handling and doesn't perform any of the other steps. This will 
probably require some code compiled in C++ but exported as C to make it 
accessible to Objective-C. The general roadmap is in "cleanup_path" in 
_path.cpp. I'm happy to help with this, but without a Mac, it will be 
hard to compile and test these changes.
I've looked through all the backend_driver images, and everything seems 
ok, but let me know if you see any strangely drawn paths etc.
Cheers,
Mike
Michael Droettboom wrote:
> Okay -- I think I've at least narrowed it down to a cause. Agg uses 
> fixed-point arithmetic to render at the low-level -- by default it uses 
> 24.8 (i.e. 24 integer bits and 8 fractional bits). Therefore, it can 
> only handle pixel coordinates in the range -2^23 to 2^23. Both of the 
> provided examples, after the data has been scaled, draw outside of this 
> range, which results in integer overflow, hence things going in the 
> wrong direction etc.
>
> We could change the fixed point in agg_basics.h, but I hesitate to do 
> so, as it's at the expense of fine detail. We could possibly move to 
> 64-bits, but I'm not sure how easy that would be, or what the impact 
> might be on 32-bit platforms.
>
> 
> //----------------------------------------------------poly_subpixel_scale_e
> // These constants determine the subpixel accuracy, to be more precise,
> // the number of bits of the fractional part of the coordinates.
> // The possible coordinate capacity in bits can be calculated by 
> formula:
> // sizeof(int) * 8 - poly_subpixel_shift, i.e, for 32-bit integers and
> // 8-bits fractional part the capacity is 24 bits.
> enum poly_subpixel_scale_e
> {
> poly_subpixel_shift = 8, 
> //----poly_subpixel_shift
> poly_subpixel_scale = 1<<poly_subpixel_shift, 
> //----poly_subpixel_scale
> poly_subpixel_mask = poly_subpixel_scale-1, 
> //----poly_subpixel_mask
> };
>
>
> One thing I will look into is whether the line simplification algorithm 
> can be extended to actually clip the lines when they go outside of the 
> image range. At the moment, it does some work to reduce the number of 
> points outside of the image, but it always draws at least one point 
> outside at its original location. It looks like Agg has some of the 
> pieces necessary to do this -- whether it's feasible to integrate that 
> into our existing line simplification algorithm remains to be seen.
>
> Mike
>
>
> Michael Droettboom wrote:
> 
>> Thanks for this.
>>
>> I believe both of these examples illustrate a shortcoming in Agg when 
>> the distance between two points on either end of a line is too great.
>>
>> I'll do some digging around and see what may be causing this and if any 
>> limits can be adjusted -- I may not get to this today, however.
>>
>> Mike
>>
>> João Luís Silva wrote:
>> 
>> 
>>> Jan Müller wrote:
>>> 
>>> 
>>> 
>>>> Hi,
>>>>
>>>> The simple code snippet at the end of this mail should plot a single line. 
>>>>
>>>> 
>>>> 
>>>> 
>>> I can confirm this bug on Ubuntu running matplotlib svn revision 6827. 
>>> However I think it doesn't have to do with the log-scale but with the 
>>> big variations on the x-scale and the custom xscale. I've reproduced a 
>>> similar behavior with the following script (pan and zoom to see the 
>>> buggy behavior).
>>> --------------------
>>>
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>>
>>> x = np.array([1.0,2.0,3.0,1.0E5,2.0E5])
>>> y = np.arange(len(x))
>>> plt.plot(x,y)
>>> plt.xlim(xmin=2,xmax=6)
>>> plt.show()
>>>
>>> --------------------
>>>
>>> Best Regards,
>>> João Silva
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> 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