matplotlib-users Mailing List for matplotlib

John Hunter wrote:
> 
> I'm able to download it from the sf site -- perhaps it's your download
> client?

I've tried a number of approaches on Linux and XP, including remote desktop into 
another box on the other side of the country, but all approaches failed. The 
only commonality between the 2 setups is we are both using IPCop as a firewall 
and are in Australia.

Robert

Cindy Hodgins Burian wrote:
>  If I 
> change "BUILD_GTKAGG = 0" it compiles with some complaints like

This will keep it form building the GTKAGG back end...do you need that?

>  >>> import pylab

>    from _gtkagg import agg_to_gtk_drawable

You're getting this error because you don't have the GTKAGG back end, 
which makes sense, as you told setup.py not to build it.

The problem is that your matplotlibrc file sets gtkagg as the default 
back end. First, try this:

 >>> import matplotlib
 >>> matplotlib.use('Agg')
 >>> import pylab

If that works, then you seem to have a working matplotlib with the Agg 
back end. If you generating plots that you want to save as PNG and use 
ion a wed site or something, you're done. You should also be able to use 
it with wxPython. Tkinter may also work. If you do need the PyGTK back 
end, I can't help you, except to say that make sure you have PyGTK 
working first.

To change the default back end, edit matplotlibrc:

http://matplotlib.sf.net/.matplotlibrc

Good luck,

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

John Hunter wrote:

> >>>>> "Teemu" == Teemu Rinne <Tee...@he...> writes:
>
>
>     Teemu> How to do this?  Do I have to combine the RGB values of the
>     Teemu> two images 'manually'?
>
> Basically what you are talking about is adding an alpha channel to the
> color map, and setting it to be transparent for image values less than
> a certain value.  Perry Greenfield is the colormap implementer and
> resident expert.
>
> Perry -- how hard would it be to either subclass or extend the current
> framework to include an alpha channel?  I think it could be done in
> just a few lines of code actually.  Eg, something like
>
>    self._alpha_lut  = makeMappingArray(self.N,
>                      self._segmentdata.get('blue', [1.0, 1.0])
>
> and then modifying
>
>     def __call__(self, X, alpha=1.0):
>
> to deal with it.
>
> Perry do you have time to take a crack at this?  I think this would be
> very useful.
>
Offhand it doesn't look like it should be a problem, but I need to clarify
some things about your suggestion and the user interface.

Should self._alpha_lut always copy the blue segment data (or are you showing
what the user would have to do?) I would have guessed that it would default
to being always 1 (I think that's the intent above but how does one then
define it independently outside of the class definition.

Secondly, this example asks for a threshold based on prenormalized data
values (i.e., image value of 30). To get what the user wants, the user must
either define the alpha map to match the normalized value of 30 or normalize
the data to match 30 to the alpha map threshold. It's not so obvious to me
how this is best handled. A fancier normalization function that uses
data-based thresholds to map to color map thresholds? Otherwise, it may be
fairly painful to apply in practice. A convenient way to define a color map
based on data values and how the data will be normalized?

But maybe I'm suffering from flu-induced confusion.

Perry

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
    Fernando> Well, the funny thing about my sometimes-odd results, is
    Fernando> that in python 2.3, list.sort _is_ stable:

    Fernando> http://py-stablesort.sourceforge.net/doc/2002_07_28_pythonowns_archive.html
    Fernando> http://mail.python.org/pipermail/python-list/2003-April/160326.html

    Fernando> So I'm not quite sure why I get odd results in a few
    Fernando> cases.  And I can't seem to find a reliable way to
    Fernando> repeat the behavior.

Hmm, I hesitate to say this, but I wonder if it's a bug in the stable
sort.  I also see the behavior you describe in ipython --
intermittently the order is wrong.  But when I add the extra ind to
the axes dsu sort, I never get it.

Changes in CVS.  Make sure you have revision - CHANGELOG 1.270

    Fernando> But thanks for the clarification on the zorder argument,
    Fernando> that's enough for me to get the behavior I need.

    Fernando> I'll update the zorder_demo example with a more explicit
    Fernando> docstring so others don't fall into the same confusion.


Thanks.

JDH

I'm having some problems compiling matplotlib 0.7.1 on solaris 8.  I 
believe I have all the prerequisites there.  If I try to compile with 
setup.py as it is originally, immediately it complains with "sh: 
pkg-config: not found", and finally dies after working a while.  If I 
change "BUILD_GTKAGG = 0" it compiles with some complaints like

/usr/local/pkg/python/include/python2.3/pyconfig.h:856:1: warning: 
"_XOPEN_SOURCE" redefined
<command line>:1:1: warning: this is the location of the previous definition

But seems to work.

When I try to import it I get:

ghia{chodgins}120: python
Python 2.3 (#1, Sep 12 2003, 16:47:52)
[GCC 3.0.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/pkg/python/lib/python2.3/site-packages/pylab.py", 
line 1, in ?
    from matplotlib.pylab import *
  File 
"/usr/local/pkg/python/lib/python2.3/site-packages/matplotlib/pylab.py", 
line 191, in ?
    from backends import new_figure_manager, error_msg, \
  File 
"/usr/local/pkg/python/lib/python2.3/site-packages/matplotlib/backends/__init__.py", 
line 20, in ?
    globals(),locals(),[backend_name])
  File 
"/usr/local/pkg/python/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 16, in ?
    from _gtkagg import agg_to_gtk_drawable
ImportError: No module named _gtkagg
 >>>

I'm not sure how to proceed from here.  I also am not a python 
programmer, just a system administrator trying to get this installed.  
Any help or fingers pointing me in a direction are greatly appreciated.  
Thanks.

Cindy
 

John Hunter wrote:
> Hmm, seems to work for me -- you didn't specify the colors in your
> example which makes it hard to test, so I'll add them

Weird.  I ran this a ton of times, and in _most_ cases I get your same 
results.  And yet a _few_ times, and only when I pasted the code in an 
interactive window, the horizontal line ends below the sine/cosine plots. 
Very, very strange.

> Well the zorder kwarg is your friend -- did you see
> examples/zorder_demo.py ?  Eg
> 
>   plot(x,y, zorder=100)  # I'm on top!

I did read it, but I guess I misunderstood the docstring on top.  I understood 
it as meaning that you could only reorder classes of objects relative to one 
another (lines, text, patches), but not individual lines within the class of 
all lines.

> Now, if I recall correctly, python sort doesn't guarantee preserving
> order for equal element.  Since the order in the respective list
> (patches, lines, etc) *is* determined by the order of the plot
> commands, we might be better off with 
> 
>         dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)]
>         dsu.sort()
>         
>         for zorder, i, a in dsu:
>             a.draw(renderer)
> 
> to guarantee relative order for artists with the same zorder.
> 
> Or is sort relative order preserving for equal elements?

Well, the funny thing about my sometimes-odd results, is that in python 2.3, 
list.sort _is_ stable:

http://py-stablesort.sourceforge.net/doc/2002_07_28_pythonowns_archive.html
http://mail.python.org/pipermail/python-list/2003-April/160326.html

So I'm not quite sure why I get odd results in a few cases.  And I can't seem 
to find a reliable way to repeat the behavior.

But thanks for the clarification on the zorder argument, that's enough for me 
to get the behavior I need.

I'll update the zorder_demo example with a more explicit docstring so others 
don't fall into the same confusion.

Cheers,

f

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:

    Robert> I'm unable to successfully download the user guide, it
    Robert> keeps bombing out at about 3MB (other downloads are
    Robert> fine). Google doesn't turn up any alternate sources and I
    Robert> was wondering if there is another site (as yet
    Robert> undiscovered by the Googlebots) to download it from?

I'm able to download it from the sf site -- perhaps it's your download
client?

JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Hi all, I am having a bit of a problem with the order
    Fernando> things get drawn.  I looked at the zorder example and
    Fernando> the docs, but I can't seem to find a solution.  Here's
    Fernando> an illustration:

    Fernando> http://amath.colorado.edu/faculty/fperez/tmp/zorder_prob.png

    Fernando> The red wiggly line is drawn first, by a loglog() call,
    Fernando> and then the green one is an axhline() call.  However,
    Fernando> the green line ends up below the red one.  It turns out
    Fernando> that in cases where the range of the red stuff is above
    Fernando> the green cutoff, this causes the green line to be
    Fernando> totally obscured.  And for my plots, it's important that
    Fernando> the green line is clearly visible always.

    Fernando> My naive expectation was that whatever was called last
    Fernando> on the plot would end up on top, but that doesn't seem
    Fernando> to be the case.  I did a few experiments:

    Fernando> x=frange(0,2*pi,npts=100) figure()
    Fernando> plot(x,sin(x),x,cos(x),linewidth=10)
    Fernando> plot(x,sin(2*x),linewidth=10) axhline(0,linewidth=10)

Hmm, seems to work for me -- you didn't specify the colors in your
example which makes it hard to test, so I'll add them

    from pylab import *
    x=frange(0,2*pi,npts=100)
    figure()
    plot(x,sin(x),x,cos(x),linewidth=10, color='red')
    plot(x,sin(2*x),linewidth=10, color='green')
    axhline(0,linewidth=10, color='blue')
    show()

with results at http://matplotlib.sf.net/jdh.png

    Fernando> And I can't really figure out what determines the zorder
    Fernando> of all the line objects.

Well the zorder kwarg is your friend -- did you see
examples/zorder_demo.py ?  Eg

  plot(x,y, zorder=100)  # I'm on top!

I think I have an idea of what may be causing the plot order problem
you are experiencing

From axes.py draw method

        artists = []
        artists.extend(self.collections)
        artists.extend(self.patches)
        artists.extend(self.lines)
        artists.extend(self.texts)

        dsu = [ (a.zorder, a) for a in artists]
        dsu.sort()
        
        for zorder, a in dsu:
            a.draw(renderer)

Now, if I recall correctly, python sort doesn't guarantee preserving
order for equal element.  Since the order in the respective list
(patches, lines, etc) *is* determined by the order of the plot
commands, we might be better off with 

        dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)]
        dsu.sort()
        
        for zorder, i, a in dsu:
            a.draw(renderer)

