matplotlib-users Mailing List for matplotlib (Page 6)

>>>>> "Eli" == Eli Glaser <eg...@se...> writes:
 Eli> Hello, I was wondering if there is any way to do a horizontal
 Eli> bar chart using Matplotlib? Any responses would be greatly
 Eli> appreciated.
Not currently. Implementing matlab's 'barh' is left as an exercise to
the reader :-)
Kidding aside, this would be very easy to implement following the
example of 'bar' and would be a nice addition. Submissions welcome!
JDH
The matlab barh doc string
>> help barh
 
 BARH Horizontal bar graph.
 BARH(X,Y) draws the columns of the M-by-N matrix Y as M groups of
 N horizontal bars. The vector X must be monotonically increasing
 or decreasing.
 
 BARH(Y) uses the default value of X=1:M. For vector inputs,
 BARH(X,Y) or BARH(Y) draws LENGTH(Y) bars. The colors are set by
 the colormap.
 
 BARH(X,Y,WIDTH) or BARH(Y,WIDTH) specifies the width of the
 bars. Values of WIDTH > 1, produce overlapped bars. The
 default value is WIDTH=0.8.
 
 BARH(...,'grouped') produces the default vertical grouped bar chart.
 BARH(...,'stacked') produces a vertical stacked bar chart.
 BARH(...,LINESPEC) uses the line color specified (one of 'rgbymckw').
 
 H = BARH(...) returns a vector of patch handles.
 
 Use SHADING FACETED to put edges on the bars. Use SHADING FLAT to
 turn them off.
 
 Examples: subplot(3,1,1), barh(rand(10,5),'stacked'), colormap(cool)
 subplot(3,1,2), barh(0:.25:1,rand(5),1)
 subplot(3,1,3), barh(rand(2,3),.75,'grouped')
 
 See also PLOT, BAR, BAR3H.
 

Having a problem with the WX backend; details follow.
I have wxPython 2.5 and matplotlib-0.60.2.win32-py2.3
installed.
My code snippet:
import matplotlib
matplotlib.use("WXAgg")
from matplotlib.matlab import *
Error msg:
Matplotlib backend_wx requires wxPython be installed
Code snippet from:
C:\Python23\Lib\site-packages\matplotlib\backends\backend_wx.py
try:
 from wxPython.wx import *
except:
 print >>sys.stderr, "Matplotlib backend_wx
requires wxPython be installed"
 sys.exit() 
I receive the following traceback when I try to invoke
this from the command line:
Enthought Edition build 1057
Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> from wxPython.wx import *
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File
"C:\Python23\lib\site-packages\wxPython\__init__.py",
line 10, in ?
 import _wx
 File
"C:\Python23\Lib\site-packages\wxPython\_wx.py", line
3, in ?
 from core import *
 File
"C:\Python23\Lib\site-packages\wxPython\core.py", line
15, in ?
 import wx.core
 File "C:\Python23\lib\site-packages\wxPython\wx.py",
line 4, in ?
 from misc import *
 File
"C:\Python23\lib\site-packages\wxPython\misc.py", line
15, in ?
 import wx.misc
 File "C:\Python23\lib\site-packages\wxPython\wx.py",
line 6, in ?
 from misc2 import *
 File
"C:\Python23\lib\site-packages\wxPython\misc2.py",
line 4, in ?
 from windows import *
 File
"C:\Python23\lib\site-packages\wxPython\windows.py",
line 15, in ?
 import wx.windows
 File "C:\Python23\lib\site-packages\wxPython\wx.py",
line 10, in ?
 from gdi import *
 File
"C:\Python23\lib\site-packages\wxPython\gdi.py", line
15, in ?
 import wx.gdi
 File "C:\Python23\lib\site-packages\wxPython\wx.py",
line 12, in ?
 from fonts import *
 File
"C:\Python23\lib\site-packages\wxPython\fonts.py",
line 120, in ?
 class wxFontPtr(wxObjectPtr):
