Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib
Andrew Straw wrote: > David Cournapeau wrote: > >> Andrew Straw wrote: >> >> >>> Andrew Straw wrote: >>> >>> >>> David Cournapeau wrote: > I have a question about git as well, actually - I could not update the > svn metadata, unfortunately, by using git-svn rebase -l (I used your > branch on github and the instructions on matplotlib website). It gives > me an awful lot of merging errors, which seems to indicate that git-svn > is confused about the current state, > > > > I have trouble with that too. :( Do you have notes on how you setup the numpy git repo? I was never able to figure out the way to make a good git clone that could be shared with others. >>> OK, I think I fixed the git mirror. The good news is that things should >>> work just like your scipy svn git mirror. The bad news is that I moved >>> the master branch to "old-master-broken-svn-import", so you'll probably >>> have to rebase all your changes. The new git branch to base off is >>> "trunk", which is a mirror of the svn trunk. MPL's svn layout doesn't >>> follow the standard svn repository, so I haven't mirrored other branches >>> (yet). I'll update the MPL dev docs soon. >>> >>> >>> >> FWIW, I have tried importing the whole svn repo, and the repo got might >> big (~700 Mb) - I guess because of all the things in trunk but not in >> trunk/matplotlib. >> >> > OK, I'm rebuilding a repo with the branches and tags myself as we speak. > It's been going over 2 hours on a local rsync on a screaming fast > computer. It took ~ 10 hours on a 4 years-old machine :) > If this does import reasonably, would it be a real pain for > you to rebase again? Not really, I export the branch with format-patch and import with git am, so it takes me less time than writing this very sentence :) >> >> > OK. Actually, the trigger that started all my git work is that something > broke with the old import anyway. Git thought one of the more recent svn > commits was parented to a commit months ago, so everything was broken > anyway. The new import is much better -- for the first time I managed to > be able to share the svn meta data across git clones. > Yes, that's the main point of the numpy/scipy mirrors - Pauli did the work with his git-svn-automirror (which is something you may want to look at if you want an automatic mirror). cheers, David -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] proposed change to colors.py
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.
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')])
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
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:[email protected]]
>> 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.
>
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Reinier Heeres
Tel: +31 6 10852639
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Comparing pdf output in tests
On Fri, Oct 2, 2009 at 12:27 AM, Andrew Straw wrote: > I just installed gs on one of the buildbots -- so at least the .pdf > generation should get tested on one machine. (The one running the py24 > and py25 tests.) The OSX build bot has been down ever since the build machine was upgraded to 10.6. Unfortunately, this has triggered some build and runtime problems for mpl that I haven't been able to crack yet. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Comparing pdf output in tests
Jouni K. Seppänen wrote: > Andrew Straw writes: > > >> This test function is a generator that nose will then generate two test >> cases out of. So, perhaps the image_comparison decorator could be >> changed to become a generator? I'm not 100% sure it will work, but I >> don't see why it won't. If it does work, I think this is a good idea. >> > > It seems to have worked. The build slave with gs shows 65 tests with 2 > known failures, and the one without gs shows 30 known failures: > > http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64/builds/167/steps/test/logs/stdio > http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20no%20dvipng%2C%20no%20latex/builds/91/steps/test/logs/stdio > > Great -- I think this is nice from a test-writer perspective, and I think it tests just what we want to test -- the appearance of the pdfs. I think this idea could be easily extended to the ps format and, if inkscape was installed, we could use the --export-png option to test svg. Thanks, Andrew -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] proposed change to colors.py
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
> 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:[email protected]]
>>> 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.
>>
>>
>> --
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] doc/make.py clean
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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] basedir
Hi, setupext.py contains a basedir directory. Please add there 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc', 'gnukfreebsd7', 'gnukfreebsd8'. It would be nice, if matplotlib had an option to disable '/usr/local'. This would be useful for distributions. The Debian patch attached (does both). Cheers, Benjamin 10_build_fix.dpatch Description: application/shellscript -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Guessing directory for Tcl/Tk
Hi, Guess the correct directory in Debian/Ubuntu fails. Replacing all tcl by tk does not lead to a correct directory: /usr/share/tcltk/tcl8.5 -> /usr/share/tktk/tk8.5 The correct directory is /usr/share/tcltk/tk8.5 A patch is attached. Cheers, Benjamin 05-find-tcl-tk-directory.dpatch Description: application/shellscript signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basedir
Benjamin Drung wrote: > Hi, > > setupext.py contains a basedir directory. Please add there > 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc', > 'gnukfreebsd7', 'gnukfreebsd8'. > > It would be nice, if matplotlib had an option to disable '/usr/local'. > This would be useful for distributions. > > The Debian patch attached (does both). I'm not sure I understand this. The patch seems to remove /usr/local from the list. Why do you want to do this? I am assuming the original idea was that if a user wants to build a version of a library and put it in /usr/local, then that is what mpl should use; if it is not found there, then use the distro version in /usr. This seems to me like the right strategy, so I am reluctant to apply your patch as-is. Eric > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basedir
Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing:
> Benjamin Drung wrote:
> > Hi,
> >
> > setupext.py contains a basedir directory. Please add there
> > 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
> > 'gnukfreebsd7', 'gnukfreebsd8'.
> >
> > It would be nice, if matplotlib had an option to disable '/usr/local'.
> > This would be useful for distributions.
> >
> > The Debian patch attached (does both).
>
> I'm not sure I understand this. The patch seems to remove /usr/local
> from the list. Why do you want to do this? I am assuming the original
> idea was that if a user wants to build a version of a library and put it
> in /usr/local, then that is what mpl should use; if it is not found
> there, then use the distro version in /usr. This seems to me like the
> right strategy, so I am reluctant to apply your patch as-is.
Ok, attached a patch which adds support for other architectures.
The Debian/Ubuntu package should be build against the distro versions of
the libraries. The Debian/Ubuntu package should not link to packages
in /usr/local. Therefore we want to disable it for building the package.
It would be nice, if you can add an --disable-usr-local for distro
maintainers. With this option set, '/usr/local' will be stripped from
basedir.
Cheers,
Benjamin
diff -pruN matplotlib-0.99.1.1/setupext.py matplotlib-0.99.1.1.new/setupext.py
--- matplotlib-0.99.1.1/setupext.py 2009-10-05 22:57:17.253438212 +0200
+++ matplotlib-0.99.1.1.new/setupext.py 2009-10-06 00:56:57.809438760 +0200
@@ -47,6 +47,10 @@ import subprocess
basedir = {
'win32' : ['win32_static',],
+'linux2-alpha' : ['/usr/local', '/usr'],
+'linux2-hppa' : ['/usr/local', '/usr'],
+'linux2-mips' : ['/usr/local', '/usr'],
+'linux2-sparc' : ['/usr/local', '/usr'],
'linux2' : ['/usr/local', '/usr'],
'linux' : ['/usr/local', '/usr',],
'cygwin' : ['/usr/local', '/usr',],
@@ -65,6 +69,8 @@ basedir = {
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
'gnukfreebsd5' : ['/usr/local', '/usr'],
'gnukfreebsd6' : ['/usr/local', '/usr'],
+'gnukfreebsd7' : ['/usr/local', '/usr'],
+'gnukfreebsd8' : ['/usr/local', '/usr'],
'aix5' : ['/usr/local'],
}
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basedir
Benjamin Drung wrote: > Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing: >> Benjamin Drung wrote: >>> Hi, >>> >>> setupext.py contains a basedir directory. Please add there >>> 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc', >>> 'gnukfreebsd7', 'gnukfreebsd8'. >>> >>> It would be nice, if matplotlib had an option to disable '/usr/local'. >>> This would be useful for distributions. >>> >>> The Debian patch attached (does both). >> I'm not sure I understand this. The patch seems to remove /usr/local >> from the list. Why do you want to do this? I am assuming the original >> idea was that if a user wants to build a version of a library and put it >> in /usr/local, then that is what mpl should use; if it is not found >> there, then use the distro version in /usr. This seems to me like the >> right strategy, so I am reluctant to apply your patch as-is. > > Ok, attached a patch which adds support for other architectures. Applied, thank you. > > The Debian/Ubuntu package should be build against the distro versions of > the libraries. The Debian/Ubuntu package should not link to packages > in /usr/local. Therefore we want to disable it for building the package. > > It would be nice, if you can add an --disable-usr-local for distro > maintainers. With this option set, '/usr/local' will be stripped from > basedir. It looks like it would be very easy to add this as an option to be set in setup.cfg; is this adequate? I don't know how to do it easily via a command-line option because those options are processed by distutils.core.setup(), so as far as I can see, they are not directly available to setup.py or setupext.py, short of adding our own layer of command-line processing. Eric > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basedir
Am Montag, den 05.10.2009, 13:36 -1000 schrieb Eric Firing: > Benjamin Drung wrote: > > Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing: > >> Benjamin Drung wrote: > >>> Hi, > >>> > >>> setupext.py contains a basedir directory. Please add there > >>> 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc', > >>> 'gnukfreebsd7', 'gnukfreebsd8'. > >>> > >>> It would be nice, if matplotlib had an option to disable '/usr/local'. > >>> This would be useful for distributions. > >>> > >>> The Debian patch attached (does both). > >> I'm not sure I understand this. The patch seems to remove /usr/local > >> from the list. Why do you want to do this? I am assuming the original > >> idea was that if a user wants to build a version of a library and put it > >> in /usr/local, then that is what mpl should use; if it is not found > >> there, then use the distro version in /usr. This seems to me like the > >> right strategy, so I am reluctant to apply your patch as-is. > > > > Ok, attached a patch which adds support for other architectures. > > Applied, thank you. Thanks. > > The Debian/Ubuntu package should be build against the distro versions of > > the libraries. The Debian/Ubuntu package should not link to packages > > in /usr/local. Therefore we want to disable it for building the package. > > > > It would be nice, if you can add an --disable-usr-local for distro > > maintainers. With this option set, '/usr/local' will be stripped from > > basedir. > > It looks like it would be very easy to add this as an option to be set > in setup.cfg; is this adequate? Yes, that's equivalent. > I don't know how to do it easily via a command-line option because those > options are processed by distutils.core.setup(), so as far as I can see, > they are not directly available to setup.py or setupext.py, short of > adding our own layer of command-line processing. Implement what you like more. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] proposed change to colors.py
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
>> 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:[email protected]]
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.
>>>
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] proposed change to colors.py
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 matplotli
