matplotlib-users Mailing List for matplotlib

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> When I create a plot that is smaller than the figure window,
 Mark> the tickmark locator seems to locate the ticks based on the
 Mark> figure size, not the subplot size. I tried this several
 Mark> ways.
Hey Mark, this is a bug. I find the problem disappears when I force a
redraw by making a small change in figure size. Could you file a sf
bug report?
Thanks!
JDH

>>>>> "Vidar" == Vidar Gundersen <vid...@37...> writes:
 Vidar> can anyone explain this format to me?
 Vidar> _cool_data = {'red': ((0., 0., 0.), (1.0, 1.0, 1.0)),
 Vidar> 'green': ((0., 1., 1.), (1.0, 0., 0.)), 'blue': ((0., 1.,
 Vidar> 1.), (1.0, 1., 1.))}
Take a look at the help for the matplotlib.colors module at
http://matplotlib.sourceforge.net/matplotlib.colors.html, in
particular
 http://matplotlib.sourceforge.net/matplotlib.colors.html#LinearSegmentedColormap
 http://matplotlib.sourceforge.net/matplotlib.colors.html#-makeMappingArray
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> My preference is for 3 separate packages - matplotlib which
 Steve> depends on dateutils and pytz.
 Steve> I think the problem is caused by matplotlib itself. I don't
 Steve> think that matplotlib should repackage dateutils and pytz
 Steve> which are already independent packages. I understand that
 Steve> John included them initially in order to make matplotlib
 Steve> easier to download and install, which I understand. But now
 Steve> that matplotlib is being packaged for distributions it
 Steve> creates unnecessary extra work for the matplotlib
 Steve> packagers.
I agree the situation is not ideal, but it is not just pytz and
dateutil that we a re talking about. It is also agg, pyparsing and
pycxx. I think we would turn a number of people off if we said, first
install Numeric, pycxx, agg, pytz, pyparsing, dateutil, freeytpe, png
and zlib. The current approach tries to balance the likelihood that a
prereq is already on the system with the ease of installation of that
package (do packages for the various platforms already exist?) with my
desire to simplify the build configure process by controlling which
version matplotlib uses. agg, for example, is particularly vexing,
because Maxim frequently updates a given release (agg23 for example)
w/o changing the version number even when the updates break existing
code. In this case, it is not sufficient even to say "use agg23".
Also, we have to balance inconvenience of package developers with
inconvenience of users. Given a choice, I tend to inconvenience the
power users, because they are more able and willing to deal with it.
That said, I think there is a compromise solution which may satisfy
everyone. Following Chris Barker's suggestion, we can create a zip
file or tarball of matplotlib deps, which has the src of all of the
prereqs (except python and numerix) in it, and rewrite the setup to
have a proper configure, checking for each prereq and issuing a kind
error like "you are missing the freetype prereq, please install it or
download http://someserver.com/mpldeps.zip and unzip it in this dir.
This would keep the matplotlib distro (and CVS updates) as light as
possible while making it easier to compile mpl on OSX and some linux
distros. Of course, to do this right requires a fair amount of
effort, but I am all for it. I worked for a while trying to use the
distutils configure functionality (which can test for include headers,
libs and the like) but was unsuccessful. The question that stumped me
was how to properly communicate the results of the config process to
the build process. I posted this to c.l.python but got no answer:
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/97cbe06f5efa58c0/18a015cba8bf2bd0?q=author:jdh...@ac...+group:comp.lang.python+distutils&rnum=1&hl=en#18a015cba8bf2bd0
If anyone wants to work on this, I'll be happy to help. But the
setup/configure/build process is fairly elaborate since it involves
multiple dependencies and gui toolkits across platforms, which is why
I have been a bit reluctant to refactor it.
JDH

>>>>> "Vidar" == Vidar Gundersen <vid...@37...> writes:
 Vidar> axvline(x=0, color='black', ) 
 Vidar> axhline(y=0, color='black', )
 Vidar> neither does this: i want a dashed line.
This is the right approach, just add linestyle='--' to the kwargs.
Since you will be using identical kwargs for the hline and vline, you
may want to consider the following approach, which is equivalent but
puts the configuration in one place
 props = dict(color='black', linestyle='--', linewidth=1)
 axvline(x=0, **props) 
 axhline(y=0, **props)
If for some reason you *really* want to use the actual gridlines
functionality w/o affecting the ticks, you could selectively toggle
the visible property of the gridlines you do not want to show.
JDH

how can i create a grid at 0,0 ?
xticks( [0] )
yticks( [0] )
grid()
does not produce what i want because i loose ticks on the axis.
axvline(x=0, color='black', )
axhline(y=0, color='black', )
neither does this: i want a dashed line.

===== Original message from Mark Bakker | Fri, 1 Jul 2005:
> Detailed instructions for adding a color map seem to be given in the user 
> manual on page 61. Did you try that?
can anyone explain this format to me?
_cool_data = {'red': ((0., 0., 0.), (1.0, 1.0, 1.0)),
 'green': ((0., 1., 1.), (1.0, 0., 0.)),
 'blue': ((0., 1., 1.), (1.0, 1., 1.))}

Vidar Gundersen wrote:
>i would like to add colorbrewer colormaps to matplotlib,
>at least for my personal use, but i would like to do this
>properly so that this can be used by others.
>
>ColorBrewer:
>http://www.personal.psu.edu/faculty/c/a/cab38/ColorBrewerBeta2.html
>
>any hints on where to start? start with the cm.py module?
>extend cm.py or create a stand-alone one?
>
>the ColorBrewer palettes could be addressed by something
>like one of the following, i guess?:
>
> cmap=cm.colorbrewer.PuBuGn
> cmap=colorbrewer.PuBuGn
>
>the colorbrewer palettes are specified by 3 to 9 rgb colors,
>each interpolated differently, how many of these points would
>be preferred in a matplotlib module?
>
>...or even all of them, assuming 5seq as a default
>(when using the above):
>
> cmap=cm.colorbrewer.PuBuGn.3seq
> cmap=cm.colorbrewer.PuBuGn.9seq
>
> 
>
Jim Boyle posted a nice example that shows how to do this a while back.
http://sourceforge.net/mailarchive/message.php?msg_id=11255878
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

On Fri, 2005年07月01日 at 10:15 -0700,
mat...@li... wrote:
> Hi all,
> I have been following this list for some time, as well as using and
> spreading the news about matplotlib for all people I know and use
> python. :-)
> 
> I would like also to thank all the developers for all the amazing work 
> that has been done on matplotlib, it helps me a lot in my work.
> 
> Now the reason why I am writing to this list is to ask what is the
> preferred policy for packaging matplotlib as an rpm for FC4. Yesterday was
> accepted in Fedora Extras and so it should take a few days to be available.
> 
> The packager choose to package matplotlib (called python-matplotlib) with
> both dateutils and pytz packaged together while I use to package it as 3
> separate packages.
> 
> What is the opinion of the packager/developers here? Which scheme do you
> prefer?
> 
> Thanks again for this nice package.
My preference is for 3 separate packages - matplotlib which depends on 
dateutils and pytz.
I think the problem is caused by matplotlib itself. I don't think that 
matplotlib should repackage dateutils and pytz which are already 
independent packages. I understand that John included them initially in 
order to make matplotlib easier to download and install, which I 
understand. But now that matplotlib is being packaged for distributions 
it creates unnecessary extra work for the matplotlib packagers.
Regards
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com