NameError: name 'wxObjectPtr' is not defined
code snippet from:
C:\Python23\Lib\site-packages\wxPython\fonts.py
class wxFontPtr(wxObjectPtr):
This doesn't seem to be a problem specific to
matplotlib. But, I'm wondering if anyone has
already solved this or I'm just missing something.
Thanks.
Barry Drake

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> After upgrading to Matplotlib 0.61, I am getting the
 Darren> following error: Unable to load image-loading module:
 Darren> C:\Program Files\Common
 Darren> Files\GTK2円.0/lib/gtk-2.0/2.2.0/loaders/svg_loader.dll
 Darren> The path is correct, the file exists, I wonder if the
 Darren> mixed path seperators is causing trouble? I cant find the
 Darren> location of this exception in matplotlib to look into it,
 Darren> where should I look?
I'm note getting this error. My guess is that it is coming from the
final lines of backend_gtk.py
# set icon used when windows are minimized
if gtk.pygtk_version >= (2,2,0):
 basedir = matplotlib.rcParams['datapath']
 fname = os.path.join(basedir, 'matplotlib.svg')
 try: gtk.window_set_default_icon_from_file (fname)
 except gobject.GError, exc: print >>sys.stderr, exc
My win32 pygtk is older than 2.2.0 which may be why I am not seeing it.
Would you mind seeing if this is indeed the problem (for starters,
just replace the conditional with 'if 0:'. If you get any more
insight into the problem, be sure and let me know!
Also, Steve, we might be better off here catching *all* exceptions
rather than just the gobject error. Darren, would you test to see if
this works
# set icon used when windows are minimized
if gtk.pygtk_version >= (2,2,0):
 basedir = matplotlib.rcParams['datapath']
 fname = os.path.join(basedir, 'matplotlib.svg')
 try: gtk.window_set_default_icon_from_file (fname)
 except: print >>sys.stderr, 'Could not load matplotlib icon'
FYI
C:\Program Files\Common Files\GTK2円.0 # looks like the default registry path
/lib/gtk-2.0/2.2.0/loaders/svg_loader.dll # looks like a path from pkgconfig
JDH

After upgrading to Matplotlib 0.61, I am getting the following error:
Unable to load image-loading module: C:\Program Files\Common 
Files\GTK2円.0/lib/gtk-2.0/2.2.0/loaders/svg_loader.dll
The path is correct, the file exists, I wonder if the mixed path 
seperators is causing trouble? I cant find the location of this 
exception in matplotlib to look into it, where should I look?

Hello,
I was wondering if there is any way to do a horizontal bar chart using =
Matplotlib? Any responses would=20
be greatly appreciated.
Thanks,
Eli

Hi:
Below is a little part of my post from a while ago regarding x-axis 
scaling on plot_date plots.
>
> 2) The auto-scaling in plot_date() does not scale properly in some 
> special cases. Consider this:
>
> -----------------
> from matplotlib.matlab import *
>
> time2= [
> 1087321489.89, 1087321500.0,
> 1087321789.89, 1087321800.0, 1087322089.89, 1087322100.0, 
> 1087322389.89, 1087322700.0, 1087322989.89,
> 1087323000.0, 1087323289.89, 1087323300.0, 1087323589.89, 
> 1087323600.0, 1087323889.89, 1087323900.0,
> 1087324189.89, 1087324200.0, 1087324489.89, 1087324500.0, ]
> data2=[ 3.02,
> 3.02,
> 3.14,
> 3.14,
> 3.21,
> 3.21,
> 3.26,
> 3.26,
> 3.39,
> 3.39,
> 3.51,
> 3.51,
> 3.58,
> 3.58,
> 3.75,
> 3.75,
> 4.0,
> 4.0,
> 4.22,
> 4.22,]
>
> plot_date(time2, data2, None, '-', color='b')
> xlabel('time')
> grid(True)
>
> show()
> ---------------
>
> The same thing happens over differnt ranges when the amount of ticks 
> is large. Perhaps you may use something similar to the code below
> (from axes.py) to deal with these things. Note the ceilings get rid of 
> the AssertErrors in ticks.Base when int() gives zero. Also, to 
> finalize this,
> one would have to write a DayMultiLocator type class for the Weeks, 
> otherwise when the number of weeks is close, but less then the number
> of weeks in numticks*months it will get crowded. This will probably be 
> a little more involved than dealing with days, but perhaps one could use
> your existent WeekdayLocator class to simplify the problem.
I added a quick and dirty version of this WeekMultiLocator that handles 
cases when the time range is many weeks but less than 5 months (say 17 
weeks) and the ticks get over-crowded. Ideally one could have the weeks 
always start on some particular day - say Monday, but for me it doesnt 
really matter, and with the simple code below, thing seem to come out 
quite nice.
In axes.py need:
Line ~19:
from ticker import YearLocator, MonthLocator, WeekdayLocator, \
 DayLocator, HourLocator, MinuteLocator, DateFormatter, 
