matplotlib-users Mailing List for matplotlib (Page 2)

Gary wrote:
> AFAICT,  It is not possible to mix text and TeX symbols in a string and 
> have it come out right.  For example, in
> 
> xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$'
> The text  comes out in TeX math mode ... not so pretty.  Please tell me 
> what I've overlooked.

well, I'm not sure how this is supported in matplotlib, but in LaTex,you 
would do:

Normalized Temperature $(kT/\epsilon)$

or:

$\text{Normalized Temperature} (kT/\epsilon)$

the "$" means put it in math mode, if you don't want "Normalized 
Temperature" in math mode, don't put it inside the $$. The second puts 
it all in math mode, but the text{} means set this in text mode.

-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...

I apologize if the answer to this is published in some painfully obvious 
location.  It seems like it must be a FAQ, but I can't find it ...

AFAICT,  It is not possible to mix text and TeX symbols in a string and 
have it come out right.  For example, in

xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$' 

The text  comes out in TeX math mode ... not so pretty.  Please tell me 
what I've overlooked.

-gary

Well I have somewhat good news.  I was using an older machine (RedHat7) 
when I had these problems.  I went to a much newer redhat machine and 
everything works fine.  Same version of Python, gcc, etc - just a newer 
operating system.

I guess I'll just ignore this problem and stick with the newer machine.

Ted

At 01:47 PM 10/21/2004, Todd Miller wrote:
>On Thu, 2004-10-21 at 16:00, John Hunter wrote:
> > >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
> >
> >     Ted> I'm trying to build matplotlib and I'm getting a segmentation
> >     Ted> fault when I do: from matplotlib import *
> >
> >     Ted> I've traced the fault down to the transforms module.
> >
> >     Ted> My first attempt used: gcc 3.3.2 Python 2.3.3 numarray 1.1
> >     Ted> gdmodule 0.52 gd 2.0.28 freetype 2.1.9 agg 22 matplotlib
> >     Ted> 0.63.4
> >
> > Standard issue stuff - very close to what most people are using w/o
> > incident.  Hmmmm....
> >
> >     Ted> In this version _na_transform segementation faults at this
> >     Ted> line: static _transforms_module* _transforms = new
> >     Ted> _transforms_module;
> >
> >     Ted> I traced the fault down to the ExtensionModuleBaseClass where
> >     Ted> it attempts to call: __Py_PackageContext()
> >
> >     Ted> It looks to me like this function is trying to access the
> >     Ted> variable (which it dereferences WITHOUT checking for a null
> >     Ted> pointer).  static char **ptr__Py_PackageContext = NULL;
> >
> > Could you try editing it an adding the NULL test; if this works can
> > you submit a patch pack to be and a bug report to the pycxx sf site?
> >
> >     Ted> This ptr gets init'ed in the function
> >     Ted> InitialisePythonIndirectInterface() but I can't find anywhere
> >     Ted> that function is being called.
> >
> >     Ted> FYI: I also tried matplotlib 0.62.4 and I get the same error.
> >
> > It couldn't be the exact same error, because _na_transforms did not
> > exist in 0.62.4.  Do you mean that you got a segfault on the same line
> > in _transform?
>
>Check for matplotlib/_transforms.so left over from prior installations
>and blow away your old matplotlib and re-install if you find it.  Before
>you re-install, also blow away matplotlib/build.
>
>Todd

