matplotlib-devel Mailing List for matplotlib

>
> 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.