matplotlib-devel Mailing List for matplotlib (Page 5)

On Sat, Sep 17, 2011 at 7:01 PM, Benjamin Root <ben...@ou...> wrote:
> Agreed. Let's declare a feature freeze at this point. Unless you already
> have a pull, no new features, and even those with existing pulls need to be
> carefully considered. I already have to make some updates to the "what's
> new" section...
While you are working on 'what's new" could you consider adding a
section on the new sankey module and maybe inline one example from the
api/sankey_demo.py? I think they are pretty snazzy.
https://github.com/matplotlib/matplotlib/pull/465
JDH

On Saturday, September 17, 2011, John Hunter <jd...@gm...> wrote:
> On Sat, Sep 17, 2011 at 4:08 PM, Benjamin Root <ben...@ou...> wrote:
>> I think it will take a declaration of a firm deadline. How about this?
>>
>> Cut RC release Friday, Sept 23rd
>> Release v1.1.0 Friday, Sept. 30th.
>> (Barring any major significant changes)
>
> Works for me; should we branch on the rc cut or before? I suggest we
> branch on the cut,
Agreed. We still have some pull requests that point to master. If we
branch before the cut, re-pulling just delays things.
> but don't merge anything in before the 23rd that is
> not release ready (eg Ben when you advised holding off on the
> projection merge because it touched hairy parts of the code).
Agreed. Let's declare a feature freeze at this point. Unless you already
have a pull, no new features, and even those with existing pulls need to be
carefully considered. I already have to make some updates to the "what's
new" section...
Ben Root

On Sat, Sep 17, 2011 at 4:08 PM, Benjamin Root <ben...@ou...> wrote:
> I think it will take a declaration of a firm deadline. How about this?
>
> Cut RC release Friday, Sept 23rd
> Release v1.1.0 Friday, Sept. 30th.
> (Barring any major significant changes)
Works for me; should we branch on the rc cut or before? I suggest we
branch on the cut, but don't merge anything in before the 23rd that is
not release ready (eg Ben when you advised holding off on the
projection merge because it touched hairy parts of the code).

On 9/17/2011 2:08 PM, Benjamin Root wrote:
> I think it will take a declaration of a firm deadline. How about this?
>
> Cut RC release Friday, Sept 23rd
> Release v1.1.0 Friday, Sept. 30th.
> (Barring any major significant changes)
>
> In particular, for the RC, I want to make sure that installation and
> documents for the installation is solid. I will have on hand an older,
> stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
> Leopard (one is 32 bits while the other is 64, I think).
>
> As a side note, the macbook can be used for automated build/test machine
> as it really isn't useful for anything else for me.
>
> Ben Root
>
That sounds to me as if the master branch is at release quality, or very 
close to. I could test it on Windows this weekend if that's true.
Christoph

I think it will take a declaration of a firm deadline. How about this?
Cut RC release Friday, Sept 23rd
Release v1.1.0 Friday, Sept. 30th.
(Barring any major significant changes)
In particular, for the RC, I want to make sure that installation and
documents for the installation is solid. I will have on hand an older,
stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
Leopard (one is 32 bits while the other is 64, I think).
As a side note, the macbook can be used for automated build/test machine as
it really isn't useful for anything else for me.
Ben Root

What will it take to get a release out, so that debian, ubuntu, etc. can 
have something better than 1.0.1? And so that the python 3 merge can 
take place?
Eric

>> As a bit of a selfish interest, I think your approach might open up a possible approach for a long-standing problem 
>> of mine with 3d projections. Axes3D objects >> want to fill its entire plot box, but when created through a subplot
>> mechanism, the defaults get over-ridden. I wonder if this approach with _init_axes() passing kwargs might 
>> provide me with the hook to fix this.
Yes, having the _init_axes method makes subclassing then initialising an Axes much easier, and avoids the need to make an intermediate class for each Axes construction.
>> Hmm, interesting idea. I took a quick look through the code, 
and it touches on some fragile parts of axes.py, so I wouldn't be
>> comfortable with this being in v1.1.0, but I think it is definitely worthy of further investigation.
I was wondering if you see axes.py changing significantly in the near future? If not then it would seem a shame to hold back this relatively small change for something not yet in the pipeline. 
Perhaps you could elaborate on what you feel to be the more fragile aspects and we could start to look to resolve these as a seperate development activity?
Thanks again,
 		 	 		 

