matplotlib-users Mailing List for matplotlib

One thing you have missed is the behavior of pylab.cm.jet. If you pass 
it an integer array, it treats the integers as indices into the default 
jet colormap, with 256 colors. If you pass it a float array, the floats 
must be scaled from 0 to 1, in which case you will get scaled values 
from the colormap.
I am sure there is more to this story, and probably some improvements 
needed in scatter and/or its documentation, but this is all I have time 
for at the moment.
Eric
Joe Shmoe wrote:
> On 8/14/07, Matthew Auger <ma...@ph...> wrote:
>> This demonstrates the *solution*--the problem is that scatter() does not
>> automagically perform color mapping for the edge and face colors.
> 
> Indeed...and I wish the behavior was more like other mpl functions.
> Either way, passing my list through a colormap did not solve the issue
> (for me). If I call:
> 
> scatter(x,y,s,c)
> 
> then I get a scatter plot where the points are different sizes and
> colors. Without specifying the keyword 'edgecolor', it is not
> possible to have varying edge colors. For consistency, I set the
> facecolors through a keyword as well. So, I would like to be able to
> make the following command:
> 
> scatter(x,y,s, facecolor=cm.jet(c), edgecolor=cm.jet(ec))
> 
> where, as noted, we must manually map the colors when specifying via
> keywords. However, when I run the above command, I do not get a
> scatter plot with varying sizes, colors, and edgecolors. Instead, I
> get varying sizes, all points with 'b' as a facecolor, and all points
> with 'k' as an edgecolor.
> 
> I've tried to figure this out...comments are requested...
> 
> I am looking at axes.py/scatter now....
> 
> When I make the above statement, c takes on its default value (which
> is 'b'). The function sees that c is string like and converts it to a
> rgba_list. Since 'faceted' defaults to True, edgecolors=None.
> 
> Now we go through and create the *PolyCollection. For 'facecolors' we
> pass in 'b'...and for 'edgecolors' we pass in None. After creation,
> collection.update(kwargs) is called.
> 
> As I understand it, this is what *should* happen when the update
> method is called: The collection should take my keywords 'facecolor'
> and 'edgecolor' and assign them to self._facecolors and
> self._edgecolors. This does occur (as my first reply demonstrated).
> It seems what should *also* happen is that the facecolors/edgecolors
> of the points should be updated...but this does not occur.
> 
> Do you (or does anybody) have a working, simple example where the
> faces/edges are both varying for a scatter plot? Perhaps I've missed
> something obvious.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 8/14/07, Matthew Auger <ma...@ph...> wrote:
> This demonstrates the *solution*--the problem is that scatter() does not
> automagically perform color mapping for the edge and face colors.
Indeed...and I wish the behavior was more like other mpl functions.
Either way, passing my list through a colormap did not solve the issue
(for me). If I call:
 scatter(x,y,s,c)
then I get a scatter plot where the points are different sizes and
colors. Without specifying the keyword 'edgecolor', it is not
possible to have varying edge colors. For consistency, I set the
facecolors through a keyword as well. So, I would like to be able to
make the following command:
 scatter(x,y,s, facecolor=cm.jet(c), edgecolor=cm.jet(ec))
where, as noted, we must manually map the colors when specifying via
keywords. However, when I run the above command, I do not get a
scatter plot with varying sizes, colors, and edgecolors. Instead, I
get varying sizes, all points with 'b' as a facecolor, and all points
with 'k' as an edgecolor.
I've tried to figure this out...comments are requested...
I am looking at axes.py/scatter now....
When I make the above statement, c takes on its default value (which
is 'b'). The function sees that c is string like and converts it to a
rgba_list. Since 'faceted' defaults to True, edgecolors=None.
Now we go through and create the *PolyCollection. For 'facecolors' we
pass in 'b'...and for 'edgecolors' we pass in None. After creation,
collection.update(kwargs) is called.
As I understand it, this is what *should* happen when the update
method is called: The collection should take my keywords 'facecolor'
and 'edgecolor' and assign them to self._facecolors and
self._edgecolors. This does occur (as my first reply demonstrated).
It seems what should *also* happen is that the facecolors/edgecolors
of the points should be updated...but this does not occur.
Do you (or does anybody) have a working, simple example where the
faces/edges are both varying for a scatter plot? Perhaps I've missed
something obvious.

