matplotlib-devel Mailing List for matplotlib

here's the old way
	cut and paste some numbers from a web page
	like the number of live births by year
	dump it in a file named moo
	run gnuplot
	and say
		plot '/tmp/moo' w l 3
	boom
	default graph to show friends
the thing is
in the new way [python import pylab plot show]
what's the best default graph
i wanna say what?
ipython -c 'readplotfile blah ... parse file ugh ...'
um
i need a one liner
ya know
find the baby boom
1910 2777000 30.1
1915 2965000 29.5
1920 2950000 27.7
1925 2909000 25.1
1930 2618000 21.3
1935 2377000 18.7
1940 2559000 19.4
1945 2858000 20.4
1950 3632000 24.1
1952 3913000 25.1
1953 3965000 25.1
1954 4078000 25.3
1955 4104000 25.0
1956 4218000 25.2
1957 4308000 25.3
1958 4255000 24.5
1959 4295000 24.3
1960 4257850 23.7
1961 4268326 23.3
1962 4167362 22.4
1963 4098020 21.7
1964 4027490 21.0
1965 3760358 19.4
1966 3606274 18.4
1967 3520959 17.8
1968 3501564 17.5
1969 3600206 17.8
1970 3731386 18.4
1971 3555970 17.2
1972 3258411 15.6
1973 3136965 14.9
1974 3159958 14.9
1975 3144198 14.8
1976 3167788 14.8
1977 3326632 15.4
1978 3333279 15.3
1979 3494398 15.9
1980 3612258 15.9
1982 3680537 15.9
1983 3638933 15.5
1984 3669141 15.5
1985 3760561 15.8
1986 3731000 15.5
1987 3829000 15.7
1988 3913000 15.9
1989 4021000 16.2
1990 4179000 16.7
1991 4111000 16.2
1992 4084000 16.0
1993 4039000 15.7
1994 3979000 15.3
1995 3892000 14.8
1996 3899000 14.7
1997 3882000 14.5
1998 3941553 14.6
1999 3959417 14.5
2000 4058814 14.7
2001 4025933 14.1
2002 4021726 13.9
2003 4089950 14.1
2004 4112052 14.0
2005 4138349 14.0

I think I've found a bug in matplotlib. I use Sage, which is based on
Python and included matplotlib.
sage: import pylab
sage: pylab.text(0.2, 0.2, r"$\left(2a = b\right)$") # note \left(
and \right) work
<matplotlib.text.Text object at 0x10daaf950>
sage: pylab.text(0.2, 0.5, r"$(2 ,円 a = b)$") # note ,円 works
<matplotlib.text.Text object at 0x10dab9c90>
sage: pylab.savefig('a.png')
sage: pylab.text(0.2, 0.7, r"$\left(2 ,円 a = b\right)$") # but
together they don't
<matplotlib.text.Text object at 0x10dad9b10>
sage: pylab.savefig('b.png')
ERROR: An unexpected error occurred while tokenizing input
...
AttributeError: 'Kern' object has no attribute 'height'
Is this repeatable for anyone else? Would the full traceback be helpful?
-- 
J. H. Palmieri
jhp...@gm...

On Wed, Jan 27, 2010 at 6:06 PM, Andrew Straw <str...@as...> wrote:
> I'm +1 on this. We can have then have the buildbot doc builder enable
> this when building the docs. (Which are output at
> http://matplotlib.sourceforge.net/trunk-docs/ and
> http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf , for
> reference .)
Thanks, with your and John's (off-list) approvals, it's committed.
The patch that went in had more docs than what I posted here, but the
code is identical.
Cheers,
f