On Thu, 2004-10-21 at 16:00, John Hunter wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
> 
>     Ted> I'm trying to build matplotlib and I'm getting a segmentation
>     Ted> fault when I do: from matplotlib import *
> 
>     Ted> I've traced the fault down to the transforms module.
> 
>     Ted> My first attempt used: gcc 3.3.2 Python 2.3.3 numarray 1.1
>     Ted> gdmodule 0.52 gd 2.0.28 freetype 2.1.9 agg 22 matplotlib
>     Ted> 0.63.4
> 
> Standard issue stuff - very close to what most people are using w/o
> incident.  Hmmmm....
> 
>     Ted> In this version _na_transform segementation faults at this
>     Ted> line: static _transforms_module* _transforms = new
>     Ted> _transforms_module;
> 
>     Ted> I traced the fault down to the ExtensionModuleBaseClass where
>     Ted> it attempts to call: __Py_PackageContext()
> 
>     Ted> It looks to me like this function is trying to access the
>     Ted> variable (which it dereferences WITHOUT checking for a null
>     Ted> pointer).  static char **ptr__Py_PackageContext = NULL;
> 
> Could you try editing it an adding the NULL test; if this works can
> you submit a patch pack to be and a bug report to the pycxx sf site?
> 
>     Ted> This ptr gets init'ed in the function
>     Ted> InitialisePythonIndirectInterface() but I can't find anywhere
>     Ted> that function is being called.
> 
>     Ted> FYI: I also tried matplotlib 0.62.4 and I get the same error.
> 
> It couldn't be the exact same error, because _na_transforms did not
> exist in 0.62.4.  Do you mean that you got a segfault on the same line
> in _transform?

Check for matplotlib/_transforms.so left over from prior installations
and blow away your old matplotlib and re-install if you find it.  Before
you re-install, also blow away matplotlib/build.

Todd

>It couldn't be the exact same error, because _na_transforms did not
>exist in 0.62.4.  Do you mean that you got a segfault on the same line
>in _transform?

Sorry - that's what I meant.  It looks like I was a little mistaken.  I 
didn't realize that there are 2 versions of __Py_PackageContext() in the 
same file.  I was orginally looking at the Windows version (I'm building on 
linux).

However, if the linux version looks like this (unmodified):

char *__Py_PackageContext()     { return _Py_PackageContext; }

I get a segmentation fault at the return line.

I then added a print statement to it:

char *__Py_PackageContext()
{
    std::cerr << "context 0\n";
    return _Py_PackageContext;
}

and then everything works!  Off the top of my head, it might be a case of 
C++ static object initialization problems but I can't find any obvious 
places that might be happening.

Ted

At 01:00 PM 10/21/2004, John Hunter wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
>     Ted> I'm trying to build matplotlib and I'm getting a segmentation
>     Ted> fault when I do: from matplotlib import *
>
>     Ted> I've traced the fault down to the transforms module.
>
>     Ted> My first attempt used: gcc 3.3.2 Python 2.3.3 numarray 1.1
>     Ted> gdmodule 0.52 gd 2.0.28 freetype 2.1.9 agg 22 matplotlib
>     Ted> 0.63.4
>
>Standard issue stuff - very close to what most people are using w/o
>incident.  Hmmmm....
>
>     Ted> In this version _na_transform segementation faults at this
>     Ted> line: static _transforms_module* _transforms = new
>     Ted> _transforms_module;
>
>     Ted> I traced the fault down to the ExtensionModuleBaseClass where
>     Ted> it attempts to call: __Py_PackageContext()
>
>     Ted> It looks to me like this function is trying to access the
>     Ted> variable (which it dereferences WITHOUT checking for a null
>     Ted> pointer).  static char **ptr__Py_PackageContext = NULL;
>
>Could you try editing it an adding the NULL test; if this works can
>you submit a patch pack to be and a bug report to the pycxx sf site?
>
>     Ted> This ptr gets init'ed in the function
>     Ted> InitialisePythonIndirectInterface() but I can't find anywhere
>     Ted> that function is being called.
>
>     Ted> FYI: I also tried matplotlib 0.62.4 and I get the same error.
>
>It couldn't be the exact same error, because _na_transforms did not
>exist in 0.62.4.  Do you mean that you got a segfault on the same line
>in _transform?
>
>Thanks,
>JDH

At long last, I finally have a prototype version of polar plots / axes
/ transforms in CVS (mirrors may lag). 