This demonstrates the *solution*--the problem is that scatter() does not 
automagically perform color mapping for the edge and face colors. Perhaps 
this is a 'feature', but if so (or even if not) maybe the documentation 
should be clarified (I figured 'c' and 'color' were equivalent, like other 
mpl functions, but this is NOT the case for scatter; none of the 'color' 
kwargs are automatically mapped).
On 2007年8月14日, Joe Shmoe wrote:
> Matthew Auger wrote the following on 08/13/2007 11:15 AM:
>> I'm trying to make high-dimensionality scatter plots, but I've run into a
>> couple of issues. I'm using scatter() but including both edge and face
>> color mapping; I doubt this will provide a meaningful display, but I'd
>> like to try it and see.... Unfortunately, passing data arrays to facecolor
>> and edgecolor does *not* map the data arrays to colors--instead I get
>> gray edges and/or faces. As a side note, none of the 'usual' keyword
>> shortcuts (ec, fc, lw for example) work with scatter().
>>
>
> Does the following demonstrate the issue?
>
> --------------
> import pylab
> x = [a for a in range(10)]
> y = [a**2 for a in range(10)]
> s = [a**3 for a in range(10)]
> c = x
> ec = c[:]
> ec.reverse()
>
> a = pylab.scatter(x,y,s,
> facecolor=pylab.cm.jet(c),
> edgecolor=pylab.cm.jet(ec))
>
> print a._facecolors
> print a._edgecolors
>
> pylab.show()
> -------------
>
> So we create a scatter plot with different sizes, facecolors, and
> edgecolors. The collection clearly has the facecolors/edgecolors
> stored. However, resulting image does not show the different
> facecolors/edgecolors. Each circle is given the default
> facecolor/edgecolor (as axes.py indicates it should)...but It seems
> like something is not getting updated. Comments anyone? ...seems
> like a bug at first glance...
>
> Confirmed with version 0.90.1.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Matthew Auger wrote the following on 08/13/2007 11:15 AM:
> I'm trying to make high-dimensionality scatter plots, but I've run into a
> couple of issues. I'm using scatter() but including both edge and face
> color mapping; I doubt this will provide a meaningful display, but I'd
> like to try it and see.... Unfortunately, passing data arrays to facecolor
> and edgecolor does *not* map the data arrays to colors--instead I get
> gray edges and/or faces. As a side note, none of the 'usual' keyword
> shortcuts (ec, fc, lw for example) work with scatter().
>
Does the following demonstrate the issue?
--------------
import pylab
x = [a for a in range(10)]
y = [a**2 for a in range(10)]
s = [a**3 for a in range(10)]
c = x
ec = c[:]
ec.reverse()
a = pylab.scatter(x,y,s,
 facecolor=pylab.cm.jet(c),
 edgecolor=pylab.cm.jet(ec))
print a._facecolors
print a._edgecolors
pylab.show()
-------------
So we create a scatter plot with different sizes, facecolors, and
edgecolors. The collection clearly has the facecolors/edgecolors
stored. However, resulting image does not show the different
facecolors/edgecolors. Each circle is given the default
facecolor/edgecolor (as axes.py indicates it should)...but It seems
like something is not getting updated. Comments anyone? ...seems
like a bug at first glance...
Confirmed with version 0.90.1.

In matplotlib 0.90.1, the trigger to render the string with math 
formatting is if the string that is ultimately passed to the plotting 
engine starts and ends with a '$'.
So to get your expression to work, you would need to do something like:
 vlostring="$v_{lo}=%5.2f$" % (vlo)