On Thu, Jan 28, 2010 at 1:03 PM, Eric Firing <ef...@ha...> wrote:
> Ryan May wrote:
>> Unless I completely misunderstand zorder, the contour should be *on
>> top* of the rectangle. Also note that printing the zorder for the
>> contour's collection (a LineCollection object) gives a value of 2,
>> even though the call to contour() specified 5 for the zorder. Looking
>> over the code for contour, the zorder is never mentioned. The reason
>> the LineCollection ends up with a value of 2 is that this is the
>> default for a LineCollection. My question is: is there any reason
>> *not* to use the passed in zorder for contours/filled contours? If
>> this is the proper fix, I'll check it in myself, I just wanted to make
>> sure I'm not missing some special case here.
>
> Ryan,
>
> Certainly it makes sense to support zorder in some fashion, and the simple
> way is as you suggest, with one value per call to contour. It may be best
> to stop there--but I can imagine the next complaint being, "why doesn't
> zorder support a sequence?", and then things get quite a bit more
> complicated.
>
> Anyway, go ahead and put in the simple zorder support; I don't see any
> downside to it.
Will do shortly.
>> As an aside, this is yet another example where it would be nice to
>> know that a keyword argument was not being used. If there's no
>> objections, I'd be willing to change ContourSet to pop arguments off
>> of **kwargs so that it can see if some aren't used and throw an
>> exception if not all are used. On the other hand, this could break
>> existing code that are passing extra/useless kwargs, so maybe a
>> warning would be better?
>
> Careful. Keeping track of which kwargs are used, and making sure they are
> always popped, and don't need to remain in the kwargs dictionary, could get
> tricky. I just added support for the units-related kwargs. I think what
> you suggest will work, and I agree that some error-trapping for kwarg
> accidents (misspelling kwargs, or otherwise trying to use a kwarg that has
> no effect) is a good idea.
>
> This sounds like an area where some general mpl coding guidelines, and quite
> a bit of work to implement them, would be good.
Agreed. After I wrote this, I thought about it some more, and it's
not something you can really do piecemeal due to passing off to base
classes and what not. It's a big usability wart however, like when
accidentally using 'linewidth' instead of 'linewidths' for calling
contour. I'll just leave this as a future improvement.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Ryan May wrote:
> Hi,
> 
> I was shown a bug today by a colleague, demonstrated by the following example:
> 
> import numpy as np
> import matplotlib.pyplot as plt
> 
> a = np.zeros([10, 10])
> a[2:6,3:8] = 1
> ls = plt.contour(a, 1, colors='r', linewidths=3, zorder=5)
> print ls.collections[0]l.get_zorder()
> rect = plt.Rectangle([2, 3], 5, 4, zorder=3)
> plt.gca().add_artist(rect)
> plt.show()
> 
> Unless I completely misunderstand zorder, the contour should be *on
> top* of the rectangle. Also note that printing the zorder for the
> contour's collection (a LineCollection object) gives a value of 2,
> even though the call to contour() specified 5 for the zorder. Looking
> over the code for contour, the zorder is never mentioned. The reason
> the LineCollection ends up with a value of 2 is that this is the
> default for a LineCollection. My question is: is there any reason
> *not* to use the passed in zorder for contours/filled contours? If
> this is the proper fix, I'll check it in myself, I just wanted to make
> sure I'm not missing some special case here.
Ryan,
Certainly it makes sense to support zorder in some fashion, and the 
simple way is as you suggest, with one value per call to contour. It 
may be best to stop there--but I can imagine the next complaint being, 
"why doesn't zorder support a sequence?", and then things get quite a 
bit more complicated.
Anyway, go ahead and put in the simple zorder support; I don't see any 
downside to it.
> 
> As an aside, this is yet another example where it would be nice to
> know that a keyword argument was not being used. If there's no
> objections, I'd be willing to change ContourSet to pop arguments off
> of **kwargs so that it can see if some aren't used and throw an
> exception if not all are used. On the other hand, this could break
> existing code that are passing extra/useless kwargs, so maybe a
> warning would be better?
Careful. Keeping track of which kwargs are used, and making sure they 
are always popped, and don't need to remain in the kwargs dictionary, 
could get tricky. I just added support for the units-related kwargs. I 
think what you suggest will work, and I agree that some error-trapping 
for kwarg accidents (misspelling kwargs, or otherwise trying to use a 
kwarg that has no effect) is a good idea.
This sounds like an area where some general mpl coding guidelines, and 
quite a bit of work to implement them, would be good.
Eric
> 
> Ryan
> 

