matplotlib-devel Mailing List for matplotlib

The old "classic" toolbar is out of sync with some API updates.
This is what I get when running embedding_in_gtk2.py (after tweaking to use 
the classic toolbar)
Traceback (most recent call last):
 File "embedding_in_gtk2.py", line 39, in <module>
 toolbar = NavigationToolbar(canvas, win)
 File "c:\python25\lib\site-packages\matplotlib\backends\backend_gtk.py", 
line
746, in __init__
 default_type=self.canvas.get_default_filetype())
TypeError: __init__() got an unexpected keyword argument 'default_type'
and the diffs, after what seemed like the appropriate fixing:
for 0.91.2
0 % diff be_gtk_912.py be_gtk_912-fixd.py
738,739c738,739
< formats=self.canvas.get_supported_filetypes(),
< default_type=self.canvas.get_default_filetype())
---
> filetypes=self.canvas.get_supported_filetypes(),
> default_filetype=self.canvas.get_default_filetype())
for 0.98.0
0 % diff be_gtk_980.py be_gtk_980-fixd.py
745,746c745,746
< formats=self.canvas.get_supported_filetypes(),
< default_type=self.canvas.get_default_filetype())
---
> filetypes=self.canvas.get_supported_filetypes(),
> default_filetype=self.canvas.get_default_filetype())
Cheers
Chris Fuller
University of Minnesota