I don't use polar plots a lot in my own work, so those of you who do
should provide some feedback on the implementation, appearance and
functionality.  

See examples/polar_demo.py (included below)

Here is a snapshot of the src distribution if you have CVS problems

  http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.64.0a.tar.gz

In particular, I need some feedback on how setting axis limits should
work and what, if anything, the navigation controls are expected to
do.  These issues are discussed a bit more in the polar_demo.py
example file.

Let me know....
JDH

#!/usr/bin/env python
#
# matplotlib now has a PolarAxes class and a polar function in the
# matplotlib interface.  This is considered alpha and the interface
# may change as we work out how polar axes should best be integrated
#
# The only function that has been tested on polar axes is "plot" (the
# matlab interface function "polar" calls ax.plot where ax is a
# PolarAxes) -- other axes plotting functions may work on PolarAxes
# but haven't been tested and may need tweaking.
#
# you can get get a PolarSubplot instance by doing, for example
#
#   subplot(211, polar=True)
#
# or a PolarAxes instance by doing
#   axes([left, bottom, width, height], polar=True)
#
# The view limits (eg xlim and ylim) apply to the lower left and upper
# right of the rectangular box that surrounds to polar axes.  Eg if
# you have
#
#  r = arange(0,1,0.01)
#  theta = 2*pi*r
#
# the lower left corner is 5/4pi, sqrt(2) and the
# upper right corner is 1/4pi, sqrt(2)
#
# you could change the radial bounding box (zoom out) by setting the
# ylim (radial coordinate is the second argument to the plot command,
# as in matlab, though this is not advised currently because it is not
# clear to me how the axes should behave in the change of view limits.
# Please advise me if you have opinions.  Likewise, the pan/zoom
# controls probably do not do what you think they do and are better
# left alone on polar axes.  Perhaps I will disable them for polar
# axes unless we come up with a meaningful, useful and functional
# implementation for them.
#
# Note that polar axes are sufficiently different that regular axes
# that I haven't stived for a consistent interface to the gridlines,
# labels, etc.  To set the properties of the gridlines and labels,
# access the attributes directly from the polar axes, as in
#
#   ax = gca()
#   set(ax.rgridlines, color='r')
#
# The following attributes are defined
#
#      thetagridlines  : a list of Line2D for the theta grids
#      rgridlines      : a list of Line2D for the radial grids
#      thetagridlabels : a list of Text for the theta grid labels
#      rgridlabels     : a list of Text for the theta grid labels                  

from matplotlib.matlab import *

r = arange(0,4,0.001)
theta = 6*pi*r
polar(theta, r)
title("It's about time!")
savefig('polar_demo')
ax = gca()

show()

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> I'm trying to build matplotlib and I'm getting a segmentation
    Ted> fault when I do: from matplotlib import *

    Ted> I've traced the fault down to the transforms module.

    Ted> My first attempt used: gcc 3.3.2 Python 2.3.3 numarray 1.1
    Ted> gdmodule 0.52 gd 2.0.28 freetype 2.1.9 agg 22 matplotlib
    Ted> 0.63.4

Standard issue stuff - very close to what most people are using w/o
incident.  Hmmmm....

    Ted> In this version _na_transform segementation faults at this
    Ted> line: static _transforms_module* _transforms = new
    Ted> _transforms_module;

    Ted> I traced the fault down to the ExtensionModuleBaseClass where
    Ted> it attempts to call: __Py_PackageContext()

    Ted> It looks to me like this function is trying to access the
    Ted> variable (which it dereferences WITHOUT checking for a null
    Ted> pointer).  static char **ptr__Py_PackageContext = NULL;

Could you try editing it an adding the NULL test; if this works can
you submit a patch pack to be and a bug report to the pycxx sf site?

    Ted> This ptr gets init'ed in the function
    Ted> InitialisePythonIndirectInterface() but I can't find anywhere
    Ted> that function is being called.

    Ted> FYI: I also tried matplotlib 0.62.4 and I get the same error.