Hi,
I was shown a bug today by a colleague, demonstrated by the following example:
import numpy as np
import matplotlib.pyplot as plt
a = np.zeros([10, 10])
a[2:6,3:8] = 1
ls = plt.contour(a, 1, colors='r', linewidths=3, zorder=5)
print ls.collections[0]l.get_zorder()
rect = plt.Rectangle([2, 3], 5, 4, zorder=3)
plt.gca().add_artist(rect)
plt.show()
Unless I completely misunderstand zorder, the contour should be *on
top* of the rectangle. Also note that printing the zorder for the
contour's collection (a LineCollection object) gives a value of 2,
even though the call to contour() specified 5 for the zorder. Looking
over the code for contour, the zorder is never mentioned. The reason
the LineCollection ends up with a value of 2 is that this is the
default for a LineCollection. My question is: is there any reason
*not* to use the passed in zorder for contours/filled contours? If
this is the proper fix, I'll check it in myself, I just wanted to make
sure I'm not missing some special case here.
As an aside, this is yet another example where it would be nice to
know that a keyword argument was not being used. If there's no
objections, I'd be willing to change ContourSet to pop arguments off
of **kwargs so that it can see if some aren't used and throw an
exception if not all are used. On the other hand, this could break
existing code that are passing extra/useless kwargs, so maybe a
warning would be better?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jan 28, 2010 at 2:00 AM, Robert Bradshaw
<rob...@ma...> wrote:
[snip]
> I'm guessing that's the issue, but just to be sure, try using the bare
I still get the error with the super-bare extension module, so
cython's off the hook :-).
> Have you verified that the same C++ compiler and version of libstdc++ is
> being used for everything?
I've tried it two ways; first with everything -- numpy, scipy,
matplotlib -- installed and compiled from svn, and one with them
installed from the latest ubuntu repositories. I also tried it on
both machines I have access to; a 64bit server with gcc 4.3.3 and
python 2.6.2, and a 32bit one with gcc 4.4.1 and python 2.6.4. The
error is the same on both of those. The python version and the gcc
compiler are the two things in common.
> If you did upgrade NumPy, rebuild *everything* of compiled code
> which depends on it.
Yes I did do that, and recompiled everything, but still good to check.
gcc is smelling fishier and fishier (or maybe python 2.6?).
-- Hoyt
++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ ho...@gm...
++++++++++++++++++++++++++++++++++++++++++

Hoyt Koepke wrote:
> I'm really not sure which mailing list to report this on -- it has got
> to rank up there with one of the most obscure errors of all times. I
> suspect it's an error in gcc's new openmp implementation, gomp, but
> not sure; I can report it there if people think I should.
>
> In gcc 4.4.1, when I compile a completely empty .pyx module in (1) c++
> mode and (2) pass -lgomp to the linker, simply (3) importing that
> empty module causes any subsequent use of matplotlib to segfault the
> program. Changing either (1), (2) or (3) makes the error go away.
>
> I'm using the latest 32bit ubuntu (9.10), python 2.6.4, with the
> latest cython-devel (2820:105c661599c9) and the latest matplotlib from
> svn (8097). In matplotlib, I'm using the qt4agg backend. Everything
> else appears to be working save for this error.
>
> If my main file is simply:
>
> import tests.emptymodule
> import tests.plottest
>
> where emptymodules is a completely empty cython module and plottest is
>
> from matplotlib.pylab import *
>
> figure()
> plot([0,1], [0,1], '-b')
> show()
>
> The program segfaults on the plot() call, with backtrace
>
> (gdb) bt 8
> #0 0x00e03bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
> #1 0x0093f282 in py_to_agg_transformation_matrix (obj=0x8223f58,
> errors=false) at src/agg_py_transforms.cpp:20
> #2 0x00946ff3 in _path_module::update_path_extents (this=0x8856098,
> args=...) at src/path.cpp:346
> #3 0x0094e2fd in
> Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
> optimized out>, method_def=0x8476e00, args=...)
> at ./CXX/Python2/ExtensionModule.hxx:184
> #4 0x0093ae26 in method_varargs_call_handler
> (_self_and_name_tuple=0x888448c, _args=0x8f052fc) at
> CXX/Python2/cxx_extensions.cxx:1714
> #5 0x080dc0d0 in PyEval_EvalFrameEx ()
> #6 0x080dddf2 in PyEval_EvalCodeEx ()
> #7 0x080dc1b4 in PyEval_EvalFrameEx ()
>
> 
It works for me here, but of course, I have a slightly different system.
gcc-4.3, python 2.5.2, Cython 0.12, and matplotlib SVN 8097.
Have you verified that the same C++ compiler and version of libstdc++ is 
being used for everything?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm really not sure which mailing list to report this on -- it has got
to rank up there with one of the most obscure errors of all times. I
suspect it's an error in gcc's new openmp implementation, gomp, but
not sure; I can report it there if people think I should.
In gcc 4.4.1, when I compile a completely empty .pyx module in (1) c++
mode and (2) pass -lgomp to the linker, simply (3) importing that
empty module causes any subsequent use of matplotlib to segfault the
program. Changing either (1), (2) or (3) makes the error go away.
I'm using the latest 32bit ubuntu (9.10), python 2.6.4, with the
latest cython-devel (2820:105c661599c9) and the latest matplotlib from
svn (8097). In matplotlib, I'm using the qt4agg backend. Everything
else appears to be working save for this error.
If my main file is simply:
import tests.emptymodule
import tests.plottest
where emptymodules is a completely empty cython module and plottest is
from matplotlib.pylab import *
figure()
plot([0,1], [0,1], '-b')
show()
The program segfaults on the plot() call, with backtrace
(gdb) bt 8
#0 0x00e03bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1 0x0093f282 in py_to_agg_transformation_matrix (obj=0x8223f58,
errors=false) at src/agg_py_transforms.cpp:20
#2 0x00946ff3 in _path_module::update_path_extents (this=0x8856098,
args=...) at src/path.cpp:346
#3 0x0094e2fd in
Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
optimized out>, method_def=0x8476e00, args=...)
 at ./CXX/Python2/ExtensionModule.hxx:184