On Thu, Sep 15, 2011 at 1:19 PM, Phil Elson <phi...@ho...> wrote:
> Hi,
>
> I would like the ability to setup a plot projection in MPL that can be
> defined by various parameters and does not need to be serialised as a string
> and registered with *matplotlib.projections.register_projection*. For
> example, an extension of /examples/api/custom_projection_example.py might be
> to add the ability to define the central meridian to an arbitrary value
> rather than the current value of 0 - in this case I would expect to define
> the projection by creating an object which can then be turned into a
> matplotlib axes:
>
> *hammer_proj = Hammer(central_meridian=45)
> ax = plt.subplot(111, projection=hammer_proj)
> *
>
>
> I have made a change to matplotlib which would enable this capability,
> which can be found at
> https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e499. Any feedback and thoughts would be really appreciated with the ultimate
> goal of getting this functionality into MPL.
>
> Many Thanks,
>
> Philip
>
>
Hmm, interesting idea. I took a quick look through the code, and it touches
on some fragile parts of axes.py, so I wouldn't be comfortable with this
being in v1.1.0, but I think it is definitely worthy of further
investigation.
As a bit of a selfish interest, I think your approach might open up a
possible approach for a long-standing problem of mine with 3d projections.
Axes3D objects want to fill its entire plot box, but when created through a
subplot mechanism, the defaults get over-ridden. I wonder if this approach
with _init_axes() passing kwargs might provide me with the hook to fix this.
Ben Root

Sorry, that link was bad, it should have read:
https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e4
To: mat...@li...
Date: 2011年9月15日 18:19:49 +0000
Subject: [matplotlib-devel] Initialising projections in matplotlib
Hi, 
I would like the ability to setup a plot projection in MPL that can be defined by various parameters and does not need to be serialised as a string and registered with matplotlib.projections.register_projection. For example, an extension of /examples/api/custom_projection_example.py might be to add the ability to define the central meridian to an arbitrary value rather than the current value of 0 - in this case I would expect to define the projection by creating an object which can then be turned into a matplotlib axes:
hammer_proj = Hammer(central_meridian=45)
ax = plt.subplot(111, projection=hammer_proj)
I have made a change to matplotlib which would enable this capability, which can be found at https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e499 . Any feedback and thoughts would be really appreciated with the ultimate goal of getting this functionality into MPL.
Many Thanks,
Philip
 		 	 		 
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel 		 	 		 

On Thu, Sep 15, 2011 at 1:19 PM, Phil Elson <phi...@ho...> wrote:
> I have made a change to matplotlib which would enable this capability, which
> can be found at
> https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e499
> . Any feedback and thoughts would be really appreciated with the ultimate
> goal of getting this functionality into MPL.
I'm getting a 404 error when I try that URL. The preferred method of
contribution is to submit a pull request
http://matplotlib.sourceforge.net/devel/gitwash/development_workflow.html#asking-for-your-changes-to-be-merged-into-the-main-repo

Hi, 
I would like the ability to setup a plot projection in MPL that can be defined by various parameters and does not need to be serialised as a string and registered with matplotlib.projections.register_projection. For example, an extension of /examples/api/custom_projection_example.py might be to add the ability to define the central meridian to an arbitrary value rather than the current value of 0 - in this case I would expect to define the projection by creating an object which can then be turned into a matplotlib axes:
hammer_proj = Hammer(central_meridian=45)
ax = plt.subplot(111, projection=hammer_proj)
I have made a change to matplotlib which would enable this capability, which can be found at https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e499 . Any feedback and thoughts would be really appreciated with the ultimate goal of getting this functionality into MPL.
Many Thanks,
Philip
 		 	 		 