It couldn't be the exact same error, because _na_transforms did not
exist in 0.62.4.  Do you mean that you got a segfault on the same line
in _transform?

Thanks,
JDH

I'm trying to build matplotlib and I'm getting a segmentation fault when I do:

from matplotlib import *

I've traced the fault down to the transforms module.

My first attempt used:
gcc 3.3.2
Python 2.3.3
numarray 1.1
gdmodule 0.52
gd 2.0.28
freetype 2.1.9
agg 22
matplotlib 0.63.4

In this version _na_transform segementation faults at this line:
   static _transforms_module* _transforms = new _transforms_module;

I traced the fault down to the ExtensionModuleBaseClass where it attempts 
to call:  __Py_PackageContext()

It looks to me like this function is trying to access the variable (which 
it dereferences WITHOUT checking for a null pointer).
static char **ptr__Py_PackageContext = NULL;

This ptr gets init'ed in the function InitialisePythonIndirectInterface() 
but I can't find anywhere that function is being called.

FYI: I also tried matplotlib 0.62.4 and I get the same error.

Can anybody figure out what's happening to me?
Thanks,
Ted

Thank you, this works fine.


On Wednesday 20 October 2004 22:47, John Hunter wrote:
> Hmm, I don't know how this slipped in untested.  corrcoef definitely
> works for corrcoeff(x,y), but is obviously broken for matrices.
>
> Here is a fixed implementation, tested against matlab for MxN matrices
> with 5 significant digits of agreement in the correlation matrix
> output with Numeric and numarray.

-- 
Sebastian Stark -- http://www.kyb.tuebingen.mpg.de/~stark
Max Planck Institute for Biological Cybernetics
Spemannstr. 38, 72076 Tuebingen
Phone: +49 7071 601 555 -- Fax: +49 7071 601 552

>>>>> "Sebastian" == Sebastian Stark <st...@tu...> writes:

    Sebastian> How is corrcoef() supposed to work? When I do the
    Sebastian> following:

    Sebastian> --------------------------------------- from numarray
    Sebastian> import * from numarray import random_array from
    Sebastian> matplotlib.mlab import corrcoef randn =
    Sebastian> random_array.standard_normal

    Sebastian> x = randn((10,4)) r = corrcoef(x)
    Sebastian> ---------------------------------------

Hmm, I don't know how this slipped in untested.  corrcoef definitely
works for corrcoeff(x,y), but is obviously broken for matrices.

Here is a fixed implementation, tested against matlab for MxN matrices
with 5 significant digits of agreement in the correlation matrix
output with Numeric and numarray.

Thanks for catching it.

As you noted, there was a non-printable character n the buffer, which
crept in when I borrowed some code from Fernando Perez.  Damned
Colombians and their accented names!

Let me know if you encounter further problems!

JDH

def corrcoef(*args):
    """
    corrcoef(X) where X is a matrix returns a matrix of correlation
    coefficients for each numrows observations and numcols variables.
    
    corrcoef(x,y) where x and y are vectors returns the matrix or
    correlation coefficients for x and y.

    Numeric arrays can be real or complex

    The correlation matrix is defined from the covariance matrix C as

    r(i,j) = C[i,j] / sqrt(C[i,i]*C[j,j])
    """


    if len(args)==2:
        X = transpose(array([args[0]]+[args[1]]))
    elif len(args)==1:
        X = args[0]
    else:
        raise RuntimeError, 'Only expecting 1 or 2 arguments'

    
    C = cov(X)

    if len(args)==2:
       d = resize(diagonal(C), (2,1))
       denom = sqrt(matrixmultiply(d,transpose(d)))
    else:
       dc = diagonal(C)
       N = len(dc)       
       shape = N,N
       denom = sqrt(matrixmultiply(diagonal_matrix(dc),
                                   resize(dc, shape)))

    r = divide(C,denom)
    try: return r.real
    except AttributeError: return r