#4 0x0093ae26 in method_varargs_call_handler
(_self_and_name_tuple=0x888448c, _args=0x8f052fc) at
CXX/Python2/cxx_extensions.cxx:1714
#5 0x080dc0d0 in PyEval_EvalFrameEx ()
#6 0x080dddf2 in PyEval_EvalCodeEx ()
#7 0x080dc1b4 in PyEval_EvalFrameEx ()
Other commands like imshow also cause a segfault.
Anyway, I can get by for now without openmp, but I'm curious if anyone
has ideas about this bug. I've attached a tarball with the code that
reproduces it for me; simply run build.sh and run.
Thanks!
-- hoyt
++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ ho...@gm...
++++++++++++++++++++++++++++++++++++++++++

Fernando Perez wrote:
> Hi all,
>
> would anyone mind if I commit the attached patch?
>
> It's 100% backwards compatible and allows for turning plot directive
> errors into fatal exceptions easily, so one can make sure that docs
> either build correctly or not at all. This is useful for having
> examples be a kind of test suite, in addition to any unit tests a
> codebase may have.
>
> Thanks,
>
> f
> 
I'm +1 on this. We can have then have the buildbot doc builder enable
this when building the docs. (Which are output at
http://matplotlib.sourceforge.net/trunk-docs/ and
http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf , for
reference .)
-Andrew

Hi all,
would anyone mind if I commit the attached patch?
It's 100% backwards compatible and allows for turning plot directive
errors into fatal exceptions easily, so one can make sure that docs
either build correctly or not at all. This is useful for having
examples be a kind of test suite, in addition to any unit tests a
codebase may have.
Thanks,
f

Jae-Joon Lee wrote:
> On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> Adding a "set_ticks" method seems reasonable.
> 
> A patch is attached.
It looks like exactly what I had in mind with respect to set_ticks. I 
wasn't thinking about set_ticklabels; my sense is that manually setting 
ticklabels tends to be tricky and error-prone, and should be 
discouraged. Maybe it should be permitted only when a FixedLocator is 
already in use.
> It does some refactoring and introduces three new methods, set_ticks,
> set_ticklabels and update_ticks, on the colorbar class.
> So, now one can do
> 
> imshow(np.arange(100).reshape((10,10)))
> cb = colorbar()
> cb.set_ticks([0, 40, 80])
> 
> Issuing a warning when user try to call Axis.set_ticks (or others)
> directly seems not straight forward as the axes can be created
> externally (i.e., when *cax* is provided).
Attached patch against svn (without your patch) shows how this can be 
done for the Axes methods. I would be more difficult (but not 
impossible) for the Axis methods, because we need to use them. I think 
that handling the Axes methods *may* be worthwhile (marginal), but 
handling the Axis methods is more trouble than it is worth.
Eric
> 
> I'll wait for response for a few more days and will commit the change.
> Regards,
> 
> -JJ