> In article 
> <CANNq6Fksj9QgnRPE8jFp_3hnpkQ9647EFUPasUgLB3CgrCik0w@...>,
> Benjamin Root <ben.root@...> wrote:
> 
>> Ok, there has been a lot of useful discussion (for both MacOSX and Windows),
>> but in the end, I want to know this: Is it possible for matplotlib to
>> provide a single, recommended, fully-supported-by-us method for installing
>> our package (possibly for each platform?). Could it be pip? Or some other
>> option?
> 
> I think we'll always need to be able to install from source and also 
> offer a binary on MacOS X.
> 
> * Build from source.
> 
> If your version of MacOS X is recent enough then building from source 
> could easily be made to work (with a few minor changes to setupext.py). 
> Most other projects have managed this. I may be able to find some time 
> to work on this.
> 
> On the good side it would work with nearly any python build and it means 
> any user can install matplotlib in the obvious fashion. For these 
> reasons I think this is very much worth doing. However, it has some 
> disadvantages:
> - It requires that users install XCode
> - I don't think the resulting build will work with older versions of 
> MacOS X, because Apple's libraries aren't backward compatible. This 
> means the user will run into unexpected difficulty if they build and 
> distribute a bundled application. This is a serious problem and means 
> that users must have a binary installer option:
> 
> -- Russell
A while ago, I posted a Makefile [1] that installs matplotlib (together with NumPy and SciPy) on Mac OS X 10.6 Snow Leopard without downloading any additional libraries (except from gfortran). Xcode (and Python) are the only dependencies.
I just tried to install the current github master on Mac OS X 10.7 Lion (with a self-built Python 2.7.2) and it still works:
 export MACOSX_DEPLOYMENT_TARGET=10.7
 export ARCHFLAGS=-arch x86_64
 export CFLAGS="${ARCHFLAGS} -I/usr/X11/include -I/usr/X11/include/freetype2 -isysroot /Developer/SDKs/MacOSX${MACOSX_DEPLOYMENT_TARGET}.sdk"
 export LDFLAGS="-Wall -undefined dynamic_lookup -bundle ${ARCHFLAGS} -L/usr/X11/lib -syslibroot,/Developer/SDKs/MacOSX${MACOSX_DEPLOYMENT_TARGET}.sdk"
 python setup.py build
 sudo python setup.py install
This should make it quite easy to let matplotlib be installed via "pip install matplotlib".
Cheers,
Stefan
[1] http://stefan.sofa-rockers.org/2010/11/17/building-numpy-scipy-matplotlib-python-27-snow-leo/

On Tue, Sep 13, 2011 at 1:11 PM, Eric Firing <ef...@ha...> wrote:
> On 09/13/2011 02:19 AM, Pim Schellart wrote:
> > Dear Eric (and other developers),
> >
> > I have implemented the requested changes and the resulting diff can be
> > seen at
> https://github.com/pschella/matplotlib/compare/master...cubehelix
> > I tried to do a better job at documentation and hope this is
> > sufficient, let me know if something is missing.
>
> Pim,
>
> I haven't tried it yet, but the code looks nice! Go ahead and click
> your "pull request" button so that it shows up on the main matplotlib
> repo list of pull requests.
>
> > I'm not sure exactly what you meant with your suggestion to define
> > named functions inside the main function body but I hope my new
> > implementation more closely matches your wishes.
>
> It does. I did not recognize that only a single function was needed.
>
> > I have opted for a factory function within the main function to avoid
> > the code duplication associated with creating a named function for
> > each color component.
>
> Good!
>
> Eric
>
>
We shouldn't forget to add mention of this new colormap to the What's New
page.
Ben Root