to guarantee relative order for artists with the same zorder.

Or is sort relative order preserving for equal elements?


JDH

Hi all,

I am having a bit of a problem with the order things get drawn.  I looked at 
the zorder example and the docs, but I can't seem to find a solution.  Here's 
an illustration:

http://amath.colorado.edu/faculty/fperez/tmp/zorder_prob.png

The red wiggly line is drawn first, by a loglog() call, and then the green one 
is an axhline() call.  However, the green line ends up below the red one.  It 
turns out that in cases where the range of the red stuff is above the green 
cutoff, this causes the green line to be totally obscured.  And for my plots, 
it's important that the green line is clearly visible always.

My naive expectation was that whatever was called last on the plot would end 
up on top, but that doesn't seem to be the case.  I did a few experiments:

x=frange(0,2*pi,npts=100)
figure()
plot(x,sin(x),x,cos(x),linewidth=10)
plot(x,sin(2*x),linewidth=10)
axhline(0,linewidth=10)

And I can't really figure out what determines the zorder of all the line objects.

Is there a way to control this?  Would it make sense to make the default 
behavior something more like what hand-drawing would cause?  I mean: you draw 
on the canvas as if it were paper, and newly drawn lines appear on top of 
older ones.

Maybe there's a good reason for the current design, and I'm just missing the 
proper incantation.  I'd be very grateful for a pointer in the right direction.

Cheers,

f

Try this:

a=arange(10)
l1,err = errorbar(a,a,sqrt(a))
legend((l1,),('it works',))


On Wednesday 09 February 2005 10:05 am, Bryan Cole wrote:
> Hi,
>
> When I try to add a legend to an errorbar plot, each individual errorbar
> gets added to the legend (without a label). With ~2000 points in my
> plot, I end up with >2000 entries in my legend: not good.
>
> Can anyone suggest a work-around for this?
>
> thanks,
> Bryan
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 

Darren

Hi,

When I try to add a legend to an errorbar plot, each individual errorbar
gets added to the legend (without a label). With ~2000 points in my
plot, I end up with >2000 entries in my legend: not good.

Can anyone suggest a work-around for this?

thanks,
Bryan

Hello,

I have a problem with the interactive zooming function of the matplotlib
"figure" Object.
I plotted a set of data as a line (simulated data) and a set of data
(measured data) as points. They are both in a subplot to show the
differences:
    plot (X1, Y1, color=(r1,g1,b1),linewidth=1.0)
    plot (X2, Y2, 'ro',markersize=2)

Problem:
Zooming is only possible in parts of the graph, where there is only the data
(X1, Y1) printed.


Does someone can help me?

Thanks in advance.

Christoph

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

I have a requirement to generate a scatter plot with the background divided into 
4 equal rectangular regions, each a different colour/shade indicating a 
particular characteristic of the points in that region. What is the best way to 
do this in matplotlib?

Robert

PS I apologise in advance if this is answered in the user guide, but I'm unable 
to download it atm for some strange reason.

I'm unable to successfully download the user guide, it keeps bombing out at 
about 3MB (other downloads are fine). Google doesn't turn up any alternate 
sources and I was wondering if there is another site (as yet undiscovered by the 
Googlebots) to download it from?

Robert