DayMultiLocator, WeekMultiLocator
Line ~1475:
 def plot_date(self, d, y, converter, fmt='bo', **kwargs):
 """
 plot_date(d, y, converter, fmt='bo', **kwargs)
 d is a sequence of dates; converter is a dates.DateConverter
 instance that converts your dates to seconds since the epoch for
 plotting. y are the y values at those dates. fmt is a plot
 format string. kwargs are passed on to plot. See plot for more
 information.
 pass converter = None if your dates are already in epoch format
 """
 if not self._hold: self.cla()
 if converter is not None:
 e = array([converter.epoch(thisd) for thisd in d])
 else:
 e = d
 
 assert(len(e))
 ret = self.plot(e, y, fmt, **kwargs)
 span = self.dataLim.intervalx().span()
 if span==0: span = SEC_PER_HOUR
 minutes = span/SEC_PER_MIN
 hours = span/SEC_PER_HOUR
 days = span/SEC_PER_DAY
 weeks = span/SEC_PER_WEEK
 months = span/(SEC_PER_DAY*31) # approx 
 years = span/(SEC_PER_WEEK*52) # approx
 numticks = 5
 if years>numticks:
 locator = YearLocator(math.ceil(years/numticks)) 
 fmt = '%Y'
 elif months>numticks:
 locator = MonthLocator(math.ceil(months/numticks)) 
 fmt = '%b %Y'
 elif weeks>numticks:
 locator = WeekMultiLocator(math.ceil(weeks/numticks))
 fmt = '%a, %b %d'
 elif days>numticks:
 locator = DayMultiLocator(math.ceil(days/numticks))
 fmt = '%b %d'
 elif hours>numticks:
 locator = HourLocator(math.ceil(hours/numticks))
 fmt = '%H:%M\n%b %d'
 elif minutes>numticks:
 locator = MinuteLocator(math.ceil(minutes/numticks))
 fmt = '%H:%M:%S'
 else:
 locator = MinuteLocator(1)
 fmt = '%H:%M:%S'
 formatter = DateFormatter(fmt)
 self.xaxis.set_major_locator(locator)
 self.xaxis.set_major_formatter(formatter)
 self.autoscale_view()
 return ret
In ticks.py:
Need to add:
class WeekMultiLocator(MultipleLocator):
 """
 Make ticks on day which are multiples of base
 """
 def __init__(self, base):
 MultipleLocator.__init__(self, base*SEC_PER_WEEK)
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

> Stephen> However, in either case, the bars' left edge is at the x
> Stephen> coordinate rather than being centered on it. I know this
> Stephen> is the documented behavior, but Matlab centers the bars
> Stephen> on the given X coordinates. How do people feel about
> Stephen> changing matplotlib to match the Matlab behavior? I've
> Stephen> changed my copy locally.
> 
> Hi Stephen,
> I'd be happy with this change. I CCd Gary Ruben who has done a lot of
> work on the bar function because he'll likely have an opinion.
Hi John,
Since you ask, the proposed change makes perfect sense to me.
Oh, and you're definitely overstating the changes I've done on barplots which was limited to tinkering with the errorbar part.
Gary
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

