matplotlib-users Mailing List for matplotlib

I'm plotting upper and lower limits via the lolims and uplims keywords to
the errorbar function and have noticed two problems.
First, the direction of the arrows produced by these keywords are opposite
to one would expect, i.e. lolims=True should produce an upward-pointing
arrow and uplims should produce a downward-pointing arrow. For example, a
"lower-limit" means the exact value is unknown, but it is known not to be
below a particular value -- this is denoted by an upward arrow whose
starting point (arrow base) is at the value of the lower limit. The xlolims
and yuplims have this similar reversed behavior.
The second point deals with the starting point of the arrow base. For
limits, the arrow should begin at the value of upper/lower limit. Currently
the arrows are centered at the limit value.
To summarize both issues with an example:
errorbar(10, 10, yerr=1, uplims=True) should produce a downward pointing
arrow whose base is at (10, 10) and whose head is at (10, 9). It currently
produces an upward-pointing arrow whose base is at (10,9) and whose head is
at (10, 11).
Thanks,
Larry

Ryan May wrote:
>> 
> Try changing your plot limits. :)
>
> pylab.xlim(-3,3)
> pylab.ylim(-3,3)
> 
Aha! Perfect; thank you!
I'll fix this in Sage now...
Jason

On Fri, Feb 13, 2009 at 2:30 PM, <jas...@cr...> wrote:
> Eric Firing wrote:
>
>> Ryan May wrote:
>>
>>> On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr... <mailto:
>>> jas...@cr...>> wrote:
>>>
>>>
>>> A student of mine recently noticed that sometimes, quiver plots were
>>> coming up empty (using the plot_vector_field function from Sage, which
>>> passes everything on to quiver). Upon investigation, we saw that some
>>> of the array entries passed in were infinity because of where we
>>> happened to evaluate the function. It was relatively easy to correct
>>> in
>>> our case (change the evaluation to miss the bad point), but is there a
>>> better way to handle this? Can this be considered a bug in quiver
>>> (i.e.,
>>> returning a blank plot when one of the vectors has an infinite
>>> coordinate?).
>>>
>>> Here is some example code illustrating the problem:
>>>
>>>
>>> import pylab
>>> import numpy
>>> step=1
>>> X,Y = numpy.meshgrid(
>>> numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
>>> U = 1/X
>>> V = Y
>>> pylab.figure()
>>> Q = pylab.quiver( X,Y,U, V)
>>> pylab.savefig("test.png")
>>>
>>> When you change step to something that avoids an evaluation at x=0
>>> (say,
>>> step=0.13), you get a nice plot.
>>>
>>> Is this something that we should be preprocessing in Sage before
>>> calling
>>> quiver, masking those "bad" points or something? I haven't used
>>> masking
>>> before, but I'd like to fix Sage's plot_vector_field function to
>>> return
>>> something sensible, even when the function happens to be infinite at
>>> one
>>> of the points.
>>>
>>>
>>> I'm not sure why quiver does not plot any arrows in that case, but it's
>>> also easy enough to mask out the values yourself:
>>>
>>> U = 1/X
>>> U = numpy.ma.array(U, mask=numpy.isinf(U))
>>> V = Y
>>> V = numpy.ma.array(V, mask=numpy.isinf(V))
>>>
>>> You can also catch NaN values by using ~numpy.isfinite() instead of
>>> numpy.isinf().
>>>
>>
>> This is a good use case for numpy.ma.masked_invalid:
>>
>> In [2]:numpy.ma.masked_invalid?
>> Type: function
>> Base Class: <type 'function'>
>> String Form: <function masked_invalid at 0xb62bccdc>
>> Namespace: Interactive
>> File: /usr/local/lib/python2.5/site-packages/numpy/ma/core.py
>> Definition: numpy.ma.masked_invalid(a, copy=True)
>> Docstring:
>> Mask the array for invalid values (NaNs or infs).
>> Any preexisting mask is conserved.
>>
>>
> Thanks for both of your replies. So I tried the following:
>
> import pylab
> import numpy
> step=1
> X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
> U = numpy.ma.masked_invalid(1/X)
> V = numpy.ma.masked_invalid(Y)
> pylab.figure()
> Q = pylab.quiver( X,Y,U, V)
> pylab.savefig("test.png")
>
> and I still didn't get a plot. I noticed two things:
>
> 1. The unmasked portion of each array might be different; I hope quiver can
> handle that.
>
> 2. Even when I called pylab.quiver(X,Y,U,U) (so that the masks lined up), I
> still didn't get a plot.
>
> Does quiver handle masks properly, or did I just do something wrong?
>
It should, but there was a release with a bug in the masked support for
quiver. What version are you running?
import matplotlib; print matplotlib.__version__
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

Eric Firing wrote:
> Ryan May wrote:
>> On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr... 
>> <mailto:jas...@cr...>> wrote:
>>
>>
>> A student of mine recently noticed that sometimes, quiver plots were
>> coming up empty (using the plot_vector_field function from Sage, 
>> which
>> passes everything on to quiver). Upon investigation, we saw that 
>> some
>> of the array entries passed in were infinity because of where we
>> happened to evaluate the function. It was relatively easy to 
>> correct in
>> our case (change the evaluation to miss the bad point), but is 
>> there a
>> better way to handle this? Can this be considered a bug in quiver 
>> (i.e.,
>> returning a blank plot when one of the vectors has an infinite
>> coordinate?).
>>
>> Here is some example code illustrating the problem:
>>
>>
>> import pylab
>> import numpy
>> step=1
>> X,Y = numpy.meshgrid(
>> numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
>> U = 1/X
>> V = Y
>> pylab.figure()
>> Q = pylab.quiver( X,Y,U, V)
>> pylab.savefig("test.png")
>>
>> When you change step to something that avoids an evaluation at 
>> x=0 (say,
>> step=0.13), you get a nice plot.
>>
>> Is this something that we should be preprocessing in Sage before 
>> calling
>> quiver, masking those "bad" points or something? I haven't used 
>> masking
>> before, but I'd like to fix Sage's plot_vector_field function to 
>> return
>> something sensible, even when the function happens to be infinite 
>> at one
>> of the points.
>>
>>
>> I'm not sure why quiver does not plot any arrows in that case, but 
>> it's also easy enough to mask out the values yourself:
>>
>> U = 1/X
>> U = numpy.ma.array(U, mask=numpy.isinf(U))
>> V = Y
>> V = numpy.ma.array(V, mask=numpy.isinf(V))
>>
>> You can also catch NaN values by using ~numpy.isfinite() instead of 
>> numpy.isinf().
>
> This is a good use case for numpy.ma.masked_invalid:
>
> In [2]:numpy.ma.masked_invalid?
> Type: function
> Base Class: <type 'function'>
> String Form: <function masked_invalid at 0xb62bccdc>
> Namespace: Interactive
> File: /usr/local/lib/python2.5/site-packages/numpy/ma/core.py
> Definition: numpy.ma.masked_invalid(a, copy=True)
> Docstring:
> Mask the array for invalid values (NaNs or infs).
> Any preexisting mask is conserved.
>
Thanks for both of your replies. So I tried the following:
import pylab
import numpy
step=1
X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
U = numpy.ma.masked_invalid(1/X)
V = numpy.ma.masked_invalid(Y)
pylab.figure()
Q = pylab.quiver( X,Y,U, V)
pylab.savefig("test.png")
and I still didn't get a plot. I noticed two things:
1. The unmasked portion of each array might be different; I hope quiver 
can handle that.
2. Even when I called pylab.quiver(X,Y,U,U) (so that the masks lined 
up), I still didn't get a plot.
Does quiver handle masks properly, or did I just do something wrong?
Jason

Ryan May wrote:
> On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr... 
> <mailto:jas...@cr...>> wrote:
> 
> 
> A student of mine recently noticed that sometimes, quiver plots were
> coming up empty (using the plot_vector_field function from Sage, which
> passes everything on to quiver). Upon investigation, we saw that some
> of the array entries passed in were infinity because of where we
> happened to evaluate the function. It was relatively easy to correct in
> our case (change the evaluation to miss the bad point), but is there a
> better way to handle this? Can this be considered a bug in quiver (i.e.,
> returning a blank plot when one of the vectors has an infinite
> coordinate?).
> 
> Here is some example code illustrating the problem:
> 
> 
> import pylab
> import numpy
> step=1
> X,Y = numpy.meshgrid(
> numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
> U = 1/X
> V = Y
> pylab.figure()
> Q = pylab.quiver( X,Y,U, V)
> pylab.savefig("test.png")
> 
> When you change step to something that avoids an evaluation at x=0 (say,
> step=0.13), you get a nice plot.
> 
> Is this something that we should be preprocessing in Sage before calling
> quiver, masking those "bad" points or something? I haven't used masking
> before, but I'd like to fix Sage's plot_vector_field function to return
> something sensible, even when the function happens to be infinite at one
> of the points.
> 
> 
> I'm not sure why quiver does not plot any arrows in that case, but it's 
> also easy enough to mask out the values yourself:
> 
> U = 1/X
> U = numpy.ma.array(U, mask=numpy.isinf(U))
> V = Y
> V = numpy.ma.array(V, mask=numpy.isinf(V))
> 
> You can also catch NaN values by using ~numpy.isfinite() instead of 
> numpy.isinf().
This is a good use case for numpy.ma.masked_invalid:
In [2]:numpy.ma.masked_invalid?
Type:		function
Base Class:	<type 'function'>
String Form:	<function masked_invalid at 0xb62bccdc>
Namespace:	Interactive
File:		/usr/local/lib/python2.5/site-packages/numpy/ma/core.py
Definition:	numpy.ma.masked_invalid(a, copy=True)
Docstring:
 Mask the array for invalid values (NaNs or infs).
 Any preexisting mask is conserved.
Eric
> 
> Ryan
> 
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr...> wrote:
>
> A student of mine recently noticed that sometimes, quiver plots were
> coming up empty (using the plot_vector_field function from Sage, which
> passes everything on to quiver). Upon investigation, we saw that some
> of the array entries passed in were infinity because of where we
> happened to evaluate the function. It was relatively easy to correct in
> our case (change the evaluation to miss the bad point), but is there a
> better way to handle this? Can this be considered a bug in quiver (i.e.,
> returning a blank plot when one of the vectors has an infinite
> coordinate?).
>
> Here is some example code illustrating the problem:
>
>
> import pylab
> import numpy
> step=1
> X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
> U = 1/X
> V = Y
> pylab.figure()
> Q = pylab.quiver( X,Y,U, V)
> pylab.savefig("test.png")
>
> When you change step to something that avoids an evaluation at x=0 (say,
> step=0.13), you get a nice plot.
>
> Is this something that we should be preprocessing in Sage before calling
> quiver, masking those "bad" points or something? I haven't used masking
> before, but I'd like to fix Sage's plot_vector_field function to return
> something sensible, even when the function happens to be infinite at one
> of the points.
>
I'm not sure why quiver does not plot any arrows in that case, but it's also
easy enough to mask out the values yourself:
U = 1/X
U = numpy.ma.array(U, mask=numpy.isinf(U))
V = Y
V = numpy.ma.array(V, mask=numpy.isinf(V))
You can also catch NaN values by using ~numpy.isfinite() instead of
numpy.isinf().
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

You can pass "extent=(left, right, bottom, top)" to imshow to specify 
what the pixels in the array correspond to in data space.
Mike
Lewis, Ambrose J. wrote:
>
> Hi All:
>
> I’m working on a wxPython GUI that uses matplotlib.
>
> This program reads "chunks" of a data file into a numpy array and than 
> plots it using imshow.
>
> The first chunk works great. But, when I load chunks 2 to N, how can I 
> specify the different values for the labels on the x axis?
>
> I tried using "axes.set_xlim". This did reposition the x axis as 
> hoped, but the data is always being drawn back at the "zero" offset.
>
> Is there a way to tell the axis to map the array to a different x range?
>
> I can’t read the whole file at once, it’s just too big
>
> THANXS
>
> amb
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Feb 13, 2009 at 12:01 PM, Lewis, Ambrose J. <
AMB...@sa...> wrote:
> Hi All:
>
> I'm working on a wxPython GUI that uses matplotlib.
>
> This program reads "chunks" of a data file into a numpy array and than
> plots it using imshow.
>
> The first chunk works great. But, when I load chunks 2 to N, how can I
> specify the different values for the labels on the x axis?
>
> I tried using "axes.set_xlim". This did reposition the x axis as hoped,
> but the data is always being drawn back at the "zero" offset.
>
> Is there a way to tell the axis to map the array to a different x range?
>
> I can't read the whole file at once, it's just too big
>
Does the 'extent' keyword argument to imshow do what you want?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

A student of mine recently noticed that sometimes, quiver plots were 
coming up empty (using the plot_vector_field function from Sage, which 
passes everything on to quiver). Upon investigation, we saw that some 
of the array entries passed in were infinity because of where we 
happened to evaluate the function. It was relatively easy to correct in 
our case (change the evaluation to miss the bad point), but is there a 
better way to handle this? Can this be considered a bug in quiver (i.e., 
returning a blank plot when one of the vectors has an infinite coordinate?).
Here is some example code illustrating the problem:
import pylab
import numpy
step=1
X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
U = 1/X
V = Y
pylab.figure()
Q = pylab.quiver( X,Y,U, V)
pylab.savefig("test.png")
When you change step to something that avoids an evaluation at x=0 (say, 
step=0.13), you get a nice plot.
Is this something that we should be preprocessing in Sage before calling 
quiver, masking those "bad" points or something? I haven't used masking 
before, but I'd like to fix Sage's plot_vector_field function to return 
something sensible, even when the function happens to be infinite at one 
of the points.
Thanks,
Jason
--
Jason Grout

Hi All:
I'm working on a wxPython GUI that uses matplotlib. 
This program reads "chunks" of a data file into a numpy array and than
plots it using imshow. 
The first chunk works great. But, when I load chunks 2 to N, how can I
specify the different values for the labels on the x axis?
I tried using "axes.set_xlim". This did reposition the x axis as hoped,
but the data is always being drawn back at the "zero" offset.
Is there a way to tell the axis to map the array to a different x range?
I can't read the whole file at once, it's just too big
THANXS
amb
 

On Fri, Feb 13, 2009 at 3:24 AM, Richard Jennings <rpj...@gm...>wrote:
> Hi,
>
> I am not expert in matplotlib, I use it to generate plots for a management
> performance tool.
>
> I have just upgraded this application from 0.98.3 to 0.98.5 and the
> upgrade broke the application in 3 places:
>
>
>
> 1). In units.py, Registry.get_converter(): this method has been made
> recursive in 0.98.5. The problem is that if x is a string then you get a
> recursion error.
>
> The cause is the 'iterable() function called in the line "if converter is
> None and interable(x):" The interable() function is in cbook.py and it
> actually tests to see if the object 'x' has a __len__() method. Call
> iterable() on a string and it returns true.
>
> Do " for thisx in x:" and you will always get the first character in the
> string, which is.... a string!
>
> My solution was to change iterable():
>
> Def iterable(obj):
>
> """
>
> Return true if **obj** is iterable
>
> """
>
> try: obj.__iter__()
>
> except AtributeError: return False
>
> return True
>
>
>
> this seems to have solved the problem.
>
This has been fixed on the SVN trunk. FYI, the problem with your fix above
is that, in general, we want strings to be considered iterable -- just not
in this case. It should also be noted that the purpose of the fix was to
eliminate the confusing infinite recursion. The fact that plotting strings
of numbers works is a coincidence of how matplotlib is coded up and really
should not be considered a supported feature.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

On Fri, Feb 13, 2009 at 6:24 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
> > On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
> >>
> >> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
>
> > Well, I checked in an example that shows the functionality. The problem
> is
> > that using these events doesn't follow the standard event API. You don't
> > connect using figure.canvas.mpl_connect() (it doesn't like the names
> > 'xlim_changed' and 'ylim_changed'), but rather you use
> > Axes.callbacks.connect(). Also, the an event object is not passed into
> the
> > callback, but rather the originating axes instance. Are these events
> relics
> > to the older version of event handling that haven't been moved to the
> > present?
> >
> > Otherwise, should I add a special section to the event handling docs to
> > handle these?
>
>
> Thanks for the example -- you are right that this is a 'legacy' event
> callback outside the regular event framework. So it doesn't really
> belong in the event handling chapter but may merit a quick note there.
> Alternatively, we could rather easily draft up a special event
> (NavigationEvent?) that *does* work in the regular event handling
> framework. The quirk is that the events are handled at the canvas
> level, so it would be difficult to register for a single axes, but one
> could get a NavigationEvent if the limits of any of the axes in the
> figure were updated, and use the inaxes attribute to process it. If
> this, or some variant of it, seems like a good idea I'm happy to add
> it.
>
I'm +1 on your idea. While it may be a little quirky that you can't
register for a single axes limit change, it's even weirder that you have
different ways to register for different types of events. I think the
overall API for matplotlib is improved by bringing *all* event callbacks
under a single, unified, API. Along those lines, I see these other 'events'
being processed in the code, but not formally recognized by the canvas level
event handler:
Aixs : 'units', 'units finalize'
Figure : 'dpi_changed'
Would it be good to try to move these to the canvas-level handler as well? I
don't have a good idea myself of how that would work right now.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I'm just commenting on the points I know about below -- leaving the rest 
to others.
Richard Jennings wrote:
>
> 2). Backend_svg.py._get_style(): in 0.98.3, stroke_width is a string 
> and in 0.98.5 it is a float. I set the styles by reading attributes in 
> an xml file and so the strings worked. When I upgraded, I got ‘float’ 
> type errors. My opinion is that we might expect parametric 
> polymorphism here. A stroke width could be ‘1’, 1 or 1.0 all of which 
> are legitimate parameters. Hence, when we set the kwarg ‘lw’ on 
> ‘plot’, a string, int or float should be legal. Just my opinion.
>
This change was made to work around a localization bug in Numpy. In a 
French locale (for example), printing a Numpy float scalar as a string 
would be "1,2" (which is against the SVG spec) and as a float would be 
"1.2".
But you're right -- this inadvertently broke supporting strings for 
certain parameters. I'm actually of the opinion that supporting strings 
in the first place was an unintentional feature -- none of our example 
or regression code uses it. I'm not sold that this is something that 
needs to be fixed.
But at a higher level, this re-raises the recurring issue about argument 
checking. In general, matplotlib doesn't do much type checking/coercion 
at the front end (user end), which leads to these sorts of unintended 
consequences in the backend. I would like to see more argument checking 
happening earlier so the user would get more localised and appropriate 
feedback when they passed in an invalid parameter. The idea of using 
Enthought's Traits library for this was thrown around in the past, but 
at the time it was impractical. Unfortunately, in the meantime that's 
kept us from doing the obvious and straightforward thing which is just 
to do more type and value checking in the setter methods. I think it 
would make a good project to go through and add type checkers to all the 
setters, followed by other user-points of entry, but it's not the 
sexiest or most interesting thing to do, perhaps.
>
> 3). Font_manager.createFontDict() in 0.98.3 become createFontList() in 
> 0.98.5. I didn’t find this change in Changes, but maybe I’m blind. 
> What I am saying here is that if I upgrade to 0.98.5 from 0.98.3, I 
> would expect 0.98.5 to be less ‘broke’ than 0.98.3, not different.
>
matplotlib version numbering has not traditionally followed Python's 
numbering scheme where the third number implies only bug fixes. We have 
started that sort of approach only recently with 0.98.5 where 0.98.5.x 
will be bugfixes only. In the future (maybe beginning 1.0 and later) we 
can probably have a more traditional version numbering scheme, though 
there has been no formal written decision on that.
That change has to do with moving from exact matching (which was 
"broke") to nearest-neighbor font matching. It is arguable that this is 
a bugfix, in that certain font lookups which were broken before are now 
correct, even though that implies different behavior.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
> On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
>>
>> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
> Well, I checked in an example that shows the functionality. The problem is
> that using these events doesn't follow the standard event API. You don't
> connect using figure.canvas.mpl_connect() (it doesn't like the names
> 'xlim_changed' and 'ylim_changed'), but rather you use
> Axes.callbacks.connect(). Also, the an event object is not passed into the
> callback, but rather the originating axes instance. Are these events relics
> to the older version of event handling that haven't been moved to the
> present?
>
> Otherwise, should I add a special section to the event handling docs to
> handle these?
Thanks for the example -- you are right that this is a 'legacy' event
callback outside the regular event framework. So it doesn't really
belong in the event handling chapter but may merit a quick note there.
 Alternatively, we could rather easily draft up a special event
