matplotlib-users Mailing List for matplotlib

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