2010年1月25日 Nicolas Rougier <Nic...@lo...>:
>
>
> Hello,
>
> This is an update about glumpy, a fast-OpenGL based numpy visualization.
> I modified the code such that the only dependencies are PyOpenGL and
> IPython (for interactive sessions). You will also need matplotlib and
> scipy for some demos.
>
> Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
> No installation required, you can run all demos inplace.
>
> Homepage: http://code.google.com/p/glumpy/
>
Hi Nicolas,
thank you for providing glumpy. I started using it for my own project.
The previous, pyglet based version of glumpy worked flawlessly on my
system (WinXP). I want to report about problems with the latest
version.
1.) On Windows glumpy fails on importing the Python termios module,
since it is for Unix platforms only.
2.) Resolving this, the demos start, but are mostly not usable, since
mouse scroll events and passive mouse motions events are not created.
This might be a problem of the glut implementation on Windows (I am
using PyOpenGL 3.0.1b2). Who knows?
3.) On OpenSuse11.1 the demos fail at 'glCreateProgram'. The demos
used to work with the previous version. I use the Intel Q45 graphics
chipset.
In the future I might spend some time on this problems and I would
like to contribute to glumpy, even if it's only testing on platforms
available to me.
Gregor

On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Adding a "set_ticks" method seems reasonable.
A patch is attached.
It does some refactoring and introduces three new methods, set_ticks,
set_ticklabels and update_ticks, on the colorbar class.
So, now one can do
 imshow(np.arange(100).reshape((10,10)))
 cb = colorbar()
 cb.set_ticks([0, 40, 80])
Issuing a warning when user try to call Axis.set_ticks (or others)
directly seems not straight forward as the axes can be created
externally (i.e., when *cax* is provided).
I'll wait for response for a few more days and will commit the change.
Regards,
-JJ

>
> How do you get around this while supporting both the proportional and the
> non-proportional modes?
>
 I must confess that I never considered that option. And, no, my
current implementation does not support non-proportional mode. So, I
guess syncing the data coordinate with ticks has its own problem.
>>
>> 1) leave it as is. but issue a warning when a users calls "set_yticks"
>> (or its relatives) on the colobar axes.
>
> Based on a quick look, I think that with some refactoring, we could add a
> set_ticks method. In a way, the question here is whether the colorbar
> should be thought of as a conventional axes object, or whether it is OK for
> it to have its own API. I think the latter is more natural, because it is a
> specialized object; once its orientation is established, there is only one
> set of ticks and one axis label. Ideally, cbar.ax would be an Axes object
> stripped down to its essentials; but that would involve major mpl
> refactoring.
>
> Intercepting calls to set_yticks and set_xticks and replacing them with
> warnings to use a new set_ticks would be good.
>
Adding a "set_ticks" method seems reasonable.
>>
>> 2) use the reimplemented version of the colorbar, but drop the
>> axes_locator part. The colorbar will be fully functional except the
>> "extend" feature (triangles at the ends of the colorbar. see
>> http://matplotlib.sourceforge.net/examples/api/colorbar_only.html).
>
> This is not acceptable. The "extend" feature is essential.
I see.
>
>>
>> 3) use the reimplemented version of the colorbar.
>>
>> 4) someone else comes up with a better implementation.
>
> Regarding 3 or 4, if you or anyone else can come up with a better
> implementation, preserving at least the present functionality, that's great.
> The present implementation was a pain to develop and is hard to understand
> and maintain.
As a person who never uses "extend" and "non-proportional" mode, I'm
afraid that I do not have much motivation for now. But, it would be
great if someone can come up with a better implementation!
Regards,
-JJ