(NavigationEvent?) that *does* work in the regular event handling
framework. The quirk is that the events are handled at the canvas
level, so it would be difficult to register for a single axes, but one
could get a NavigationEvent if the limits of any of the axes in the
figure were updated, and use the inaxes attribute to process it. If
this, or some variant of it, seems like a good idea I'm happy to add
it.
JDH

Hi,
I am not expert in matplotlib, I use it to generate plots for a management
performance tool.
I have just upgraded this application from 0.98.3 to 0.98.5 and the upgrade
broke the application in 3 places:
 
1). In units.py, Registry.get_converter(): this method has been made
recursive in 0.98.5. The problem is that if x is a string then you get a
recursion error.
The cause is the 'iterable() function called in the line "if converter is
None and interable(x):" The interable() function is in cbook.py and it
actually tests to see if the object 'x' has a __len__() method. Call
iterable() on a string and it returns true.
Do " for thisx in x:" and you will always get the first character in the
string, which is.... a string!
My solution was to change iterable():
Def iterable(obj):
"""
Return true if *obj* is iterable
"""
try: obj.__iter__()
except AtributeError: return False
return True
 
this seems to have solved the problem.
 
2). Backend_svg.py._get_style(): in 0.98.3, stroke_width is a string and in
0.98.5 it is a float. I set the styles by reading attributes in an xml file
and so the strings worked. When I upgraded, I got 'float' type errors. My
opinion is that we might expect parametric polymorphism here. A stroke width
could be '1', 1 or 1.0 all of which are legitimate parameters. Hence, when
we set the kwarg 'lw' on 'plot', a string, int or float should be legal.
Just my opinion.
 
