matplotlib-devel Mailing List for matplotlib

Hi Mike,
thanks. Your Python implementation looks good. I will test it, when it
is official released and we package that release for Debian/Ubuntu. I
will let you know, if there is something missing or not working.
Otherwise all will be fine.
Cheers,
Benjamin
Am Dienstag, den 06.10.2009, 10:09 -0400 schrieb Michael Droettboom:
> I have committed your suggestion to SVN r7849 (0.99 branch) and r7850 
> (trunk). It does exactly what you listed, but using Python functions 
> rather than system calls. Please test in your environment and let me 
> know if it's adequate when you get a chance.
> 
> Mike
> 
> Benjamin Drung wrote:
> > Hi,
> >
> > "doc/make.py clean" runs svn-clean. Running svn-clean outside the svn
> > repository does not clean anything. So "doc/make.py clean" does not work
> > in the Debian/Ubuntu package. Please remove the generated files directly
> > and do not relay on svn. In our package we run these commands:
> >
> > rm -rf doc/build doc/examples
> > rm -f doc/mpl_examples/api/*.png
> > rm -f doc/mpl_examples/pylab_examples/*.png
> > rm -f doc/mpl_examples/pylab_examples/*.pdf
> > rm -f doc/mpl_examples/units/*.png
> > rm -f doc/pyplots/tex_demo.png
> > rm -f doc/_static/matplotlibrc
> > rm -f doc/_templates/gallery.html
> >
> > Cheers,
> > Benjamin

David Cournapeau wrote:
> Hi,
>
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
>
> http://github.com/cournape/matplotlib/tree/scons_build
> 
Hi David,
I'm trying to download your git repository, but I'm having trouble
cloning it.
Can you do this? "git clone git://github.com/cournape/matplotlib.git"
For me, I get an error:
$ git clone git://github.com/cournape/matplotlib.git
Initialized empty Git repository in /home/astraw/tmp/mpl/matplotlib/.git/
fatal: The remote end hung up unexpectedly
This has been happening for 2 days now.
If it's not working for you, can you file a support ticket with github?
(Or just delete your old repo and start a new one on github, preferably
forking from the astraw/matplotlib.git repo.)
-Andrew

I have committed your suggestion to SVN r7849 (0.99 branch) and r7850 
(trunk). It does exactly what you listed, but using Python functions 
rather than system calls. Please test in your environment and let me 
know if it's adequate when you get a chance.
Mike
Benjamin Drung wrote:
> Hi,
>
> "doc/make.py clean" runs svn-clean. Running svn-clean outside the svn
> repository does not clean anything. So "doc/make.py clean" does not work
> in the Debian/Ubuntu package. Please remove the generated files directly
> and do not relay on svn. In our package we run these commands:
>
> rm -rf doc/build doc/examples
> rm -f doc/mpl_examples/api/*.png
> rm -f doc/mpl_examples/pylab_examples/*.png
> rm -f doc/mpl_examples/pylab_examples/*.pdf
> rm -f doc/mpl_examples/units/*.png
> rm -f doc/pyplots/tex_demo.png
> rm -f doc/_static/matplotlibrc
> rm -f doc/_templates/gallery.html
>
> Cheers,
> Benjamin
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> 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

Here it is.
On Tue, Oct 6, 2009 at 12:19 PM, Jeff Whitaker <js...@fa...> wrote:
> Stephane Raynaud wrote:
>>
>> Hi Jeff,
>>
>> how about allowing units to be set as meters when calling
>> Basemap.drawmapscale ?
>> And maybe adding the keyword "format" for formatting numeric values.
>> That would be interesting when plotting maps with small area.
>>
>> Thanks.
>>
>>
>
> Stephane: I don't use the drawmapscale function very much (it was
> contributed by another user). If you would like to submit a patch, I'd be
> happy to test it and then commit it.
> -Jeff
>
-- 
Stephane Raynaud

Stephane Raynaud wrote:
> Hi Jeff,
>
> how about allowing units to be set as meters when calling Basemap.drawmapscale ?
> And maybe adding the keyword "format" for formatting numeric values.
> That would be interesting when plotting maps with small area.
>
> Thanks.
>
> 
Stephane: I don't use the drawmapscale function very much (it was 
contributed by another user). If you would like to submit a patch, I'd 
be happy to test it and then commit it. 
-Jeff

Hi Jeff,
how about allowing units to be set as meters when calling Basemap.drawmapscale ?
And maybe adding the keyword "format" for formatting numeric values.
That would be interesting when plotting maps with small area.
Thanks.
-- 
Stephane Raynaud

Phillip M. Feldman wrote:
> Hello Eric-
> 
> I'd like to understand the reason why you object to piecewise-constant 
> colormaps. I have found these to be useful for some types of plots. 
It is a crude and indirect way of achieving a result that can be 
achieved precisely and directly using ListedColormap and BoundaryNorm, 
or possibly a subclass. The problem is that discretization is being 
done at the wrong stage.
Suppose you have data in the range 1.5 to 2.5, and you want the low 
third of that range to be red, the middle green, and the upper blue. If 
you use LinearSegmentedColormap and one of your functions to make a 
discrete map, then you will have divided your interval of length 1 into 
256 segments, which does not allow you to specify exactly 1.5 + 1.0/3 as 
a transition point. You have only 8 bits of precision available.
What does allow you to specify the transitions exactly (to within the 
limits of double precision) is this:
cmap = ListedColormap(['r','g','b'])
norm = BoundaryNorm([1.5+1.0/3, 1.5+2.0/3], cmap.N)
Simple, readable, flexible: choose any boundaries you like, specify the 
colors any way you like, including pulling them out of an existing 
colormap. Efficient: the cmap lookup table has only as many entries as 
it needs, and the index into that table is calculated directly in a 
single step.
Now if you need autoscaling, with the boundaries calculated from vmin 
and vmax, then this can be done by subclassing BoundaryNorm. In both 
cases, after using this cmap and norm for a mappable, passing that 
mappable to colorbar will yield a reasonable result, because colorbar 
has special code to handle the BoundaryNorm.
> Also, the functionality to create piecewise-constant colormaps is 
> already provided by LinearSegmentedColormap, so "the cat is already out 
> of the bag", so to speak.. (I created my functions mainly because I 
LinearSegmentedColormap is very general, so yes, it can be used for this.
> found the LinearSegmentedColormap interface painful to use. Since then, 
That painfulness is exactly the reason why John Hunter added the 
from_list method 8 months ago (I forgot it had been there that long), 
and Reinier recently made it more flexible.
> I have found ways to produce the plots that I need with the existing 
> functions; some of the code isn't very pretty, but this is a secondary 
> consideration).
You are always welcome to use functions like that in your own code; if 
they help you, that's fine.
Whenever possible, we want to make it easy for users to plot with pretty 
code, so if you believe you can't, then either you are not seeing a nice 
way to do something, or there really is no nice way. In the latter 
case, an addition or improvement to mpl code may be in order. And in 
the former case, improvements in documentation and/or examples may be 
needed.
> 
> Eric/Reinier/all:
> 
> Is there some way to find out what development tasks are underway so 
> that duplication of effort can be avoided? If there were a list of 
> tasks with associated names and target dates, this would be very 
> useful. (Perhaps something like this already exists, but I have not 
> been able to find it).
> 
No, we operate in a very informal way. Big changes, and sometimes 
medium and smaller ones, are generally discussed on one of the lists, 
and that discussion indicates if anyone is actually working on the 
change. Some smaller and medium changes are simply done when a bee gets 
under someone's bonnet, leading to a burst of activity. I think most of 
us have at least short mental lists of things we would like to do, or to 
see done. All of us are severely constrained by time.
> Also, it seems as though the HTML documentation is sometimes quite 
> different from the doc strings. I've found the HTML easier to read 
> because of color, italics, etc., but the content of the doc strings is 
> sometimes better and/or quite different. It would be great if these 
> could be harmonized.
The API html docs are built automatically from the docstrings; the rest 
of the docs are written manually, and that does tend to lag.
Eric
> 
> Thanks!
> 
> Phillip
> 
> Eric Firing wrote:
>> Reinier Heeres wrote:
>>> Hi Philip, all,
>>>
>>> This work seems to overlap a lot with the recent color map changes I
>>> committed 
>>> (http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/colors.py?r1=7488&r2=7620), 
>>>
>>> except for the piece-wise constant color maps.
>>
>> Exactly. And I don't think piece-wise constant maps are a good idea, 
>> so I oppose including a function to make them.
>>
>>>
>>> Of course we should avoid duplicate code and work, so perhaps we can
>>> narrow it down to the piece-wise constant part? Please let me know
>>> what you think. We should definitely add a few examples of how to use
>>> this new code, as it might not be that clear directly. Basically the
>>> following is the idea:
>>>
>>> import numpy as np
>>> import matplotlib.colors as mcol
>>> import matplotlib.pyplot as plt
>>>
>>> stop = mcol.LinearSegmentedColormap.from_list('stop', ['green',
>>> 'orange', 'red'])
>>> # or: stop = mcol.LinearSegmentedColormap.from_list('stop', [(0,
>>> 'green'), (0.2, 'orange'), (1, 'red')])
>>
>> from_list could have an API more like Phillip's, with an optional 
>> argument for the transition points instead of using the sequence of 
>> pairs. I'm not sure whether this is an improvement or not, but it has 
>> some appeal to me.
>>
>> One might also argue that instead of being a static method, from_list 
>> should be renamed as a free-standing factory function in the colors 
>> namespace. Or that such an alias be created.
>>
>> Eric
>>
>>>
>>> x = np.arange(100)
>>> y = x.reshape((5,20))
>>> plt.imshow(y, cmap=stop)
>>> plt.show()
>>>
>>> Beside that, I think in no part of MPL we depend on scipy explicitly,
>>> so it would be good to get rid of that. Also, your use of isinstance
>>> should be replaced by the more generic functions in cbook.py (e.g.
>>> is_string_like, is_numlike).
>>>
>>> Regards,
>>> Reinier
>>>
>>> On Sun, Oct 4, 2009 at 4:34 AM, Dr. Phillip M. Feldman
>>> <pfe...@ve...> wrote:
>>>> "Create patch" worked. Thanks! The output is attached.
>>>>
>>>> http://www.nabble.com/file/p25734649/colors.py.diff colors.py.diff
>>>>
>>>>
>>>>> From: Dr. Phillip M. Feldman [mailto:pfe...@ve...]
>>>>> Sent: Thursday, October 01, 2009 20:45
>>>>>
>>>>> Unfortunately, I'm on a Windows system, and it appears that I
>>>>> must use SVN's GUI interface, which does not provide a
>>>>> mechanism for saving the diff to a file.
>>>> Which GUI are you using? If TortoiseSVN, you right-click on the 
>>>> modified
>>>> file
>>>> and select "Create patch..." from the TortoiseSVN menu.
>>>> -- 
>>>> View this message in context: 
>>>> http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25734649.html 
>>>>
>>>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>>>
> 

Hello Eric-
I'd like to understand the reason why you object to piecewise-constant 
colormaps. I have found these to be useful for some types of plots. 
Also, the functionality to create piecewise-constant colormaps is 
already provided by LinearSegmentedColormap, so "the cat is already out 
of the bag", so to speak.. (I created my functions mainly because I 
found the LinearSegmentedColormap interface painful to use. Since then, 
I have found ways to produce the plots that I need with the existing 
functions; some of the code isn't very pretty, but this is a secondary 
consideration).
Eric/Reinier/all:
Is there some way to find out what development tasks are underway so 
that duplication of effort can be avoided? If there were a list of 
tasks with associated names and target dates, this would be very 
useful. (Perhaps something like this already exists, but I have not 
been able to find it).
Also, it seems as though the HTML documentation is sometimes quite 
different from the doc strings. I've found the HTML easier to read 
because of color, italics, etc., but the content of the doc strings is 
sometimes better and/or quite different. It would be great if these 
could be harmonized.
Thanks!
Phillip
Eric Firing wrote:
> Reinier Heeres wrote:
>> Hi Philip, all,
>>
>> This work seems to overlap a lot with the recent color map changes I
>> committed 
>> (http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/colors.py?r1=7488&r2=7620), 
>>
>> except for the piece-wise constant color maps.
>
> Exactly. And I don't think piece-wise constant maps are a good idea, 
> so I oppose including a function to make them.
>
>>
>> Of course we should avoid duplicate code and work, so perhaps we can
>> narrow it down to the piece-wise constant part? Please let me know
>> what you think. We should definitely add a few examples of how to use
>> this new code, as it might not be that clear directly. Basically the
>> following is the idea:
>>
>> import numpy as np
>> import matplotlib.colors as mcol
>> import matplotlib.pyplot as plt
>>
>> stop = mcol.LinearSegmentedColormap.from_list('stop', ['green',
>> 'orange', 'red'])
>> # or: stop = mcol.LinearSegmentedColormap.from_list('stop', [(0,
>> 'green'), (0.2, 'orange'), (1, 'red')])
>
> from_list could have an API more like Phillip's, with an optional 
> argument for the transition points instead of using the sequence of 
> pairs. I'm not sure whether this is an improvement or not, but it has 
> some appeal to me.
>
> One might also argue that instead of being a static method, from_list 
> should be renamed as a free-standing factory function in the colors 
> namespace. Or that such an alias be created.
>
> Eric
>
>>
>> x = np.arange(100)
>> y = x.reshape((5,20))
>> plt.imshow(y, cmap=stop)
>> plt.show()
>>
>> Beside that, I think in no part of MPL we depend on scipy explicitly,
>> so it would be good to get rid of that. Also, your use of isinstance
>> should be replaced by the more generic functions in cbook.py (e.g.
>> is_string_like, is_numlike).
>>
>> Regards,
>> Reinier
>>
>> On Sun, Oct 4, 2009 at 4:34 AM, Dr. Phillip M. Feldman
>> <pfe...@ve...> wrote:
>>> "Create patch" worked. Thanks! The output is attached.
>>>
>>> http://www.nabble.com/file/p25734649/colors.py.diff colors.py.diff
>>>
>>>
>>>> From: Dr. Phillip M. Feldman [mailto:pfe...@ve...]
>>>> Sent: Thursday, October 01, 2009 20:45
>>>>
>>>> Unfortunately, I'm on a Windows system, and it appears that I
>>>> must use SVN's GUI interface, which does not provide a
>>>> mechanism for saving the diff to a file.
>>> Which GUI are you using? If TortoiseSVN, you right-click on the 
>>> modified
>>> file
>>> and select "Create patch..." from the TortoiseSVN menu.
>>> -- 
>>> View this message in context: 
>>> http://www.nabble.com/proposed-change-to-colors.py-tp25691605p25734649.html 
>>>
>>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>>