Does that work for you?
Cheers,
Mike
David D Clark wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> I am trying to create some text on a plot with the following commands:
> 
> vlostring="$v_{lo}$="+str(vlo)+" t="+str(vlotime)
> text(vlo,vlotime,vlostring)
> 
> However, the text is rendered literally --
> 
> $v_{lo}$=0.3 t=7961.66
> 
> instead of nicely formatted LaTeX like text
> 
> when I do
> 
> text(vlo,vlotime,"$v_{lo}=$")
> 
> without trying to add the str(...), it renders the expression correctly.
> 
> Any suggestions?
> Dave
> 
> - --
> David D. Clark
> Electrical Engineer
> P-23, Neutron Science and Technology
> e-mail mailto:dd...@la...
> GPG Public key 0x018D6523 available at http://www.us.pgp.net
> http://www.gnupg.org has information about public key cryptography
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFGwgG0Nu7GcwGNZSMRAqRrAJ4kHL6bpFVFhJteHQ1uzQPtREFxkwCdFxe4
> zw3F6ymJr5XSeJxwDQmBFjE=
> =MIQ6
> -----END PGP SIGNATURE-----
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Darren Dale wrote:
> On Tuesday 14 August 2007 09:14:54 am Xavier Gnata wrote:
> 
>> Darren Dale wrote:
>> 
>>> On Sunday 12 August 2007 07:05:38 pm Xavier Gnata wrote:
>>> 
>>>> OK my matplotlibrc was out of date. Now it works but I have found
>>>> another but playing with the sliders of the backend:
>>>> As the log is quite long, here are only the most relevant parts :
>>>> 
>>> [...]
>>>
>>> 
>>>> It looks like that the ranges of the sliders are checked in a wrong way.
>>>> It may be due to numerical rounding issues.
>>>> 
>>> Unfortunately I have my hands full at work, so I don't know when I will
>>> be able to look into this. I would need more information before I could
>>> start anyway: a simple script and a list of steps that reproduces the
>>> problem, and does it only occur with the qt4 backend.
>>>
>>> Darren
>>> 
>> Using Qt4Agg as backend :
>> import pylab
>> pylab.plot([1,2])
>> Then click on the "subplot configuration tool"
>> Move the "left" slider to the right end on the slider.
>> Python crashes because :
>>
>> ValueError: left cannot be >= right
>>
>> Using the TkAgg backend, I'm not able to reporduce the bug because it is
>> not possbile to move the sliders to get left>=right (so there is no bug
>> here :))
>>
>> I had a quick look to the code and it looks like it is quite simple to
>> fix that adding in backend_qt4.py a logic like:
>> if left>=right: left=right-right/1000.
>>
>> The main problem is that I'm not sure to add this fix at the best place
>> in the code.
>> 
>
> This should be fixed in svn 3709. Thank you for the report and the suggested 
> fix. In the future, please try to provide a little more context for your 
> patch, the file is 550 lines long.
>
> Darren
> 
It is fixed. Thanks.
Xavier
ps : I only provide developers with real unified diffs when I'm able to 
produce them ;)
-- 
############################################
Xavier Gnata
CRAL - Observatoire de Lyon
9, avenue Charles André
69561 Saint Genis Laval cedex
Phone: +33 4 78 86 85 28
Fax: +33 4 78 86 83 86
E-mail: gn...@ob...
############################################ 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Using
vlostring="$v_{lo}$=%5.2f" % (vlo)
doesn't work either.
Dave
David D Clark wrote:
> Hello,
> 
> I am trying to create some text on a plot with the following commands:
> 
> vlostring="$v_{lo}$="+str(vlo)+" t="+str(vlotime)
> text(vlo,vlotime,vlostring)
> 
> However, the text is rendered literally --
> 
> $v_{lo}$=0.3 t=7961.66
> 
> instead of nicely formatted LaTeX like text
> 
> when I do
> 
> text(vlo,vlotime,"$v_{lo}=$")
> 
> without trying to add the str(...), it renders the expression correctly.
> 
> Any suggestions?
> Dave
> 
- -------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
- --
David D. Clark
Electrical Engineer
P-23, Neutron Science and Technology
ph. 505.667.4147 fx. 505.665.4121 pg. 505.996.1416
e-mail mailto:dd...@la...
GPG Public key 0x018D6523 available at http://www.us.pgp.net
http://www.gnupg.org has information about public key cryptography
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGwgvzNu7GcwGNZSMRAjrzAJ9mgSOdnbBf7uYpgrARdDnF6S/XBQCfUh1O
GKM4Xeg2wMhedNv/kyDmbTM=
=zW3m
-----END PGP SIGNATURE-----

When I updated from Matplotlib 0.90 to 0.90.1 the axis tick labels 
started overlaping the axes themselves. In 0.90 they are slightly 
offset and are readable, but in 0.90.1 they are very hard to read.
Is there some way I can fix this easily? I guess I can roll back to 
0.90 since I don't seem to notice any other differences/fixes in 0.90.1.
I am creating a 3D plot with this code, in case that helps:
 fig = pylab.figure()
 ax = axes3d.Axes3D(fig)
 for X, Y, Z, color in plotData:
 ax.plot3D(X,Y,Z, color = color)
 ax.set_xlabel('X')
 ax.set_ylabel('Y')
 ax.set_zlabel('Z')
 pylab.legend(legendText,
 'upper center', shadow=True)
 pylab.show()
-Sim

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I am trying to create some text on a plot with the following commands:
vlostring="$v_{lo}$="+str(vlo)+" t="+str(vlotime)
text(vlo,vlotime,vlostring)
However, the text is rendered literally --
$v_{lo}$=0.3 t=7961.66
instead of nicely formatted LaTeX like text
when I do
text(vlo,vlotime,"$v_{lo}=$")
without trying to add the str(...), it renders the expression correctly.
Any suggestions?
Dave
- --
David D. Clark
Electrical Engineer
P-23, Neutron Science and Technology
e-mail mailto:dd...@la...
GPG Public key 0x018D6523 available at http://www.us.pgp.net
http://www.gnupg.org has information about public key cryptography
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGwgG0Nu7GcwGNZSMRAqRrAJ4kHL6bpFVFhJteHQ1uzQPtREFxkwCdFxe4
zw3F6ymJr5XSeJxwDQmBFjE=
=MIQ6
-----END PGP SIGNATURE-----