3). Font_manager.createFontDict() in 0.98.3 become createFontList() in
0.98.5. I didn't find this change in Changes, but maybe I'm blind. What I
am saying here is that if I upgrade to 0.98.5 from 0.98.3, I would expect
0.98.5 to be less 'broke' than 0.98.3, not different.
 
I hope this is somehow helpful.
 
Best regards, Richard Jennings

Kaushik Ghose <Kau...@hm...> writes:
> In [2]: pylab.arange(0.5,1.0,.1)
> Out[2]: array([ 0.5, 0.6, 0.7, 0.8, 0.9]) <---- OK
>
> In [3]: pylab.arange(0.5,1.1,.1)
> Out[3]: array([ 0.5, 0.6, 0.7, 0.8, 0.9, 1. , 1.1]) <----- Not OK
The "bug" is really in numpy, which is where pylab imports arange from,
but even then it's not exactly a bug but a feature of floating-point
numerics (.1 is not exactly representable in binary floating-point, so
the equality comparison done by arange doesn't make much sense). Use
linspace if you know how many values you want:
In [4]: linspace(0.5,1.0,num=5,endpoint=False)
Out[4]: array([ 0.5, 0.6, 0.7, 0.8, 0.9])
In [5]: linspace(0.5,1.1,num=6,endpoint=False)
Out[5]: array([ 0.5, 0.6, 0.7, 0.8, 0.9, 1. ])
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
I'm using matplotlib 0.98.5.2 on mac os X.
I get the following behavior with arange that I think is not right
In [1]: import pylab
In [2]: pylab.arange(0.5,1.0,.1)
Out[2]: array([ 0.5, 0.6, 0.7, 0.8, 0.9]) <---- OK
In [3]: pylab.arange(0.5,1.1,.1)
Out[3]: array([ 0.5, 0.6, 0.7, 0.8, 0.9, 1. , 1.1]) <----- Not OK
Thanks
-Kaushik