>>>>> "Richard" == Richard Taylor <rt...@ec...> writes:
 Richard> I recently upgraded to the binary for Windows version
 Richard> 0.60.2 and found that the plus (+) symbol always plots in
 Richard> black even though a color is specified. My fix was to
 Richard> change the parameter lines.markeredgecolor to the color I
 Richard> wanted using the rc() command and then to revert to the
 Richard> default using rcdefaults(). This works ok for me but I
 Richard> thought you might want to know in case it's a bug.
Yes, this is a bug, sort of. '+' is a marker. In the current
matplotlib, the colorarg only sets the marker face color but not the
edge color. For circles and the like, this is normally not a
problem. But for '+' it makes no sense.
In the next release, color args will affect both the edge and face
colors, and you can override this by providing a kwarg, eg
 >>> plot(range(10), 'r+') # red plusses
 >>> plot(range(10), 'ro') # red circles, edge and face
 >>> plot(range(10), 'ro', markeredgecolor='k') # red face, black edge
Thanks for letting me know.
JDH

I recently upgraded to the binary for Windows version 0.60.2 and found that
the plus (+) symbol always plots in black even though a color is specified.
My fix was to change the parameter lines.markeredgecolor to the color I
wanted using the rc() command and then to revert to the default using
rcdefaults(). This works ok for me but I thought you might want to know in
case it's a bug.
 
Regards,
Rich

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> However, in either case, the bars' left edge is at the x
 Stephen> coordinate rather than being centered on it. I know this
 Stephen> is the documented behavior, but Matlab centers the bars
 Stephen> on the given X coordinates. How do people feel about
 Stephen> changing matplotlib to match the Matlab behavior? I've
 Stephen> changed my copy locally.
Hi Stephen,
I'd be happy with this change. I CCd Gary Ruben who has done a lot of
work on the bar function because he'll likely have an opinion.
If you could send me your code, I'll look into merging it if all
agree this is the desired behavior.
JDH

Personally, I agree with Stephen that "center the bar on the given x value" is 
more user friendly.
JC Hsu

On Thu, 2004年08月05日 at 10:00, John Hunter wrote:
> >>>>> "Jin-chung" =3D=3D Jin-chung Hsu <hs...@st...> writes:
>=20
> Jin-chung> When I do the bar(left, height) in matlab the first
> Jin-chung> time, e.g.:
> >>>> bar([4,5,6,7,8],[9,8,7,6,5])
>=20
> This was a bug in the way I update the datalim in axes.py, which is
> currently a bit too fragile for my tastes. Below I'll include the
> modified matplotlib.axes.Axes.bar function. Let me know if it passes
> all your tests...
I was interested in this report, and sorry if I butted in. John's patch
fixes Jin-chung's problem with poor x-axis scaling here. I'm using CVS,
not 0.60.2, and didn't see the "funny Y tick labels" he reported.
However, in either case, the bars' left edge is at the x coordinate
rather than being centered on it. I know this is the documented
behavior, but Matlab centers the bars on the given X coordinates. How
do people feel about changing matplotlib to match the Matlab behavior?=20
I've changed my copy locally.
--=20
Stephen Walton <ste...@cs...>
Dept. of Physics & Astronomy, Cal State Northridge

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:
 Jin-chung> When I do the bar(left, height) in matlab the first
 Jin-chung> time, e.g.:
 >>>> bar([4,5,6,7,8],[9,8,7,6,5])