Hi Nicolas,
On Mon, Jan 25, 2010 at 2:46 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
>
> Hello,
>
> This is an update about glumpy, a fast-OpenGL based numpy visualization.
> I modified the code such that the only dependencies are PyOpenGL and
> IPython (for interactive sessions). You will also need matplotlib and
> scipy for some demos.
>
> Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
> No installation required, you can run all demos inplace.
>
> Homepage: http://code.google.com/p/glumpy/
This is great, and it would be very cool to have it updated to the new
code we're now landing in ipython with a much cleaner internal API
(finally :) Have you had a chance to look at the code in my trunk-dev
branch?
https://code.launchpad.net/~fdo.perez/ipython/trunk-dev
Brian finished a large review of it and we just had a chance to go
over his feedback directly, so there's now one more round of reviews
to do (once he applies the changes from our discussion) and this
should become trunk very soon. The apis are much cleaner, this is the
big cleanup I told you about last year, and now we're getting to the
point where having multiple ipython frontends is a very realistic
prospect.
Unfortunately we won't be able to use your code directly in IPython as
it stands, since the GPL provisions in it would require us to GPL all
of IPython to make use of any of it directly in IPython. Your code
uses iptyhon, numpy, matplotlib and scipy (in some demos), which
amounts to hundreds of thousands of lines of code; here are the
sloccount outputs from their respective trunks:
IPython
Totals grouped by language (dominant language first):
python: 47357 (99.24%)
lisp: 262 (0.55%)
sh: 62 (0.13%)
objc: 37 (0.08%)
Numpy
Totals grouped by language (dominant language first):
ansic: 152950 (67.19%)
python: 73188 (32.15%)
cpp: 828 (0.36%)
fortran: 298 (0.13%)
sh: 156 (0.07%)
pascal: 120 (0.05%)
f90: 97 (0.04%)
Matplotlib
Totals grouped by language (dominant language first):
python: 83290 (52.64%)
cpp: 68212 (43.11%)
objc: 4517 (2.85%)
ansic: 2149 (1.36%)
sh: 69 (0.04%)
Scipy
Totals grouped by language (dominant language first):
cpp: 220149 (48.35%)
fortran: 87240 (19.16%)
python: 79164 (17.38%)
ansic: 68746 (15.10%)
sh: 61 (0.01%)
Glumpy:
Totals grouped by language (dominant language first):
python: 3751 (100.00%)
We're looking at ~300.000 lines of python alone in these tools. It's
unfortunately not realistic for us to consider GPL-ing them in order
to incorporate glumpy into the core set; it would be fantastic if you
were willing to consider licensing your code under a license that is
compatible with the body of work you are building on top of.
You are obviously free to choose your license as you see fit, and end
users (myself included) will be always able to use glumpy along with
ipython, numpy, matplotlib and scipy. So *users* get all of the
benefit of your contribution, and for that I am the first to be
delighted and grateful that you've put your code out there.
But as it stands, your code builds on close to half a million lines of
other code which can not benefit back from your contributions. If you
consider licensing glumpy to be compatible with ipython, numpy and
matplotlib, it would be possible to incorporate your ideas back into
those projects: perhaps in some places the right solution would be to
fix our own designs to better provide what glumpy needs, in other
cases we may find fixes you've made fit better upstream, etc.
But this kind of collaboration will not be possible as long as glumpy
can benefit from our tools but our codes are not allowed to benefit
from glumpy (without changing licenses, which isn't going to happen).
I hope you consider this from our perspective and in the most friendly
and open manner: I completely respect your right to license your own
code as you see fit (I've seen people put out GPL 'projects' that
effectively consist of 3 lines that import IPython and make a function
call, and that's OK too, and allowed by the license I chose to use).
The only reason I ask you is because I think your tool is very
interesting, and it would ultimately lead to a much more productive
relationship with ipython, numpy and matplotlib if it could be a
collaboration instead of a one-way benefit.
Best regards,
Fernando.

When labeling the lines of latitude and longitude on a map, it appears that
there is currently no way to control the color of the labels. It would be
great if a keyword could be added to enable this.
http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html#mpl_toolkits.basemap.Basemap.drawparallels
-- 
View this message in context: http://old.nabble.com/need-a-way-to-control-color-of-labels-tp27314724p27314724.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Olle Engdegård wrote:
> Hi,
> 
> Combining "stepfilled" with log scale sometimes gives inappropriate plots:
> 
> a=[4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5]
> hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True)
> 
> The problem is not restricted to the case here with more bins than unique 
> elements, but sometimes reducing the bin number makes the issue go away.
> 
> Cheers,
> Olle
> 
> 
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Thanks for the report. This is fixed now in r8097. mm

Jae-Joon Lee wrote:
> John and others developers,
> 
> I think the current colorbar implementation has some (minor) issue
> related with how ticks are treated.
> 
> Here is a quick example,
> 
> imshow(np.arange(100).reshape((10,10)))
> cb = colorbar()
> 
> This gives you a nice colorbar, However, an issue arises when you want
> to change the ticks.
> 
> cax = cb.ax
> cax.set_yticks([0, 40, 80])
> 
> And the colorbar got messed up.
> 
> Changing ticks and ticklabels after the colobar is created is quite tricky.
> And, the easiest solution is to set those when creating the colorbar.
> 
> As far as I can see, the real confusion comes fromthe fact that, in
> the current colorbar implementation, the data coordinate of the
> colorbar axes has nothing to do with the actual color scale.
> In the above example, while the color scale ranges from 0 to 99, the
> data coordinate (ylim) is still from 0 to 1.
How do you get around this while supporting both the proportional and 
the non-proportional modes?
> 
> A few months back, I worked on a revised implementation of the
> colorbar, and that version of colorbar is currently included in the
> axes_grid toolkit. It is backward-compatible, but it uses
> "axes_locator" feature that I'm a bit reluctant to push into the
> mainline matplotlib.
> 
> So, here is a few possible resolutions I consider.
> 
> 1) leave it as is. but issue a warning when a users calls "set_yticks"
> (or its relatives) on the colobar axes.
Based on a quick look, I think that with some refactoring, we could add 
a set_ticks method. In a way, the question here is whether the colorbar 
should be thought of as a conventional axes object, or whether it is OK 
for it to have its own API. I think the latter is more natural, because 
it is a specialized object; once its orientation is established, there 
is only one set of ticks and one axis label. Ideally, cbar.ax would be 
an Axes object stripped down to its essentials; but that would involve 
major mpl refactoring.
Intercepting calls to set_yticks and set_xticks and replacing them with 
warnings to use a new set_ticks would be good.
> 
> 2) use the reimplemented version of the colorbar, but drop the
> axes_locator part. The colorbar will be fully functional except the
> "extend" feature (triangles at the ends of the colorbar. see
> http://matplotlib.sourceforge.net/examples/api/colorbar_only.html).
This is not acceptable. The "extend" feature is essential.
> 
> 3) use the reimplemented version of the colorbar.
> 
> 4) someone else comes up with a better implementation.
Regarding 3 or 4, if you or anyone else can come up with a better 
implementation, preserving at least the present functionality, that's 
great. The present implementation was a pain to develop and is hard to 
understand and maintain.
Eric
> 
> I don't think there is an immediate need for any changes as I see it
> as a minor issue.
> I'm just posting this as there has been a few recent questions
> regarding the colorbar behavior in the user list.
> 
> Any suggestion and/or comments?
> Regards,
> 
> -JJ