John Hunter wrote:

[snip, snip]
> 
> As I wrote then, I think the root of this bug is that matplotlib is
> doing the transforms in the front end and passing the backend display
> coordinates.  In some cases, you can get very odd display coordinates,
> eg very large positive or negative numbers, and I think this is what
> is causing agg to fail (I know agg has some canvas size limitations,
> something like 4096x4096 pixels if memory serves).  For some time I've
> been wanting to refactor the backend code to pass data + transform to
> the backend rather than transformed data.  This would fix a lot of
> little bugs, eg some subpixel artifacts in agg that I've had to hack
> around by special casing, and would improve performance on some
> backends, like PS and SVG where you can simply provide the data
> coordinates and the vec 6 affine and let the display device handle the
> transformations.

Yeah!

> It's a fairly big change, and requires some thought as to how to do it
> right in the presence of nonlinear/nonseparable transformations, but
> it's on the list.

Excellent!

[snip, snip]

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:

    Jin-chung> When I do the following, the plot is doing something
    Jin-chung> weird. It fills up a triangle area between first and
    Jin-chung> second points, after the axis command:

    >>>> n = 5000.0 plot([n,-49.9,-49.9,-49.99,-50,-50])
    >>>> axis([0,5,-50.1,-50+0.1])

    Jin-chung> This only happens at a very narrow window of boundary
    Jin-chung> conditions.  If n is smaller (e.g. 4000) or if Y range
    Jin-chung> is larger (e.g. set the min at -50.2 instead of -50.1),
    Jin-chung> it becomes normal.

Many months ago Srinath Avadhanula reported the same bug - strange and
unexplained filling behavior with very narrow axis limits and a points
far outside those limits.  

  http://sourceforge.net/mailarchive/message.php?msg_id=7973663

As I wrote then, I think the root of this bug is that matplotlib is
doing the transforms in the front end and passing the backend display
coordinates.  In some cases, you can get very odd display coordinates,
eg very large positive or negative numbers, and I think this is what
is causing agg to fail (I know agg has some canvas size limitations,
something like 4096x4096 pixels if memory serves).  For some time I've
been wanting to refactor the backend code to pass data + transform to
the backend rather than transformed data.  This would fix a lot of
little bugs, eg some subpixel artifacts in agg that I've had to hack
around by special casing, and would improve performance on some
backends, like PS and SVG where you can simply provide the data
coordinates and the vec 6 affine and let the display device handle the
transformations.

It's a fairly big change, and requires some thought as to how to do it
right in the presence of nonlinear/nonseparable transformations, but
it's on the list.

I see you are actively working to maintain your role as the finder of
the toughest bugs.  Unfortunately, Srinath scooped you on this one.
Thanks for reminding me that it is still a problem, as I had allowed
it to slip to the most distant reaches of my conciousness.

JDH

When I do the following, the plot is doing something weird. It fills up a 
triangle area between first and second points, after the axis command:

>>> n = 5000.0
>>> plot([n,-49.9,-49.9,-49.99,-50,-50])
>>> axis([0,5,-50.1,-50+0.1])

This only happens at a very narrow window of boundary conditions.
If n is smaller (e.g. 4000) or if Y range is larger (e.g. set the min at -50.2 
instead of  -50.1), it becomes normal.

JC Hsu

How is corrcoef() supposed to work? When I do the following:

---------------------------------------
from numarray import *
from numarray import random_array
from matplotlib.mlab import corrcoef
randn = random_array.standard_normal

x = randn((10,4))
r = corrcoef(x)
---------------------------------------

it gives:

corrcoef_test.py:4: DeprecationWarning: Non-ASCII character '\xc3' in 
file /usr/lib/python2.3/site-packages/matplotlib/mlab.py on line 1143, but no 
encoding declared; see http://www.python.org/peps/pep-0263.html for details
  from matplotlib.mlab import corrcoef