On 09/13/2011 02:19 AM, Pim Schellart wrote:
> Dear Eric (and other developers),
>
> I have implemented the requested changes and the resulting diff can be
> seen at https://github.com/pschella/matplotlib/compare/master...cubehelix
> I tried to do a better job at documentation and hope this is
> sufficient, let me know if something is missing.
Pim,
I haven't tried it yet, but the code looks nice! Go ahead and click 
your "pull request" button so that it shows up on the main matplotlib 
repo list of pull requests.
> I'm not sure exactly what you meant with your suggestion to define
> named functions inside the main function body but I hope my new
> implementation more closely matches your wishes.
It does. I did not recognize that only a single function was needed.
> I have opted for a factory function within the main function to avoid
> the code duplication associated with creating a named function for
> each color component.
Good!
Eric
>
> Kind regards,
>
> Pim Schellart
>
> P.S. Sorry for submitting the patch directly on the mailing list
> before, I simply followed the link on how to contribute from the
> matplotlib FAQ and didn't look at what was stated above the section
> scrolled to automatically (maybe something to change).
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs& more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Dear Sameer,
I had a quick look at the paper and this scheme seems useful as well.
I'm willing to implement the general conversion functions for this
scheme as well if and when I have some time left.
But only after cubehelix is approved so I know what the format should be.
If you already have code to do it that would be even better of course.
Kind regards,
Pim Schellart

Dear Eric (and other developers),
I have implemented the requested changes and the resulting diff can be
seen at https://github.com/pschella/matplotlib/compare/master...cubehelix
I tried to do a better job at documentation and hope this is
sufficient, let me know if something is missing.
I'm not sure exactly what you meant with your suggestion to define
named functions inside the main function body but I hope my new
implementation more closely matches your wishes.
I have opted for a factory function within the main function to avoid
the code duplication associated with creating a named function for
each color component.
Kind regards,
Pim Schellart
P.S. Sorry for submitting the patch directly on the mailing list
before, I simply followed the link on how to contribute from the
matplotlib FAQ and didn't look at what was stated above the section
scrolled to automatically (maybe something to change).

On 07/18/2011 07:07 AM, Sameer Grover wrote:
> I came across this website where different colormaps have been compared
> and the author has come up with an optimal colormap for data
> visualization called the "cool-warm colormap".
>
> http://www.cs.unm.edu/~kmorel/documents/ColorMaps/index.html
>
> It is somewhat similar to the cool colormap already included in
> matplotlib, but I've added the new colormap to matplotlib in the patch
> attached in case it is deemed fit to be included in the matplotlib source.
>
> Regards,
> Sameer
Sameer,
We should include this, but I think the 257-entry version is overkill; 
it adds a big chunk to the _cm.py file, and I doubt it is visually 
distinguishable from the 33-entry version. Would you mind providing a 
patch for the latter? (Or better yet, the functions that generate the 
r,g,b values.)
Thank you.
Eric
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
Thanks for the newly added plt.tight_layout function to the master mpl
branch. This saves me from manually adjusting the spacing around the figure
canvas each time I need to use the full available figure space. For this I
was switching from Qt4Agg to WXAgg backend, so that I was able to read
right/left/top/bottom/hspace/wspace parameters numerically and then feed
into plt.subplot_adjust function. I guess there is no need for this long
path with the addition of this new adjuster function.
-- 
Gökhan

On 9/12/2011 10:35 AM, Benjamin Root wrote:
> On Fri, Sep 9, 2011 at 9:51 AM, Pim Schellart <P.S...@as...
> <mailto:P.S...@as...>> wrote:
>
> Dear Developers,
>
> In the field of Astronomy (and in science in general) we often make
> images that represent the intensity of some source.
> However the color schemes used to display images are not perceived as
> increasing monotonically in brightness.
> D.A. Green developed a color scheme that does increase monotonically
> in brightness and this scheme is already in use in several data
> display packages (e.g. CASA and AIPS, two software packages used to
> analyze radio astronomy data).
> The paper describing this algorithm can be found here
> http://arxiv.org/abs/1108.5083
> The main advantage of this color map is that images will look
> monotonically increasing in brightness to the eye both on color screen
> and when printed in black and white (as is often needed for scientific
> papers).
> Attached is a patch for _cm.py to add this colormap (named cubehelix
> as it is named in CASA) to the list of matplotlib colormaps.
>
> Complicating this a bit is the fact that the algorithm takes several
> parameters as specified in the paper referred to (start color, number
> of rotations, hugh parameter and gamma factor).
> These parameters are now set to the values they have in the default
> CASA color map but ideally they could be changed by the user.
> I could not find any other colormap that has this option so I don't
> know what the preffered way of doing this is, therefore I left the
> values hardcoded which should be ok for most applications anyway.
> Please let me know what you think.
>
> Kind regards,
>
> Pim Schellart
>
>
> Do we want to add this colormap in the upcoming release, or do we want
> to wait for the next release?
>
> Ben Root
>
Please also consider adding the "coolwarm" color map suggested before by 
Sameer Grover 
<http://sourceforge.net/mailarchive/message.php?msg_id=27816391>. That 
message has a patch attached.
The colormap is used by Kitware (ParaView) and was designed around these 
requirements:
"""
– The map yields images that are aesthetically pleasing.
– The map has a maximal perceptual resolution.
– Interference with the shading of 3D surfaces is minimal.
– The map is not sensitive to vision deficiencies.
– The order of the colors should be intuitively the same for all people.
– The perceptual interpolation matches the underlying scalars of the map.
"""
<http://www.cs.unm.edu/~kmorel/documents/ColorMaps/index.html>
Thank you,
Christoph