Hi, thanks for the report.
This was a bug in the way I update the datalim in axes.py, which is
currently a bit too fragile for my tastes. Below I'll include the
modified matplotlib.axes.Axes.bar function. Let me know if it passes
all your tests...
Cheers,
JDH
 def bar(self, left, height, width=0.8, bottom=0,
 color='b', yerr=None, xerr=None, ecolor='k', capsize=3
 ):
 """
 BAR(left, height)
 
 Make a bar plot with rectangles at
 left, left+width, 0, height
 left and height are Numeric arrays
 Return value is a list of Rectangle patch instances
 BAR(left, height, width, bottom,
 color, yerr, xerr, capsize, yoff)
 xerr and yerr, if not None, will be used to generate errorbars
 on the bar chart
 color specifies the color of the bar
 ecolor specifies the color of any errorbar
 capsize determines the length in points of the error bar caps
 
 The optional arguments color, width and bottom can be either
 scalars or len(x) sequences
 This enables you to use bar as the basis for stacked bar
 charts, or candlestick plots
 """
 if not self._hold: self.cla()
 
 left = asarray(left)
 height = asarray(height)
 patches = []
 # if color looks like a color string, and RGB tuple or a
 # scalar, then repeat it by len(x)
 if (is_string_like(color) or
 (iterable(color) and len(color)==3 and len(left)!=3) or
 not iterable(color)):
 color = [color]*len(left)
 if not iterable(bottom):
 bottom = array([bottom]*len(left), Float)
 else:
 bottom = asarray(bottom)
 if not iterable(width):
 width = array([width]*len(left), Float)
 else:
 width = asarray(width)
 N = len(left)
 assert len(bottom)==N, 'bar arg bottom must be len(left)'
 assert len(width)==N, 'bar arg width must be len(left) or scalar'
 assert len(height)==N, 'bar arg height must be len(left) or scalar'
 assert len(color)==N, 'bar arg color must be len(left) or scalar'
 right = left + width
 top = bottom + height
 
 args = zip(left, bottom, width, height, color)
 for l, b, w, h, c in args: 
 if h<0:
 b += h
 h = abs(h)
 r = Rectangle(
 xy=(l, b), width=w, height=h,
 facecolor=c,
 )
 self.add_patch(r)
 patches.append(r)
 
 if xerr is not None or yerr is not None:
 self.errorbar(
 left+0.5*width, bottom+height,
 yerr=yerr, xerr=xerr,
 fmt=None, ecolor=ecolor, capsize=capsize)
 self.autoscale_view()
 return patches

When I do the bar(left, height) in matlab the first time, e.g.:
>>> bar([4,5,6,7,8],[9,8,7,6,5])
the plot does not have the "full" range : X starts at 4.5 (should be 4) and Y 
starts at 5 (shouldbe 0). But if I reissue the same command without erasing the 
plot, the plot range is fine, but the Y tick labels are funny (3 and 9 seem to 
be at 2.5 and 8.5).
I also notice that if I use yerr:
>>> bar([4,5,6,7,8],[9,8,7,6,5],yerr=[1,.5,.5,.9,1])
The plot is fine the first time, both the range and the tick labels.
I am using matplotlib 0.60.1 on Solaris.
JC Hsu

Hi John:
DayMulitLocator is missing from the following line:
from ticker import YearLocator, MonthLocator, WeekdayLocator, \
 DayLocator, HourLocator, MinuteLocator, DateFormatter
in axes.py
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

John Hunter wrote:
>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>> 
>>>>>>
>
> Peter> Yes, thanks. Just one more question. Recently (in the last
> Peter> couple of versions I think), there has been a change and
> Peter> now the 'o' line markers (circles) are filled in by
> Peter> default. For example:
>
> Peter> plot(xp,yp,'ok')
>
> Peter> gives sold black circles.
>
>Just do
>
> >>> plot(x, y, 'ok', markerfacecolor=None)
>
> 
>
Aghh.. yes. Thanks.
>This raises the question of what the default behavior of plot should
>be. If you say
>
> >>> plot(x, y, 'ro')
>
>should the red apply to the facecolor, edgecolor, or both? 
>
I think both is good. It seems like it's really easy to change in any case.
>I could add some aliases like mfc=markerfacecolor, ec=edgecolor,
>lw=linewidth if people often find themselves overriding the defaults
>and think these are useful shortcuts. 
>
Might be a good idea.
On another note, interesting to see how much matplotlib has matured in 
the last six months. Great job John!
Peter