You might take a look at tvtk.mlab and mavayi.
http://www.scipy.org/Cookbook/MayaVi
On 8/14/07, Eric Firing <ef...@ha...> wrote:
> Kaushik Ghose wrote:
> > Hi Everyone,
> >
> > I vaguely remember a comment from a poster a short while back that
> > suggested that 3D support in matplotlib was not serious. I would like to
> > ask what plans there are for 3D plotting support in this great library.
>
> There are no plans. The topic keeps coming up, but no one has come
> forward to put steady work into it. It is not entirely clear how much
> can be done using the present approach, which is a layer on top of a
> fundamentally 2D framework.
>
> Eric
> >
> > thanks!
> > -Kaushik
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Kaushik Ghose wrote:
> Hi Everyone,
> 
> I vaguely remember a comment from a poster a short while back that 
> suggested that 3D support in matplotlib was not serious. I would like to 
> ask what plans there are for 3D plotting support in this great library.
There are no plans. The topic keeps coming up, but no one has come 
forward to put steady work into it. It is not entirely clear how much 
can be done using the present approach, which is a layer on top of a 
fundamentally 2D framework.
Eric
> 
> thanks!
> -Kaushik

Hi Everyone,
I vaguely remember a comment from a poster a short while back that 
suggested that 3D support in matplotlib was not serious. I would like to 
ask what plans there are for 3D plotting support in this great library.
thanks!
-Kaushik

On Tuesday 14 August 2007 09:14:54 am Xavier Gnata wrote:
> Darren Dale wrote:
> > On Sunday 12 August 2007 07:05:38 pm Xavier Gnata wrote:
> >> OK my matplotlibrc was out of date. Now it works but I have found
> >> another but playing with the sliders of the backend:
> >> As the log is quite long, here are only the most relevant parts :
> >
> > [...]
> >
> >> It looks like that the ranges of the sliders are checked in a wrong way.
> >> It may be due to numerical rounding issues.
> >
> > Unfortunately I have my hands full at work, so I don't know when I will
> > be able to look into this. I would need more information before I could
> > start anyway: a simple script and a list of steps that reproduces the
> > problem, and does it only occur with the qt4 backend.
> >
> > Darren
>
> Using Qt4Agg as backend :
> import pylab
> pylab.plot([1,2])
> Then click on the "subplot configuration tool"
> Move the "left" slider to the right end on the slider.
> Python crashes because :
>
> ValueError: left cannot be >= right
>
> Using the TkAgg backend, I'm not able to reporduce the bug because it is
> not possbile to move the sliders to get left>=right (so there is no bug
> here :))
>
> I had a quick look to the code and it looks like it is quite simple to
> fix that adding in backend_qt4.py a logic like:
> if left>=right: left=right-right/1000.
>
> The main problem is that I'm not sure to add this fix at the best place
> in the code.
This should be fixed in svn 3709. Thank you for the report and the suggested 
fix. In the future, please try to provide a little more context for your 
patch, the file is 550 lines long.
Darren

Darren Dale wrote:
> On Sunday 12 August 2007 07:05:38 pm Xavier Gnata wrote:
> 
>> OK my matplotlibrc was out of date. Now it works but I have found
>> another but playing with the sliders of the backend:
>> As the log is quite long, here are only the most relevant parts :
>> 
> [...]
> 
>> It looks like that the ranges of the sliders are checked in a wrong way.
>> It may be due to numerical rounding issues.
>> 
>
> Unfortunately I have my hands full at work, so I don't know when I will be 
> able to look into this. I would need more information before I could start 
> anyway: a simple script and a list of steps that reproduces the problem, and 
> does it only occur with the qt4 backend.
>
> Darren
> 
Using Qt4Agg as backend :
import pylab
pylab.plot([1,2])
Then click on the "subplot configuration tool"
Move the "left" slider to the right end on the slider.
Python crashes because :
ValueError: left cannot be >= right
Using the TkAgg backend, I'm not able to reporduce the bug because it is 
not possbile to move the sliders to get left>=right (so there is no bug 
here :))
I had a quick look to the code and it looks like it is quite simple to 
fix that adding in backend_qt4.py a logic like:
if left>=right: left=right-right/1000.
The main problem is that I'm not sure to add this fix at the best place 
in the code.
Could someone else have a look?
Xavier
-- 
############################################
Xavier Gnata
CRAL - Observatoire de Lyon
9, avenue Charles André
69561 Saint Genis Laval cedex
Phone: +33 4 78 86 85 28
Fax: +33 4 78 86 83 86
E-mail: gn...@ob...
############################################ 

Dear all,
I am making a contour plot using matplotlib. The title and axis annotations
require math symbols so I set usetex=True in the rc('text',usetex).
However that made ALL texts in LaTeX (incl. contour labels) and
the contour labels look not satisfying when rendered by TeX. What I needed
is LaTeX for all texts EXCEPT the contour labels (I'd like to use the
default sans-serif font for them.)
Can you tell me some hints?
Thanks in advance.
Cong.