John and others developers,
I think the current colorbar implementation has some (minor) issue
related with how ticks are treated.
Here is a quick example,
 imshow(np.arange(100).reshape((10,10)))
 cb = colorbar()
This gives you a nice colorbar, However, an issue arises when you want
to change the ticks.
 cax = cb.ax
 cax.set_yticks([0, 40, 80])
And the colorbar got messed up.
Changing ticks and ticklabels after the colobar is created is quite tricky.
And, the easiest solution is to set those when creating the colorbar.
As far as I can see, the real confusion comes fromthe fact that, in
the current colorbar implementation, the data coordinate of the
colorbar axes has nothing to do with the actual color scale.
In the above example, while the color scale ranges from 0 to 99, the
data coordinate (ylim) is still from 0 to 1.
A few months back, I worked on a revised implementation of the
colorbar, and that version of colorbar is currently included in the
axes_grid toolkit. It is backward-compatible, but it uses
"axes_locator" feature that I'm a bit reluctant to push into the
mainline matplotlib.
So, here is a few possible resolutions I consider.
1) leave it as is. but issue a warning when a users calls "set_yticks"
(or its relatives) on the colobar axes.
2) use the reimplemented version of the colorbar, but drop the
axes_locator part. The colorbar will be fully functional except the
"extend" feature (triangles at the ends of the colorbar. see
http://matplotlib.sourceforge.net/examples/api/colorbar_only.html).
3) use the reimplemented version of the colorbar.
4) someone else comes up with a better implementation.
I don't think there is an immediate need for any changes as I see it
as a minor issue.
I'm just posting this as there has been a few recent questions
regarding the colorbar behavior in the user list.
Any suggestion and/or comments?
Regards,
-JJ

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
>> When I generate a map with the aeqd projection, the width parameter 
>> has no
>> effect. This looks like a bug.
>> 
> Philip: I don't see this. Here's an example, does this fail for you?
>
> lon_0=-105; lat_0=40
> width=4000.e3
> height=4000.e3
> m =\
> Basemap(resolution='c',projection='aeqd',lat_0=lat_0,lon_0=lon_0,width=width,height=height) 
>
> m.drawcoastlines(linewidth=0.5)
> m.fillcontinents()
> plt.show()
>
>
> -Jeff
>
I specified width but not height. I'm not sure how the code should 
behave under those conditions, but in any case this was my fault.
Thanks!
Phillip