>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:
 Vineet> That's fine. I'll start using
 Vineet> ax.viewLim.intervaly().get_bounds() # the y limits
 Vineet> to get the y limits.
Hi Vineet,
This is not recommended. I pointed you to limit attributes these so
you can compare what is happening with the data and view limits
separately, and to give you some insight into how to poke around if
you need to. There is no reason for you to call
ax.viewLim.intervaly().get_bounds() since this is what get_ylim calls
anyway. The set_ylim and get_ylim functions are fixed as part of the
matlab API; The viewLim and dataLim attributes are not. When
possible, stick with the documented API, so your code will be
compatible with future matplotlib releases.
 Vineet> In any case though, the order in which the plot functions
 Vineet> are called should not change the value returned by
 Vineet> self.axMiddle.get_ylim. I think that is a bug.
There may be a bug, but let's be clear to find out. Here is what is
happening.
Every time you issue a plot command, the ax.dataLim are updated.
These should exactly bound the min and max of the x and y range of
your data. After that, ax.autoscale_view is called. This updates the
min and max of the x and y *view* limits, which should include, but
may exceed, the datalim. Exactly how this view limit update is done
depends on the tick locator you have chosen. The default locator is
matplotlib.ticker.AutoLocator, but you can customize this.
if you issue repeated plot commands
 ax.plot(something)
 ax.plot(something_else)
 ax.plot(still_mode)
 print 'datalim', ax.dataLim.intervaly().get_bounds() 
 print 'viewlim', ax.get_ylim() 
neither the viewlim nor the datalim after all plot commands have been
issued should not be affected by the order of the plot commands. Of
course, you need to apply the patch I posted in my previous email (to
the has_data function) because there was a bug. 
The viewlim *will* be changed after each plot command, and will depend
on the order, as in
 ax.plot(something)
 print 'viewlim', ax.get_ylim() 
 ax.plot(something_else)
 print 'viewlim', ax.get_ylim() 
 ax.plot(still_mode)
 print 'viewlim', ax.get_ylim() 
but again, the final viewlim should be order independent. Is this
what you observe?
If the plot order does affect the final limits, let me know. If the
viewlim differs from the data lim, that is unsurprising, as that is by
design. If you are unhappy with the way to the autolocator is
choosing the view limits, you have a couple of choices: 1) let me know
by giving me the requisite datalim and viewlim boundaries, what is
happening, and what you think should be happening and I'll look in to
fixing it or 2) use a custom locator that autoscales the view limits
in the way you want.
JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
 Peter> Yes, thanks. Just one more question. Recently (in the last
 Peter> couple of versions I think), there has been a change and
 Peter> now the 'o' line markers (circles) are filled in by
 Peter> default. For example:
 Peter> plot(xp,yp,'ok')
 Peter> gives sold black circles.
Just do
 >>> plot(x, y, 'ok', markerfacecolor=None)
This raises the question of what the default behavior of plot should
be. If you say
 >>> plot(x, y, 'ro')
should the red apply to the facecolor, edgecolor, or both? Both is
the current behavior, which I think is in accord with the principal of
least surprise. If it should apply to only one, say the edge color,
the facecolor would fall back on lines.markerfacecolor.
I could add some aliases like mfc=markerfacecolor, ec=edgecolor,
lw=linewidth if people often find themselves overriding the defaults
and think these are useful shortcuts. I've already added these to the
rc command, and adding them to the lines/patches classed would be
easy.
JDH

That's fine. I'll start using
	 ax.viewLim.intervaly().get_bounds() # the y limits