I was able to fix this without too much trouble, so I have committed it 
on the trunk.
Cheers,
Mike
Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> I see that this isn't a LaTeX error, but I think Tony's comment is 
>> still somewhat valid. Since mathtext's parser is a direct subset of 
>> LaTeX's, and since $$ is a syntax error in LaTeX, it also is in 
>> mathtext. (This is really a side effect of make such a direct copy 
>> of the parser, rather than a deliberate choice). We can probably add 
>> a workaround to the parser, but I personally don't have a problem 
>> with it raising an exception. It doesn't seem to be a very useful 
>> thing to be able to do. What's your use case?
>>
>
> There is an exception for $ $ which is valid LaTeX. I have no 
> particular usecase, I was just surprised by the exception. However I 
> imagine that there could be instances when you want to interpolate an 
> expression into a string but sometimes leave it empty, not that 
> compelling perhaps.
>
> /Jörgen
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Jun 4, 2008 at 12:01 PM, Ted Drain <ted...@jp...> wrote:
> Sorry - I don't think I was very clear in my email. Try this:
>
> import pylab as p
> p.plot( [] ()
> p.gca().xaxis_date()
> p.show()
I did understand that in your first post, but I was focusing more on
your comments about a better date class than this specific bug, but I
see how the a better class would solve this bug too. But we can work
around this -- I committed some changes to the branch and trunk which
checks to see if the datalim have been updated on the call to xaxis
date and if not it will choose a valid default date range for the date
and view lim, but leave the "ignore" setting in place so it won't
affect the autoscaling when you actually do add data. Hit it with
your standard battery of tests and let me know how it works.
Michael, in the process of adding support for this, I added a check to
the Axes.update_datalim to ignore empty lists
 def update_datalim(self, xys):
 if len(xys): return
but when I ran backend driver, I found a bug on contour_demo.py where
a non-iterable was being passed in for xys. I added a debug print
statement to update_datalim to print type(xys), and here is what I
got, along with the traceback
johnh@flag:svn> python ~/mpl/examples/pylab_examples/contour_demo.py
<type 'list'>
<type 'list'>
<type 'list'>
<type 'list'>
<type 'tuple'>
<type 'list'>
<type 'numpy.ndarray'>
<class 'matplotlib.transforms.Bbox'>
Traceback (most recent call last):
 File "/home/titan/johnh/mpl/examples/pylab_examples/contour_demo.py",
line 83, in ?
 CB = colorbar(CS, shrink=0.8, extend='both')
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 1179, in colorbar
 ret = gcf().colorbar(mappable, cax = cax, ax=ax, **kw)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 965, in colorbar
 cb = cbar.Colorbar(cax, mappable, **kw)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colorbar.py",
line 591, in __init__
 self.add_lines(CS)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colorbar.py",
line 612, in add_lines
 ColorbarBase.add_lines(self, CS.levels, tcolors, tlinewidths)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/colorbar.py",
line 329, in add_lines
 self.ax.add_collection(col)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py",
line 1242, in add_collection
 self.update_datalim(collection.get_datalim(self.transData))
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/axes.py",
line 1313, in update_datalim
 if not len(xys): return
TypeError: len() of unsized object
So the collection.get_datalim is returning a transformed bbox and
passing this off to update_datalim. This is easy to work around by
adding an iterable(xys) check, which I did on the branch and the
trunk, but to be sure I am not masking a bug, I wanted to make sure
that this is what should be happening here. I would think we would
call update_datalim_bounds for a bbox....
Thanks,
JDH
JDH

Sorry - I don't think I was very clear in my email. Try this:
import pylab as p
p.plot( [] ()
p.gca().xaxis_date()
p.show()
While this is a silly example, we do a lot of embedding of plots in GUI's
and this does come up. Normal MPL mode is something like:
- get data
- plot data
- configure and format plot
But in an embedded GUI, it's much easier to write code like this:
- configure and format plot
- wait for data
- get data and plot
So we want to be able to create a plot widget and set all the options and
formatting we want to use on it. Then wait for data to arrive or be input
and plot it. The problem is that it turns out there are a lot of places
where autoscaling or other algorithms cause date formatting to fail w/ a
similar message about not being able to handle zero or negative numbers.
You can work around them if you know they're going to show up but it's
frustrating. It would be nice if date formatting could be applied to any
plot range and have it work.
I'll make some more concrete examples later - I think it's something we can
fix. I'd like to get a suite of examples that illustrate some of the
problems before I/we start thinking about possible solutions.
Ted
> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...] On Behalf Of
> John Hunter
> Sent: Tuesday, June 03, 2008 1:51 PM
> To: Ted Drain
> Cc: Matplotlib
> Subject: Re: [matplotlib-devel] date2num/num2date and ordinal date
> 
> On Tue, Jun 3, 2008 at 3:41 PM, Ted Drain <ted...@jp...>
> wrote:
> 
> > At some point in the future, I'll put a little test case together to
> show
> > how the problems w/ not supporting a zero date show up in embedded
> plots.
> 
> Actually, when you pass in python datetime objects to mpl, we use the
> units converter infrastructure to convert these under the hood using
> date2num. This is fairly easy to override in the units registry. If
> you provide a registry to do conversions, locators and formatters for
> julian dates, I can easily include it with an rc setting to make a
> configurable default.
> 
> The date interface is setup in the matplotlib.dates module with the
> following code -- all you have to do is provide a different converter
> and we can provide a hook
> 
> class DateConverter(units.ConversionInterface):
> 
> def axisinfo(unit):
> 'return the unit AxisInfo'
> if unit=='date':
> majloc = AutoDateLocator()
> majfmt = AutoDateFormatter(majloc)
> return units.AxisInfo(
> majloc = majloc,
> majfmt = majfmt,
> label='',
> )
> else: return None
> axisinfo = staticmethod(axisinfo)
> 
> def convert(value, unit):
> if units.ConversionInterface.is_numlike(value): return
> value
> return date2num(value)
> convert = staticmethod(convert)
> 
> def default_units(x):
> 'return the default unit for x or None'
> return 'date'
> default_units = staticmethod(default_units)
> 
> 
> units.registry[datetime.date] = DateConverter()
> units.registry[datetime.datetime] = DateConverter()
> 
> -----------------------------------------------------------------------
> --
> 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,
Some more thoughts about hist():
A "range" parameter should be added and used in histogram()
A new histogram should get a new colour, just like plot() does
The "step" type should default to fill=False
Actually, personally I hardly ever use bar histograms at all, so if 
step-mode (unfilled) was made default I wouldn't complain...
And not directly related to hist():
I think the pan/zoom tool should be on by default when a new figure opens. 
As it is now, we always need to press some button no matter what we want 
to do. pan/zoom is a good guess (at least for me)!
Thanks all developers for creating what has become my default plotting 
tool! I will never leave the python shell again.
(from kitchen import coffee)
Cheers,
Olle

I see that this isn't a LaTeX error, but I think Tony's comment is still 
somewhat valid. Since mathtext's parser is a direct subset of LaTeX's, 
and since $$ is a syntax error in LaTeX, it also is in mathtext. (This 
is really a side effect of make such a direct copy of the parser, rather 
than a deliberate choice). We can probably add a workaround to the 
parser, but I personally don't have a problem with it raising an 
exception. It doesn't seem to be a very useful thing to be able to do. 
What's your use case?
Cheers,
Mike
Jörgen Stenarson wrote:
> Tony Yu skrev:
> 
>> On Jun 3, 2008, at 4:18 PM, Jörgen Stenarson wrote:
>> 
>>> using an empty mathtext "$$" in labels generates an exception. See
>>> example and traceback below.
>>> 
>> My guess is that this is a LaTeX error. If you enter $$ in a normal 
>> LaTeX document, you will get:
>>
>>
>> 
> I don't think so. I'm using mathtext i.e. matplotlibs own latex 
> interpreter. And I get the same error with $$ $$.
>
> /Jörgen
>
> -------------------------------------------------------------------------
> 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

Hi,
On Tue, Jun 3, 2008 at 10:59 PM, Jeff Whitaker <js...@fa...> wrote:
>
> There are alternate versions num2date and a date2num in basemap that handle
> arbitrary calendars (not just 'proleptic gregorian') and arbitrary reference
> times (not just 'days since 0001年01月01日 00:00:00'). The docstrings are at
> http://matplotlib.sourceforge.net/mpl_toolkits.basemap.basemap.html, down
> near the bottom of the page.
>
> I don't know if this addresses the problem you're talking about though...
I agree with you Jeff: your version of date2num (and num2date)
perfectly does the job.
Maybe the 'units' argument should defaults to 'days since 0001年01月01日'
for backward compatibility.
And maybe, as for the DateConverter, the 'unit' argument in
axis_info() and convert() should follow the CF conventions
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.2/cf-conventions.html#time-coordinate)
as Jeff's functions, and default_units() should return 'days since
0001年01月01日'.
>
> -Jeff
>
> --
> Jeffrey S. Whitaker Phone : (303)497-6313
> Meteorologist FAX : (303)497-6449
> NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
> 325 Broadway Office : Skaggs Research Cntr 1D-113
> Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
>
>
-- 
Stephane Raynaud