Numeric import failed... trying numarray.
Traceback (most recent call last):
  File "corrcoef_test.py", line 10, in ?
    r = corrcoef(x)
  File "/usr/lib/python2.3/site-packages/matplotlib/mlab.py", line 303, in 
corrcoef
    r = divide(C,denom)
  File "/usr/lib/python2.3/site-packages/numarray/generic.py", line 585, in 
_dualbroadcast
    raise ValueError("Arrays have incompatible shapes");
ValueError: Arrays have incompatible shapes


Any ideas, help?


(Just to note: There's another bug in mlab.py, in line 294 I think it should 
read "elif len(args)==1:" and not "elif len(args==1):". I changed that, 
otherwise corrcoef() would have bailed out way earlier.)


Thanks,
Sebastian

-- 
Sebastian Stark -- http://www.kyb.tuebingen.mpg.de/~stark
Max Planck Institute for Biological Cybernetics
Spemannstr. 38, 72076 Tuebingen
Phone: +49 7071 601 555 -- Fax: +49 7071 601 552

Chris Fonnesbeck wrote:

>I am wondering it it is possible to:
>
>1. Modify the spacing between subplots; currently they are cramped for
>some plots that I am generating
>
>2. Reduce the font size of the tick labels (not the axis labels);
>large font size for subplot ticks is contributing to the crowded look
>mentioned above.
>
>Perhaps I am quite blind, but I could not find these in the tutorial
>nor in a quick search of the mailing list archive.
>
>Thanks for any help.
>
>  
>
Did you check the FAQ, specifically 
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP ?

I am wondering it it is possible to:

1. Modify the spacing between subplots; currently they are cramped for
some plots that I am generating

2. Reduce the font size of the tick labels (not the axis labels);
large font size for subplot ticks is contributing to the crowded look
mentioned above.

Perhaps I am quite blind, but I could not find these in the tutorial
nor in a quick search of the mailing list archive.

Thanks for any help.

c.

Hi All,

I just added support for PIL (Python Imaging Library, for those living 
in a cave) images to imshow().  This was acheived largely through the 
creation of a pil_to_array() function in image.py, which may be useful 
for other purposes.  I've tested the code with numarray and Numeric and 
several image types and checked it into CVS this morning.

This code does not add a dependency on PIL to matplotlib -- it merely 
uses PIL object attributes if they happen to get passed in.  (I think 
it's important to keep matplotlib's dependency list from growing without 
reason.)

I would like to test the pil_to_array() function for the case of >8-bit 
per channel images that (IIRC) PIL supports.  If anyone has such images, 
could they either 1) send one to me or 2) run them through 
pil_to_array() and fix it?

Note that *display* of such high dynamic range will currently only be 
possible with single channel data passed through a colormap because the 
matplotlib's _image.cpp uses 8 bits per channel. (Not that anyone's 
display device is likely to make use of this information -- and if you 
have such a device, I'd love to hear about it!)

Cheers!
Andrew

Quoting je...@33... (je...@33...):
> I spent a (VERY) little bit of time trying to find where the border is
> drawn around each point/marker on a scatter plot and unfortunately got
> lost in the ether.
> 
> I've not found a standardized way in the api to do this.  I found that
> for lines, there's a "markeredgewidth" mentioned in the documentation,
> but I can't seem to set this for scatter plots.

well... as is usually the case, as soon as I admitted defeat and asked
for help, I found the solution. ;)

----note---------
plot = scatter(x,y,s=s,c=c,alpha=0.3)
set(plot,'linewidth',0.0)   # <---  this is what does it
----end----------

maybe someone else will find this useful, or at least google will pick
it up for the next time I forget.  heh.

If there's a better way, I'm interested to know it, but this works
quite nicely.

jeremy