to get the y limits.
In any case though, the order in which the plot functions are called should
not change the value returned by self.axMiddle.get_ylim. I think that is a
bug.
VJ
-----Original Message-----
From: mat...@li...
[mailto:mat...@li...]On Behalf Of John
Hunter
Sent: Monday, August 02, 2004 10:56 AM
To: Vineet Jain
Cc: matplotlib-users
Subject: Re: [Matplotlib-users] Settling y-axis scaling
>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:
 Vineet> After making changes to has_data I get the following:
 Vineet> (0.0, 400.0) (0.0, 400.0) (0.0, 400.0)
 Vineet> which is not correct it should be:
 Vineet> (300.0, 400.0) (100.0, 400.0) (100.0, 400.0)
I'm not sure this is incorrect. matplotlib distinguishes between the
data limits and the view limits. The latter are automatically
adjusted to include the data limits but may incorporate more. For
example, the x data limits in [0.1, 10] may produce view limits
[0,10].
If you need the view limits to always equal the data limits, you could
provide a custom ticker, as described in
http://matplotlib.sourceforge.net/matplotlib.ticker.html and
illustrated in the example
http://matplotlib.sourceforge.net/examples/custom_ticker1.py.
You might want to verify that the data limits are correct by printing
 ax.dataLim.intervalx().get_bounds() # the x limits
 ax.dataLim.intervaly().get_bounds() # the y limits
where ax is your Axes instance. You can compare these with
 ax.viewLim.intervalx().get_bounds() # the x limits
 ax.viewLim.intervaly().get_bounds() # the y limits
JDH
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

> .....
> But you can also create your own color maps at any time using the
> cm.get_cmap function
>
> >>> jet512 = cm.get_cmap('jet', 512)
> >> imshow(X, cmap=jet512)
>
> Should work.
>
Yes, thanks.
Just one more question. Recently (in the last couple of versions I 
think), there has been a change and now the 'o' line markers (circles) 
are filled in by default.
For example:
 plot(xp,yp,'ok')
gives sold black circles.
I would like my circles to not be filled; just have the border so that 
the inside is transparent.
Is this something that is settable?
Thanks,
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:
 Vineet> After making changes to has_data I get the following:
 Vineet> (0.0, 400.0) (0.0, 400.0) (0.0, 400.0)
 Vineet> which is not correct it should be:
 Vineet> (300.0, 400.0) (100.0, 400.0) (100.0, 400.0)
I'm not sure this is incorrect. matplotlib distinguishes between the
data limits and the view limits. The latter are automatically
adjusted to include the data limits but may incorporate more. For
example, the x data limits in [0.1, 10] may produce view limits
[0,10].
If you need the view limits to always equal the data limits, you could
provide a custom ticker, as described in
http://matplotlib.sourceforge.net/matplotlib.ticker.html and
illustrated in the example
http://matplotlib.sourceforge.net/examples/custom_ticker1.py.
You might want to verify that the data limits are correct by printing
 ax.dataLim.intervalx().get_bounds() # the x limits
 ax.dataLim.intervaly().get_bounds() # the y limits
where ax is your Axes instance. You can compare these with
 ax.viewLim.intervalx().get_bounds() # the x limits
 ax.viewLim.intervaly().get_bounds() # the y limits
JDH

>>>>> "Kenneth" == Kenneth McDonald <ken...@sb...> writes:
 Kenneth> Does any exist? I looked through the distribution and
 Kenneth> didn't see anything, but then, that doesn't prove
 Kenneth> anything :-)
There is no official documentation, but there are a few resources
 * The class documentation at
 http://matplotlib.sourceforge.net/classdocs.html
 * the examples embedding_in*.py in the examples directory.
 * examples/pythonic_matplotlib.py describes the translation from the
 matlab style interface to the pythonic, OO interface
 * Another good resource is matlab.py. This is just a thin wrapper
 to the API, so you can look and see how it is done there,
 translating all the gcf() calls to your figure instance, all the
 gca() calls to your axes instance, and so on.
Other than that, you can post here...
I'm working on some additional documentation but it is not ready yet.
JDH