On 09/09/2011 04:51 AM, Pim Schellart wrote:
> Dear Developers,
>
> In the field of Astronomy (and in science in general) we often make
> images that represent the intensity of some source.
> However the color schemes used to display images are not perceived as
> increasing monotonically in brightness.
> D.A. Green developed a color scheme that does increase monotonically
> in brightness and this scheme is already in use in several data
> display packages (e.g. CASA and AIPS, two software packages used to
> analyze radio astronomy data).
> The paper describing this algorithm can be found here
> http://arxiv.org/abs/1108.5083
> The main advantage of this color map is that images will look
> monotonically increasing in brightness to the eye both on color screen
> and when printed in black and white (as is often needed for scientific
> papers).
> Attached is a patch for _cm.py to add this colormap (named cubehelix
> as it is named in CASA) to the list of matplotlib colormaps.
>
> Complicating this a bit is the fact that the algorithm takes several
> parameters as specified in the paper referred to (start color, number
> of rotations, hugh parameter and gamma factor).
> These parameters are now set to the values they have in the default
> CASA color map but ideally they could be changed by the user.
> I could not find any other colormap that has this option so I don't
> know what the preffered way of doing this is, therefore I left the
> values hardcoded which should be ok for most applications anyway.
> Please let me know what you think.
Adding this colormap would be good, but I would much prefer to see it 
done in a more general and readable fashion, with a docstring including 
some explanation and a citation with link to the reference. (A little 
editing of your message above would take care of it.)
I would suggest making a "cubehelix" function, taking the colormap 
parameters as kwargs with the present defaults, and returning the 
dictionary. The lambda functions can be replaced with named functions 
nested in the main function. Line lengths should be no greater than 80 
characters.
The _cubehelix_data would then be created by a call to the function.
I think that this re-arrangement and documentation could be done very 
easily and quickly, and would make the contribution much nicer. It 
would also leave in place the mechanism for a user to create a variation 
of the cubehelix; the cubehelix function could be imported into the cm 
namespace, so that one could make a custom data dictionary for use in 
register_cmap.
Submission via github would be nice, but is not required.
Eric
>
> Kind regards,
>
> Pim Schellart
>

On Fri, Sep 9, 2011 at 9:51 AM, Pim Schellart <P.S...@as...>wrote:
> Dear Developers,
>
> In the field of Astronomy (and in science in general) we often make
> images that represent the intensity of some source.
> However the color schemes used to display images are not perceived as
> increasing monotonically in brightness.
> D.A. Green developed a color scheme that does increase monotonically
> in brightness and this scheme is already in use in several data
> display packages (e.g. CASA and AIPS, two software packages used to
> analyze radio astronomy data).
> The paper describing this algorithm can be found here
> http://arxiv.org/abs/1108.5083
> The main advantage of this color map is that images will look
> monotonically increasing in brightness to the eye both on color screen
> and when printed in black and white (as is often needed for scientific
> papers).
> Attached is a patch for _cm.py to add this colormap (named cubehelix
> as it is named in CASA) to the list of matplotlib colormaps.
>
> Complicating this a bit is the fact that the algorithm takes several
> parameters as specified in the paper referred to (start color, number
> of rotations, hugh parameter and gamma factor).
> These parameters are now set to the values they have in the default
> CASA color map but ideally they could be changed by the user.
> I could not find any other colormap that has this option so I don't
> know what the preffered way of doing this is, therefore I left the
> values hardcoded which should be ok for most applications anyway.
> Please let me know what you think.
>
> Kind regards,
>
> Pim Schellart
>
>
Do we want to add this colormap in the upcoming release, or do we want to
wait for the next release?
Ben Root

ESCO 2012 - European Seminar on Coupled Problems
=================================================
ESCO2012 http://esco2012.femhub.com/ is the 3rd event in a series of
interdisciplineary meetings dedicated to computational science challenges
in multi-physics and PDEs.
I was invited as ESCO last year. It was an aboslute pleasure, because it
is a small conference that is very focused on discussions. I learned a
lot and could sit down with people who code top notch PDE libraries such
as FEniCS and have technical discussions. Besides, it is hosted in the
historical brewery where the Pilsner was invented. Plenty of great beer.
Application areas
------------------
Theoretical results as well as applications are welcome. Application
areas include, but are not limited to: Computational electromagnetics,
Civil engineering, Nuclear engineering, Mechanical engineering,
Computational fluid dynamics, Computational geophysics, Geomechanics and
rock mechanics, Computational hydrology, Subsurface modeling,
Biomechanics, Computational chemistry, Climate and weather modeling, Wave
propagation, Acoustics, Stochastic differential equations, and
Uncertainty quantification.
Minisymposia
* Multiphysics and Multiscale Problems in Civil Engineering
* Modern Numerical Methods for ODE
* Porous Media Hydrodynamics
* Nuclear Fuel Recycling Simulations
* Adaptive Methods for Eigenproblems
* Discontinuous Galerkin Methods for Electromagnetics
* Undergraduate Projects in Technical Computing
Software afternoon
-------------------
Important part of each ESCO conference is a software afternoon featuring
software projects by participants. Presented can be any computational
software that has reached certain level of maturity, i.e., it is used
outside of the author's institution, and it has a web page and a user
documentation. 
Proceedings
-----------
For each ESCO we strive to reserve a special issue of an international
journal with impact factor. Proceedings of ESCO 2008 appeared in Math.
Comput. Simul., proceedings of ESCO 2010 in CiCP and Appl. Math. Comput.
Proceedings of ESCO 2012 will appear in Computing.
Important Dates
* December 15, 2011: Abstract submission deadline.
* December 15, 2011: Minisymposia proposals.
* January 15, 2012: Notification of acceptance.
PyHPC: Python for High performance computing
--------------------------------------------
If you are doing super computing, SC11, (
http://sc11.supercomputing.org/) the Super Computing conference is the
reference conference. This year there will a workshop on high performance
computing with Python: PyHPC
(http://www.dlr.de/sc/desktopdefault.aspx/tabid-1183/1638_read-31733/).
At the scipy conference, I was having a discussion with some of the
attendees on how people often still do process management and I/O with
Fortran in the big computing environment. This is counter productive.
However, has success stories of supercomputing folks using high-level
languages are not advertized, this is bound to stay. Come and tell us
how you use Python for high performance computing!
Topics
* Python-based scientific applications and libraries
* High performance computing
* Parallel Python-based programming languages
* Scientific visualization
* Scientific computing education
* Python performance and language issues
* Problem solving environments with Python
* Performance analysis tools for Python application
Papers
We invite you to submit a paper of up to 10 pages via the submission
site. Authors are encouraged to use IEEE two column format.
Important Dates
* Full paper submission: September 19, 2011
* Notification of acceptance: October 7, 2011
* Camera-ready papers: October 31, 2011

On Fri, Sep 9, 2011 at 14:50, Jeff Whitaker <js...@fa...> wrote:
> On 9/2/11 1:33 AM, Sandro Tosi wrote:
>>
>> Hello,
>> I'm trying to download basemap examples tarball from SF but it seems
>> to be corrupted - could you confirm/fix it?
>>
>> Thanks,
>
> Should be fixed now.
Yes indeed, thanks! Just a side note: there's a lot of ._* files in
the tarball (I think they are some sort of Mac OS backup files or os);
they are not a problem but are kinda useless so it might be nice to
remove them altogether.
Thanks,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I'm not sure if it's true to every install, but my m*atplotlibrc * was
missing a section.
Looking at *matplotlibrc.template* we have a section:
# If you are using the Qt4Agg backend, you can choose here
# to use the PyQt4 bindings or the newer PySide bindings to
# the underlying Qt4 toolkit.
#backend.qt4 : PyQt4 # PyQt4 | PySide
Adding and configuring this section to my *matplotlibrc* solved it...
Not sure if it's a bug on installation process... Any Ideas?
Atenciosamente,
Tiago Ferreira Bonetti
On Thu, Sep 8, 2011 at 11:00 PM, Eric Firing <ef...@ha...> wrote:
> On 09/08/2011 03:53 PM, Tiago Bonetti wrote:
> > I'm new to github, so forgive me if I'm a litlle lost.
> > I have the most recent master branch from github matplotlib
> > <https://github.com/matplotlib> / matplotlib
> > <https://github.com/matplotlib/matplotlib> public repository...
> > I would like to help testing, yet i cant find the dev branch.
>
> It is what you have, the master branch.
>
> Eric
>
> >
> > Thanks,
> > Tiago Ferreira Bonetti
> >
> >
> > On Thu, Sep 8, 2011 at 10:27 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> >
> >
> > On Thursday, September 8, 2011, Tiago Bonetti
> > <tia...@gm... <mailto:tia...@gm...>> wrote:
> > > I was trying for dome time to use the Pyside Backend (qt4Agg with
> > pySide), with no success, but after reading the beckend code I've
> > finally made it.
> > > After installing the 1.0.1 version on my Ubuntu, I've noticed the
> > installation doesn't check for pySide what is strange yet, not the
> > point here...
> > > The trick was quite simple, forcing the QtGui and QtCore to be
> > declared from pySide module. This is done inside qt4_compat.py
> > checking for the string inside: rcParams['backend.qt4'].
> > > This dictionary I don't know where It comes from, so, just
> > altering during runtime was enough to make the example
> > "embedding_in_qt4.py" work.
> > > There is any better way to choose between pySide and pyQt?
> > Couldn't they be separated in to individual backends?
> > > Yet I understand this information is not easily available on the
> > Internet, so i'm trying to share it.
> > > Thanks,
> > > Tiago Ferreira Bonetti
> > >
> >
> > Tiago,
> >
> > Have you had a chance to look at the code in the latest
> > developmental branch? There was some work over the summer on this,
> > and I think it is largely resolved, but testing would be appreciated.
> >
> > Cheers!
> > Ben Root
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Why Cloud-Based Security and Archiving Make Sense
> > Osterman Research conducted this study that outlines how and why cloud
> > computing security and archiving is rapidly being adopted across the IT
> > space for its ease of implementation, lower cost, and increased
> > reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Dear Developers,
In the field of Astronomy (and in science in general) we often make
images that represent the intensity of some source.
However the color schemes used to display images are not perceived as
increasing monotonically in brightness.
D.A. Green developed a color scheme that does increase monotonically
in brightness and this scheme is already in use in several data
display packages (e.g. CASA and AIPS, two software packages used to
analyze radio astronomy data).
The paper describing this algorithm can be found here
http://arxiv.org/abs/1108.5083
The main advantage of this color map is that images will look
monotonically increasing in brightness to the eye both on color screen
and when printed in black and white (as is often needed for scientific
papers).
Attached is a patch for _cm.py to add this colormap (named cubehelix
as it is named in CASA) to the list of matplotlib colormaps.
Complicating this a bit is the fact that the algorithm takes several
parameters as specified in the paper referred to (start color, number
of rotations, hugh parameter and gamma factor).
These parameters are now set to the values they have in the default
CASA color map but ideally they could be changed by the user.
I could not find any other colormap that has this option so I don't
know what the preffered way of doing this is, therefore I left the
values hardcoded which should be ok for most applications anyway.
Please let me know what you think.
Kind regards,
Pim Schellart