-- 
Jeremy Kelley <je...@33...>
     All plenty which is not my God is poverty to me. -Augustine

Hi,

I spent a (VERY) little bit of time trying to find where the border is
drawn around each point/marker on a scatter plot and unfortunately got
lost in the ether.

I've not found a standardized way in the api to do this.  I found that
for lines, there's a "markeredgewidth" mentioned in the documentation,
but I can't seem to set this for scatter plots.

Any help would be greatly appreciated.
jeremy


-- 
Jeremy Kelley <je...@33...>
     All plenty which is not my God is poverty to me. -Augustine

>>>>> "Dirk" ==   <rep...@we...> writes:

    Dirk> I cannot get that ylabel to write it's text on the
    Dirk> right-hand side of the graph. I use two scales following the
    Dirk> 'two_scales.py' examples from the matplotlib-src, but this
    Dirk> examples doesn't put ylabels.

    Dirk> Is there a way to get a ylabel on both sides?

To make a ylabel on the right, use the text command.  You need to set
the transform to use axes coordinates (ax.transAxes), rotate the text
vertically, make the horizontal alignment left, the vertical alignment
centered.  Note that x, y = 1, 0.5 is the right, middle of the axes in
axes coordinates.  You also need to turn off clipping, so the text can
appear outside the axes w/o being clipped by the axes bounding box,
which is the default behavior.

from matplotlib.matlab import *

plot([1,2,3])

text(1.02, 0.5, 'volts',
     horizontalalignment='left',
     verticalalignment='center',
     rotation='vertical',
     transform=gca().transAxes,
     clip_on=False)
show()

I cannot get that ylabel to write it's text on the right-hand side of the
graph. I use two scales following the 'two_scales.py' examples from the
matplotlib-src, but this examples doesn't put ylabels.

Is there a way to get a ylabel on both sides?

-Dirk

In numerix.py, the following loop:

if hasattr(sys, 'argv'):        #Once again, Apache mod_python has no argv
     for a in sys.argv:
         if a in ["--Numeric", "--numeric", "--NUMERIC",
                  "--Numarray", "--numarray", "--NUMARRAY"]:
             which = a[2:], "command line"
             break

leaves behind a variable called 'a', which gets pulled in when the user does a 
'from matplotlib.matlab import *'.  This seems like a minor annoyance, except 
that it breaks ipython's 'whos' command in pylab mode, since whos tries to 
distinguish between variables interactively defined by the user and those 
loaded during internal initialization.  Since the name 'a' appears in internal 
initialization, whos hides it later:

[matplotlib]> which pylab
pylab:   aliased to ipython -pylab --nobanner
[matplotlib]> pylab

In [1]: a
Out[1]: '--nobanner'

In [2]: a='Hello!'

In [3]: a
Out[3]: 'Hello!'

In [4]: whos
Interactive namespace is empty.

A simple 'del a' after the loop indicated above fixes this issue.  In general, 
for modules which are meant for 'from foo import *', it's a good idea to make 
sure no internal locals are left around.

Best,

f

John Hunter wrote:

>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>>
>
>    >>  also in 0.60.2 i noticed that ticker.DayMultiLocator is used
>    >> on line 1518 of matplotlib/axes.py but is not imported
>
>    Peter> That was just after DayMultiLocator was added; it's a
>    Peter> bug. You can just add it yourself. I use (a little
>    Peter> modified) 60.2 as well on two production servers. It seems
>    Peter> very stable at this point.  Great majority of my plotting
>    Peter> uses plot_date and with the new changes (haven't tried -
>    Peter> just read about) I am afraid that lots of my code will
>    Peter> break. So might take this opportunity to ask:
>
>My apologies for the hassle. 
>
No need. Evolution...