Phillip M. Feldman wrote:
> Andrew Straw wrote:
>> Jeff Whitaker wrote:
>> 
>>> Dr. Phillip M. Feldman wrote:
>>> 
>>>> Basemap offers many projections, but is missing two of the most 
>>>> useful ones:
>>>>
>>>> - For satellite applications, it would be helpful to have a "camera"
>>>> projection, i.e., a projection that shows the Earth as viewed from a
>>>> specified point in space. This would be a generalization of the 
>>>> current
>>>> geostationary projection.
>>>> 
>>> Philip: Don't think the proj4 lib supports this.
>>> 
>> I think it's already in there -- see nsper, for near sided perspective.
>>
>> -Andrew
>>
>> 
> Hello Andrew-
>
> It does sound as thought nsper is exactly what I need, but when I try 
> to use it, I get the following error message:
>
> ValueError: 'nsper' is an unsupported projection.
> The supported projections are:
>
> aeqd Azimuthal Equidistant
> poly Polyconic
> gnom Gnomonic
> moll Mollweide
> tmerc Transverse Mercator
> nplaea North-Polar Lambert Azimuthal
> gall Gall Stereographic Cylindrical
> mill Miller Cylindrical
> merc Mercator
> stere Stereographic
> npstere North-Polar Stereographic
> geos Geostationary
> vandg van der Grinten
> laea Lambert Azimuthal Equal Area
> mbtfpq McBryde-Thomas Flat-Polar Quartic
> sinu Sinusoidal
> spstere South-Polar Stereographic
> lcc Lambert Conformal
> npaeqd North-Polar Azimuthal Equidistant
> eqdc Equidistant Conic
> cyl Cylindrical Equidistant
> omerc Oblique Mercator
> aea Albers Equal Area
> spaeqd South-Polar Azimuthal Equidistant
> ortho Orthographic
> cass Cassini-Soldner
> splaea South-Polar Lambert Azimuthal
> robin Robinson
>
> Phillip 
Philip: I think Andrew meant nsper is in proj4. I'll look into adding 
support for it in Basemap.
-Jeff

Dr. Phillip M. Feldman wrote:
> When I generate a map with the aeqd projection, the width parameter has no
> effect. This looks like a bug.
> 
Philip: I don't see this. Here's an example, does this fail for you?
lon_0=-105; lat_0=40
width=4000.e3
height=4000.e3
m =\
Basemap(resolution='c',projection='aeqd',lat_0=lat_0,lon_0=lon_0,width=width,height=height)
m.drawcoastlines(linewidth=0.5)
m.fillcontinents()
plt.show()
-Jeff

Hello,
This is an update about glumpy, a fast-OpenGL based numpy visualization.
I modified the code such that the only dependencies are PyOpenGL and
IPython (for interactive sessions). You will also need matplotlib and
scipy for some demos.
Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
No installation required, you can run all demos inplace.
Homepage: http://code.google.com/p/glumpy/
Nicolas

When I generate a map with the aeqd projection, the width parameter has no
effect. This looks like a bug.
-- 
View this message in context: http://old.nabble.com/with-projection%3Daeqd%2C-width-has-no-effect-tp27302405p27302405.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.