>>>>> "Mathias" == Mathias Franzius <mat...@we...> writes:
 Mathias> Dear NG, I have a problem mwith the installation of
 Mathias> matplotlib under redhat 9 and python 2.3.2. I first
 Mathias> updated all relevant packages (see [1]). Building
 Mathias> matplotlib with default setup.py seemd to be ok, except
 Mathias> two types of warnings (see [2]). Install showed no errors
 Mathias> as well. When importing matplotlib I get the following
 Mathias> error:
The warnings you posted are completely harmless. 
 Mathias> What could be the problem? The directory
 Mathias> /usr/lib/python2.3/site-packages/matplotlib/ contains
 Mathias> transforms.py and _transforms.so but no _transforms.py -
 Mathias> is that ok?
Yes, this is OK. There is no _transforms.py
My guess is you are trying to run matplotlib from the build dir. You
cannot do this, because python finds the matplotlib src dir named
matplotlib and tries to load that. There is no _transforms module in
that dir, but there is in site-packages so you should be OK. cd into
another directory, ie your home dir or the examples dir, and try from
there.
This problem bites a number of users. Perhaps we should rename the
base matplotlib python dir in the src tree to something like
matplotlibpy.
JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
 Peter> Hi: How many colors do images created via:
 Peter> imshow(Zi, cmap=cm.jet)
 Peter> (Zi = some data matrix) have?
 Peter> Are these true color? 256? Is there a simple way to define
 Peter> these things?
The following image parameters can be configured from your rc file
### images
image.aspect : free # free | preserve
image.interpolation : bilinear # see help(imshow) for options
image.cmap : jet # gray | jet
image.lut : 256 # the size of the colormap lookup table
image.origin : upper # lower | upper
The image.lut parameter controls the size of the lookup table. You
can change the default in the rc file, or dynamically in a single
python session using the rc function. Eg,
 # default cmap is now 100 level grayscale by cm.jet and cm.gray unaffected
 >>> rc('image', lut=100, cmap='gray')
 >>> imshow(X) # show X with default cmap
But you can also create your own color maps at any time using the
cm.get_cmap function
 >>> jet512 = cm.get_cmap('jet', 512)
 >> imshow(X, cmap=jet512)
Should work.
JDH

Dear NG,
I have a problem mwith the installation of matplotlib under redhat 9 and 
python 2.3.2. I first updated all relevant packages (see [1]).
Building matplotlib with default setup.py seemd to be ok, except two 
types of warnings (see [2]). Install showed no errors as well.
When importing matplotlib I get the following error:
 >>> from matplotlib import matlab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "matplotlib/matlab.py", line 142, in ?
 from axes import Axes
 File "matplotlib/axes.py", line 9, in ?
 from artist import Artist
 File "matplotlib/artist.py", line 4, in ?
 from transforms import identity_transform
 File "matplotlib/transforms.py", line 180, in ?
 from _transforms import Value, Point, Bbox, Affine
ImportError: No module named _transforms
What could be the problem?
The directory /usr/lib/python2.3/site-packages/matplotlib/
contains transforms.py and _transforms.so but no _transforms.py - is 
that ok?
Thanks for any help,
 Mathias
--------
[1]: zlib, zlib-devel, libpng, libpng-devel, freetype, freetype-devel, 
freetype-utils, gtk2-devel, gtk+-devel, pygtk2, glib-devel, 
pygtk2-devel, gnome-libs-devel, pygtk2-libglade,
tcl, tk, tkinter
[2]: In file included from /usr/include/python2.3/Python.h:8,
 from CXX/Objects.hxx:9,
 from CXX/Extensions.hxx:18,
 from src/_transforms.h:10,
 from src/_transforms.cpp:2:
/usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from 
/usr/include/c++/3.2.2/i386-redhat-linux/bits/os_defines.h:39,
 from 
/usr/include/c++/3.2.2/i386-redhat-linux/bits/c++config.h:34,
 from /usr/include/c++/3.2.2/functional:53,
 from src/_transforms.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the 
previous definition