> I suspect you'll find the conversion
>painless when/if you can ever work yourself up to it.  I converted all
>the datetime example code in a matter of minutes
>
> 1) convert your epoch to proleptic gregorian dates(see below)
>
> 2) remove the converter instance from the calls to plot_date
>
> 3) check your tick locator constructors replacing all 'base'
>    constructors with explicit constructors (expect for the
>    YearLocator, which still take the base arg).  Eg if you want even
>    months, do MonthLocator(range(2,13,2)) rather than MonthLocator(2)
>
>
sounds straight forward..

>
>import matplotlib.numerix as nx
>from matplotlib.dates import num2date
>
>def epoch2num(e):
>    spd = 24.*3600.
>    return 719163 + nx.asarray(e)/spd         
>
>e = range(0,20000,1000)
>d = epoch2num(e)
>
>print num2date(d[0])
>
>If everyone is happy with the conversion function name and
>implementation, I'll add it to the dates module.
>

epoch2num() looks good to me.. i usually deal with large data sets 
(often >500k points) and the conversion still seems very quick with 
Numeric. Will try to upgrade within next couple of weeks.

Thanks
Peter

P.S So when can we see your daughter join the matplotlib development? 
Judging from your usual responses to our questions/requests, I bet it's 
sometime real soon.


-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:

    >>  also in 0.60.2 i noticed that ticker.DayMultiLocator is used
    >> on line 1518 of matplotlib/axes.py but is not imported

    Peter> That was just after DayMultiLocator was added; it's a
    Peter> bug. You can just add it yourself. I use (a little
    Peter> modified) 60.2 as well on two production servers. It seems
    Peter> very stable at this point.  Great majority of my plotting
    Peter> uses plot_date and with the new changes (haven't tried -
    Peter> just read about) I am afraid that lots of my code will
    Peter> break. So might take this opportunity to ask:

My apologies for the hassle.  I suspect you'll find the conversion
painless when/if you can ever work yourself up to it.  I converted all
the datetime example code in a matter of minutes

 1) convert your epoch to proleptic gregorian dates(see below)

 2) remove the converter instance from the calls to plot_date

 3) check your tick locator constructors replacing all 'base'
    constructors with explicit constructors (expect for the
    YearLocator, which still take the base arg).  Eg if you want even
    months, do MonthLocator(range(2,13,2)) rather than MonthLocator(2)

    Peter> Does the new date plotting mechanism support the old way of
    Peter> using "seconds from epoch"? It was very efficient as a lot
    Peter> of data (not only mine I would imagine) is simply in that
    Peter> format.

I'll provide a converter func in the dates module.  This is what I
think should be done, but I'll bounce it off the list to make sure.

Epoch time starts at 1970,1,1

    >>> time.gmtime(0) 
    (1970, 1, 1, 0, 0, 0, 3, 1, 0)
    >>> dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=None)
    >>> dt.toordinal()
    719163 

So to convert to the new calendar, add 719163 and divide by seconds
per day.  Since you can do this in numerix, it shouldn't impose a
noticeable performance hit on your script

import matplotlib.numerix as nx
from matplotlib.dates import num2date

def epoch2num(e):
    spd = 24.*3600.
    return 719163 + nx.asarray(e)/spd         

e = range(0,20000,1000)
d = epoch2num(e)

print num2date(d[0])

If everyone is happy with the conversion function name and
implementation, I'll add it to the dates module.

JDH

>
> also in 0.60.2 i noticed that ticker.DayMultiLocator is used on line 
> 1518 of matplotlib/axes.py but is not imported

That was just after DayMultiLocator was added; it's a bug. You can just 
add it yourself. 

I use (a little modified) 60.2 as well on two production servers. It 
seems very stable at this point.  Great majority of my plotting uses 
plot_date and with the new changes (haven't tried - just read about) I 
am afraid that lots of my code will break. So might take this 
opportunity to ask:

Does the new date plotting mechanism support the old way of using 
"seconds from epoch"? It was very efficient as a lot of data (not only 
mine I would imagine) is simply in that format.


-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA