matplotlib-devel Mailing List for matplotlib

While going through and updating some scripts to use the new features
that were recently added to hist(), I found myself very confused by
the align keywords - I had to go and look at Manuel Metz's post a
couple weeks ago to believe it wasn't a typo in the documentation...
"center" and "edge" are exactly the opposite of what one would have
thought (as he noted)... I've attached a diff of my proposed solution
- accepting the old keywords for backwards-compatibility, but have the
documentation only mention two keywords that make more sense ('left'
and 'mid').

I've added two other features as well - for some of the histograms I'm
making, it makes sense to have plots that are cumulative from the left
instead of the right - with this patch, that's allowed by passing in
cumulative=-1 (or anything else that is less than 0 - True still
operates the way it did before).  To make this also easier from the
perspective of how some might want the histogram to look, I've also
added a 'right' option to the 'align' keyword.

Hopefully these changes will now satisfy all possible uses that anyone
can imagine for a histogram. :)

On Mon, Jun 2, 2008 at 2:32 PM, John Hunter <jd...@gm...> wrote:

>> http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg
>
> That appears to have a gradient field gray->white on the arrows, which
> we haven't implemented.  But I'd like too...

A bit of acid and the right music on top of that figure, and you can
sell MPL for psychedelic raves :)

Cheers,

f

On Mon, Jun 2, 2008 at 4:32 PM, Christopher Barker
<Chr...@no...> wrote:
> John Hunter wrote:
>> And now that we have spline path elements in mpl98, we can actually
>> implement curved arrows w/o an onerous polygon approximation.
>
> Then could we do this too?
>
> http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg

That appears to have a gradient field gray->white on the arrows, which
we haven't implemented.  But I'd like too...

JDH

John Hunter wrote:
> And now that we have spline path elements in mpl98, we can actually
> implement curved arrows w/o an onerous polygon approximation.

Then could we do this too?

http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg

from:

http://ccom.unh.edu/vislab/projects/FlowVis.html

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Mon, Jun 2, 2008 at 2:42 PM, Fernando Perez <fpe...@gm...> wrote:

> The code is partly GPL (it uses a BSD kd-tree library), so don't go
> looking there.  But the basic ideas sound pretty neat for producing
> very clean-looking vector fields.  It would be neat if mpl grew
> something along these lines...

And now that we have spline path elements in mpl98, we can actually
implement curved arrows w/o an onerous polygon approximation.

JDH

Howdy,

just saw this on the sage list:

http://sview01.wiredworkplace.net/pub/vfplot/index.html

The code is partly GPL (it uses a BSD kd-tree library), so don't go
looking there.  But the basic ideas sound pretty neat for producing
very clean-looking vector fields.  It would be neat if mpl grew
something along these lines...

Cheers


f

John Hunter wrote:
> Hey Michael,
>
> I recently committed a pyplot patch for the switch_backends
> functionality, and when I went to svnmerge it I go the changes for
> your backend_agg fix.  Since I would rather let you handle these, what
> is the best way to back out of the situation I am in.  I guess what I
> would like to do is
>
>   * ignore the backend_agg changes on my end
>
>   * just merge the pyplot changes
>
>   * not screw anything up that you are doing and preserve the merge for you
>
> What is the best way to proceed in this situation?
>   
None of those _backend_agg.cpp changes apply to the trunk.  Just replace _backend_agg.cpp with _backend_agg.cpp.working and commit.  (Or I can do that...)

Cheers,
Mike


Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Jun 2, 2008 at 7:28 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Jun 2, 2008 at 3:26 AM, Fernando Perez <fpe...@gm...> wrote:
>
>> I've added this little bit of code to the default ipython -pylab startup:
>
> The latest releases of pylab already provide np and plt in the pylab namespace.
>
> Would it be better to simply add a "pyplot" mode to ipython to
> encourage the proper usage, and in this mode import only as few
> symbols (np, plt, and sp if possible)?

I'm not sure the duplication is worthwhile (users don't read mailing
lists on weekends, you know?  They have lives and all that :)
Besides, for ipython the 'import *' mode *is* a reasonable use case,
since when you're working interactively, you really just want to type

plot(x,cos(x**2)+sin(x**3))

and not some plt.foo/np.bar contraption.  So I think there remains a
use case for importing all the names in at the top level (remember
that you can configure now ipython to NOT do 'from pylab import *'
anymore if you reall want a clean namespace).

The use case is mostly to provide an environment where the standard
examples and docstrings that may use either numpy or np,
pylab/pyplot/plt are always defined, so users can copy/paste without
fear.

Cheers,

f

Hey Michael,

I recently committed a pyplot patch for the switch_backends
functionality, and when I went to svnmerge it I go the changes for
your backend_agg fix.  Since I would rather let you handle these, what
is the best way to back out of the situation I am in.  I guess what I
would like to do is

  * ignore the backend_agg changes on my end

  * just merge the pyplot changes

  * not screw anything up that you are doing and preserve the merge for you

What is the best way to proceed in this situation?

JDH

Ok.  This should now be fixed in r5358.

Cheers,
Mike

John Hunter wrote:
> On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <md...@st...> wrote:
>
>   
>> We probably want to trap for this case in the C code so it at least
>> doesn't crash, but am I right that "c=''" is an invalid input?  What
>> should that do, if not raise an exception?
>>     
>
> facecolor='' or facecolor='None' in other parts of the code (eg
> Line2D), mean do not fill the marker.  But the principle of least
> surprise, we should probably support this for the polygon collections
> too, unless there is a good reason not to.
> JDH
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Jun 2, 2008 at 3:26 AM, Fernando Perez <fpe...@gm...> wrote:

> I've added this little bit of code to the default ipython -pylab startup:

The latest releases of pylab already provide np and plt in the pylab namespace.

Would it be better to simply add a "pyplot" mode to ipython to
encourage the proper usage, and in this mode import only as few
symbols (np, plt, and sp if possible)?

> it needs a proper docstring.  Just try 'pylab?' vs 'pyplot?'

We can easily add the docstring for the next bug fix release

JDH

On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <md...@st...> wrote:

> We probably want to trap for this case in the C code so it at least
> doesn't crash, but am I right that "c=''" is an invalid input?  What
> should that do, if not raise an exception?

facecolor='' or facecolor='None' in other parts of the code (eg
Line2D), mean do not fill the marker.  But the principle of least
surprise, we should probably support this for the polygon collections
too, unless there is a good reason not to.
JDH

On Mon, Jun 2, 2008 at 8:12 AM, Michael Droettboom <md...@st...> wrote:

> I agree with John -- I think the documentation effort should be focused on
> the trunk.  Now that we have (apparently) such a stable 0.91.3, hopefully
> the maintenance branch will be much less frequently modified anyway.
>  Theoretically, we should only run into merge conflicts related to
> docstrings if the docstrings on the maintenance branch are themselves
> edited.  If we're just going to be doing bugfixes on the branch, that seems
> unlikely.

Up to know, we've been adding features and bugs on the branch and then
merging them in.  Going forward, I think we should just focus on
bug-fixes on the branch and mostly implement a feature-freeze, which
will promote stability and encourage people who want the new stuff
onto the trunk.  We don't have to be fanatical about this -- if there
is a great feature we can put in w/o compromising stability, that's
fine, but I think our default should be bug-fixes only.

JDH

John Hunter wrote:
> On Sat, May 31, 2008 at 9:19 AM, Darren Dale <dar...@co...> wrote:
>   
>> I'll be working on converting docstrings to rest this weekend. Should any of
>> this be done on the branch? Or should we just focus on the trunk?
>>     
>
> As far as I am concerned, the documentation effort is for the trunk.
> The only reason to do them on the branch too is to make merges of
> other code changes easier, which may be a compelling reason.  If the
> docstrings get far out of whack, it may make merging other changes
> very painful.   But at the same time, I don't want the burden of
> trying to keep the two in sync stopping you from getting the work done
> that you need to do.  Maybe you can try it and see how hard it is, and
> if proves to be too much of an impediment, just concentrate on the
> trunk.  Michael, any advice here?
>   
I was away on the weekend, so just getting back.  Darren: you rock.  The 
documentation is looking great!

I agree with John -- I think the documentation effort should be focused 
on the trunk.  Now that we have (apparently) such a stable 0.91.3, 
hopefully the maintenance branch will be much less frequently modified 
anyway.  Theoretically, we should only run into merge conflicts related 
to docstrings if the docstrings on the maintenance branch are themselves 
edited.  If we're just going to be doing bugfixes on the branch, that 
seems unlikely.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

It's giving a floating point exception on the following operation:

  i % Nface

where Nface is the number of face colors, which in this case is 0.

We probably want to trap for this case in the C code so it at least 
doesn't crash, but am I right that "c=''" is an invalid input?  What 
should that do, if not raise an exception?

Cheers,
Mike

Eric Firing wrote:
> Dave wrote:
>   
>> Whilst trying to plot a scatter plot with no facecolor I was able to reliably
>> reproduce a segfault in mpl 0.91.2 - see below:
>>
>> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
>> IPython 0.8.3.svn.r3001 -- An enhanced Interactive Python.
>>
>> In [1]: import matplotlib
>> In [2]: matplotlib.__version__
>> Out[2]: '0.91.2'
>> In [3]: from pylab import scatter, rand
>> In [4]: scatter(rand(100),rand(100),c='')
>> <--SegFault-->
>>
>> That's probably not the right way to do it but it does work in 0.98.0.
>> I'm unable to test on 0.91.3 at the moment.
>>     
>
> On ubuntu hardy with 0.91.3 from the svn maintenance branch:
>
> In [1]:import matplotlib
>
> In [2]:matplotlib.__version__
> Out[2]:'0.91.3'
>
> In [3]:from pylab import scatter, rand
>
> In [4]:scatter(rand(100), rand(100), c='')
> Out[4]:<matplotlib.collections.RegularPolyCollection instance at 0x8edf04c>
>
> In [5]:from pylab import show
>
> In [6]:show()
> Floating point exception
>
> On the svn trunk it works.
>
> Eric
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> 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

Darren Dale wrote:
> On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
>   
>> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
>>     
>>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fpe...@gm...>
>>>       
> I tracked this down by checking the contents of the generated 
> build/latex/Matplotlib.tex, line 954. It is from the following code from 
> mathtext.rst:
>
>   
>> When using the STIX fonts, you also have the choice of:
>>
>>     ================ =================================
>>     Command          Result
>>     ================ =================================
>>     ``\mathbb``      :math:`\mathbb{Blackboard}`
>>     ``\mathcircled`` :math:`\mathcircled{Circled}`
>>     ``\mathfrak``    :math:`\mathfrak{Fraktur}`
>>     ``\mathsf``      :math:`\mathsf{sans-serif}`
>>     ================ =================================
>>     
>
>
> I'm not sure this is being properly rendered in the HTML output for me, 
> either. Mike, are you able to compile this into a pdf on your machine, and if 
> so, would you tell us how to configure STIX support? I commented this block 
> out in svn for now.
>   
Sorry about that.  It requires the amssymb and/or amsmath LaTeX packages 
to render correctly.  Perhaps it is better to not require the LaTeX 
installation to have anything special though.  I think the best course 
of action is to just include pre-generated images in the documentation 
source for this.  I'll go ahead and do that.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Sat, May 24, 2008 at 6:02 PM, Olle Engdegård <ol...@fy...> wrote:
> 
>> I very much miss the 'l' shortcut for toggling log/lin y-scale in the
>> trunk! I use it a lot.
>>
>> I suggest restoring it with something like
>>
>> if self.get_yscale() is ("log" or "linear"):
>>    self.toggle_log_lineary()
>> else: pass
>>
>> I think most of time most people use log or linear scales.
> 
> 
> This seems reasonable, but when I tried to implement it it looked like
> the nan mask for the simple_plot.py example was sticky, eg when I
> toggled back to linear the negative values were still masked.  I tried
> a simpler example still (all positive y data) and got something very
> strange: the plotted y values appear to change on a toggle from log
> and back to linear:
> 
> In [18]: import matplotlib.pyplot as plt
> 
> In [19]: plt.close('all')
> 
> In [20]: ax = plt.subplot(111)
> 
> In [21]: ax.plot(np.random.rand(20))
> Out[21]: [<matplotlib.lines.Line2D object at 0x123082f0>]
> 
> In [22]: ax.set_yscale('linear'); ax.figure.canvas.draw()
> 
> In [23]: ax.set_yscale('log'); ax.figure.canvas.draw()
> 
> In [24]: ax.set_yscale('linear'); ax.figure.canvas.draw()  # the y
> data are now plotted differently
> 
> 
> I am not sure what is going on yet, but I'm sure Michael will chime in
> since I think we are seeing some funkiness in the new transforms and
> path infrastructure.
> 
> 
>> The new hist() function looks really good, I especially welcome the "step"
>> mode. A couple of comments:
>>
>> The latest svn incarnation doesn't allow for log scale in step-mode
>> (unless you set it manually).
>>
>> Also, I think the step-mode should have fill=False as default, otherwise
>> it does not look that much different from bar-mode. The nice thing about
>> step histograms is that you can put several of them in the same plot while
>> keeping it intelligible!
> 
> Manuel is the developer behind these nice new changes to hist --
> hopefully he can help you here.

log-scale support for step-histograms is done now on the trunk.

   Manuel

Hi folks,

I've added this little bit of code to the default ipython -pylab startup:

        exec ("import numpy\n"
              "import numpy as np\n"
              "import matplotlib\n"
              "import matplotlib.pylab as pylab\n"
              "try:\n"
              "    import matplotlib.pyplot as plt\n"
              "except ImportError:\n"
              "    pass\n"
              ) in user_ns

to try and encourage use of the 'canonical' ways of calling/executing
numpy and mpl calls.  This is just in my branch, not publicly visible
yet.  I wanted to know:

1. If I should keep the try/except around.
2. If this is your 'approved' manner of loading.  It worries me a bit
that if we promote pyplot/plt as the entry point, it needs a proper
docstring.  Just try 'pylab?' vs 'pyplot?' and you'll see the
difference.

Cheers,

f

I agree that the new logo looks nice, but I also think that
Rob is right: When you see the logo you wouldn't know that
we are talking about a general purpose plotting package.
So the question is: are we going for looks over meaning?
I guess the other way around would be terrible: choosing
meaning over looks you are stuck with an ugly logo that
carries the right message. So to me, looks it is,

Mark


> On Jun 1, 2008, at 9:47 AM, Rob Hetland wrote:
> >
> > 2. I like the figure to the side (and agree that there should be
> > only one), but it seems that polar plots are more rarely used than
> > normal x-y plots.  Perhaps an x-y plot (the histogram, for example)
> > would be better advertising.
>
> I was the one who originally chose the polar plot. I admit, it was
> mainly for aesthetics. Here are a few reasons:
>
> * I think a circular plot works better on the logo than a rectangular
> plot would.
> * The polar plot is one of the more attractive plots in the examples.
> * It's a plotting featuring that most plotting software wouldn't have
> so it seems to differentiate matplotlib from other plotting software.
>
> Originally, it wasn't a big deal because there were other plots in the
> logo. Still, I'd be in favor of keeping the polar plot for aesthetic
> reasons.
>
> Great, now I'm that guy who's arguing for looks over practicality. :(
>
> -Tony
>