matplotlib-users Mailing List for matplotlib (Page 1402)

>>>>> "Samir" == Samir Patel <mep...@ya...> writes:

    Samir> I am getting following error while compiling later version
    Samir> of matplotlib with gcc 3.4.2: Any clue?

This is a pycxx bug that is fixed in pycxx and matplotlib cvs.  See
http://sourceforge.net/mailarchive/message.php?msg_id=9683332 for the
solution -- replace map(s) with map(m) on the offending line 2271 in
CXX/Objects.hxx.

Hope this helps,
JDH

> Date: Mon, 25 Oct 2004 20:40:02 -0400
> From: Gary <pa...@in...>
> To: Chris Barker <Chr...@no...>
> CC:  mat...@li...
> Subject: Re: [Matplotlib-users] TeX in xlabel ?
>
> Chris Barker wrote:
>
> > 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
> >
> Matplotlib doesn't support \text, and it requires that the first and
> last characters of a TeX string be $.  I guess it only processes
> mathmode.    Well, it can't do *everything*.  It would be nice to figure
> out a workaround...

Gary's example
     xlabel(r'$\rm{Normalized Temperature} (kT/\epsilon)$'
USED to work, in earlier versions of Matplotlib. It no longer does. I have
posted a similar issue a little while ago:
     http://sourceforge.net/mailarchive/message.php?msg_id=9681306
Unfortunately, I haven't really had the time to dig into the code to see what
has changed, but when I do, I'll let you know what I find. The solution
     xlabel(r'$\rm{Normalized \ Temperature} (kT/\epsilon)$'
somehow isn't entirely satisfactory.

As far as I can see, \rm{} in Matplotlib should act just the way \mbox{} does in
LaTeX, when you are already in math mode. And certainly, in LaTeX,
$$
xy = 0 \mbox{ but however } x \neq y
$$
produces the expected output in the expected fonts and with the expected
spacing.

Dominique

I am getting following error while compiling later
version of matplotlib with gcc 3.4.2: Any clue?

**********************************************


running build_ext
building 'matplotlib._nc_transforms' extension
creating build/temp.linux-i686-2.3
creating build/temp.linux-i686-2.3/src
creating build/temp.linux-i686-2.3/CXX
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -fPIC -Isrc -I.
-I/usr/include/python2.3 -c
CXX/IndirectPythonInterface.cxx -o
build/temp.linux-i686-2.3/CXX/IndirectPythonInterface.o
-DNUMERIC=1
cc1plus: warning: command line option
"-Wstrict-prototypes" is valid for C/ObjC but not for
C++
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -fPIC -Isrc -I.
-I/usr/include/python2.3 -c CXX/cxxsupport.cxx -o
build/temp.linux-i686-2.3/CXX/cxxsupport.o -DNUMERIC=1
cc1plus: warning: command line option
"-Wstrict-prototypes" is valid for C/ObjC but not for
C++
In file included from CXX/cxxsupport.cxx:6:
./CXX/Objects.hxx: In constructor
`Py::MapBase<T>::const_iterator::const_iterator(const
Py::MapBase<T>*, Py::List,
Py::SeqBase<Py::Object>::iterator)':
./CXX/Objects.hxx:2271: error: `s' undeclared (first
use this function)
./CXX/Objects.hxx:2271: error: (Each undeclared
identifier is reported only once for each function it
appears in.)
error: command 'gcc' failed with exit status 1
[spatel@taamportable matplotlib-0.63.4]$ gcc --version
gcc (GCC) 3.4.2


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

John Hunter wrote:

[snip]

> One is to fall back on tex where available as a command line tool (as
> pyx does, I believe), and use other command line tools to convert the
> dvi to png or some other raster format and then embed it.  This would
> require a few external libs and utilities, but it's certainly doable.

+1 for (relatively) low-hanging fruit.

> Another idea I had while reading Knuth's "TeX: The Program" is to use
> the layout information in the TFM font metric files.  Apparently math
> fonts have additional layout information in them, like where to place
> superscripts.  I've looked at several tfm parsing implementations, and
> haven't found one yet that actually extracts this information; most
> extract the standard font information but not the special math
> information.  But if we could access this info, we could include the
> tfm files for common raster sizes and use the layout info crafted by
> the master himself.

I wish you luck!

> A third possibility would be to support mathml, using some good mathml
> renderer.  Is there a good, free mathml rendering library - what does
> mozilla use for this?

Mozilla's MathML is inextricably linked into Gecko[1] and cannot be torn 
out of it.

I've seen some programs out there that render MathML to either rasters 
or SVG, but they are either commercial or (L)GPL. They are also usually 
written in Java or C#.

Some possibilities gleaned from 
http://www.w3.org/Math/implementations.html :

* GtkMathView: C++, GPL, already has Perl and PHP bindings
   http://helm.cs.unibo.it/mml-widget/

Okay, that was the only one I found.

In any case, I would not want to be directly writing MathML; it is not 
intended to be human-writable. There are, however, programs that will 
convert a restricted mathematical subset of LaTeX to MathML[2]. There 
are also a few non-TeX syntaxes drifting around with converters to MathML.

[1] http://www.mozilla.org/projects/mathml/enable.html
[2] http://pear.math.pitt.edu/mathzilla/

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

John Hunter wrote:
>>>>>>"Chris" == Chris Barker <Chr...@no...> writes:
> 
> 
>     Chris> Gary wrote:
>     >> Matplotlib doesn't support \text, and it requires that the
>     >> first and last characters of a TeX string be $.  I guess it
>     >> only processes mathmode.  Well, it can't do *everything*.
> 
> It is on the goals page (http://matplotlib.sourceforge.net/goals.html)
> to support embedded math strings like
> 
>   s = r'Mean ($\mu=5) and standard deviation ($\sigma=1$)'

did you mean:

s = r'Mean ($\mu=5$) and standard deviation ($\sigma=1$)'

I think there was a missing "$".

That would be nice.

> It would be nice to be able to choose one or the other --

that would be nice.

> It would be a monster job.  There is basically no way to factor tex
> into components -- it's a monolithic system, in part because of the
> heavy use of web macros.

Ah. too bad. It's nice to know you've looked into this some.

 > And web2c, the conversion of web/pascal to
> c, is GPLd and less permissive than the matplotlib license.  So
> embedding tex is a no-go, aside from size considerations.

web2c is essentially a compiler of sorts, isn't it? So there wouldn't be 
  any problem with distributing C code created by it would there? In any 
case, there are LOTS of commercial TeX distributions out there, so there 
must be a way. This doesn't address the other big issues, however.

AmiPro, the word processor bought by Lotus, then later turned into 
WordPro, used TeX to format math. I used it for years before I 
discovered LaTeX because it had such nice math rendering (MS Word's 
still sucks!). They somehow managed to embed it, so I suppose it can be 
done! That doesn't mean it's the least bit easy, however.

>  But there
> are some possibilities for improving what matplotlib already offers.

good news, of course.

> One is to fall back on tex where available as a command line tool (as
> pyx does, I believe), and use other command line tools to convert the
> dvi to png or some other raster format and then embed it.  This would
> require a few external libs and utilities, but it's certainly doable.

That would be a nice option, but I'd rather see a DVI driver built in to 
Matplotlib, than a raster format. That's how PyX does it. I guess that 
would require matplotlib to have the same fonts, however. Another option 
would be PDF or EPS, but that would probably only be convenient for PS 
and/or PDF output.

> Another idea I had while reading Knuth's "TeX: The Program" is to use
> the layout information in the TFM font metric files.  Apparently math
> fonts have additional layout information in them, like where to place
> superscripts.  I've looked at several tfm parsing implementations, and
> haven't found one yet that actually extracts this information; most
> extract the standard font information but not the special math
> information.  But if we could access this info, we could include the
> tfm files for common raster sizes and use the layout info crafted by
> the master himself.

very cool.

> A third possibility would be to support mathml, using some good mathml
> renderer.  Is there a good, free mathml rendering library - what does
> mozilla use for this?

good question. That would be nice, too.


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

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

    Chris> Gary wrote:
    >> Matplotlib doesn't support \text, and it requires that the
    >> first and last characters of a TeX string be $.  I guess it
    >> only processes mathmode.  Well, it can't do *everything*.

It is on the goals page (http://matplotlib.sourceforge.net/goals.html)
to support embedded math strings like

  s = r'Mean ($\mu=5) and standard deviation ($\sigma=1$)'

This wouldn't be too hard - just takes some time that I haven't had of
late.

    Chris> Oh well, I've always thought that if you want to support
    Chris> Math in a graphics package, you would actually use TeX,
    Chris> rather than emulating it. Maybe like PyX:

    Chris> http://pyx.sourceforge.net/

Yes, but you lose the platform independence and portability by doing
this.  It would be nice to be able to choose one or the other -- see
below.

    Chris> The problem, of course, is that requiring a TeX system is a
    Chris> BIG dependency! It would be nice if one could re-package
    Chris> the Tex interpreter to be embedded. I have no idea how big
    Chris> a job that would be. You'd also have all the font issues,
    Chris> of course, but while that would all be a lot of work, I'm
    Chris> not sure it would be more work than trying to re-write TeX!

It would be a monster job.  There is basically no way to factor tex
into components -- it's a monolithic system, in part because of the
heavy use of web macros.  And web2c, the conversion of web/pascal to
c, is GPLd and less permissive than the matplotlib license.  So
embedding tex is a no-go, aside from size considerations.  But there
are some possibilities for improving what matplotlib already offers.

One is to fall back on tex where available as a command line tool (as
pyx does, I believe), and use other command line tools to convert the
dvi to png or some other raster format and then embed it.  This would
require a few external libs and utilities, but it's certainly doable.

Another idea I had while reading Knuth's "TeX: The Program" is to use
the layout information in the TFM font metric files.  Apparently math
fonts have additional layout information in them, like where to place
superscripts.  I've looked at several tfm parsing implementations, and
haven't found one yet that actually extracts this information; most
extract the standard font information but not the special math
information.  But if we could access this info, we could include the
tfm files for common raster sizes and use the layout info crafted by
the master himself.

A third possibility would be to support mathml, using some good mathml
renderer.  Is there a good, free mathml rendering library - what does
mozilla use for this?

JDH

On Tue, 26 Oct 2004, Chris Barker wrote:

> Gary wrote:
>
> > Matplotlib doesn't support \text, and it requires that the first and
> > last characters of a TeX string be $.  I guess it only processes
> > mathmode.    Well, it can't do *everything*.
>
> Oh well, I've always thought that if you want to support Math in a
> graphics package, you would actually use TeX, rather than emulating it.
> Maybe like PyX:
>
> http://pyx.sourceforge.net/
>
> The problem, of course, is that requiring a TeX system is a BIG
> dependency! It would be nice if one could re-package the Tex interpreter
> to be embedded. I have no idea how big a job that would be. You'd also
> have all the font issues, of course, but while that would all be a lot
> of work, I'm not sure it would be more work than trying to re-write TeX!
>
> -Chris

OTOH: many people working in science will already have a TeX system
installed, I'd guess.

Another thought: What about an optional PyX back-end for matplotlib?
(If one is interested in really good postscript
output I think PyX is great. Transparency etc.
might be problematic with postscript,
but a combination of postscript lines, symbols and math with bitmapped
graphics should be possible for the PyX back-end).

Best,

Arnd

P.S.: Just to be sure: I am not saying that the postscript
output of matplotlib is bad (Haven't even tested it).

Gary wrote:

> Matplotlib doesn't support \text, and it requires that the first and 
> last characters of a TeX string be $.  I guess it only processes 
> mathmode.    Well, it can't do *everything*. 

Oh well, I've always thought that if you want to support Math in a 
graphics package, you would actually use TeX, rather than emulating it. 
Maybe like PyX:

http://pyx.sourceforge.net/

The problem, of course, is that requiring a TeX system is a BIG 
dependency! It would be nice if one could re-package the Tex interpreter 
to be embedded. I have no idea how big a job that would be. You'd also 
have all the font issues, of course, but while that would all be a lot 
of work, I'm not sure it would be more work than trying to re-write TeX!

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

Chris Barker wrote:

> 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
>
Matplotlib doesn't support \text, and it requires that the first and 
last characters of a TeX string be $.  I guess it only processes 
mathmode.    Well, it can't do *everything*.  It would be nice to figure 
out a workaround...

thx,
-gary

Hi there, I tried to install from CVS and got the following error from
an existing script.  I haven't looked deeply for the cause because it
seems likely to be something to do with John's post a few days ago.

[cory@fog 050]$ python IQplots.py
Traceback (most recent call last):
  File "IQplots.py", line 2, in ?
    from matplotlib.matlab import *
  File "/eosmls/local/linux/lib/python/matplotlib/matlab.py", line 161,
in ?
    from axes import Axes, PolarAxes
  File "/eosmls/local/linux/lib/python/matplotlib/axes.py", line 9, in ?
    from artist import Artist
  File "/eosmls/local/linux/lib/python/matplotlib/artist.py", line 4, in
?
    from transforms import identity_transform
  File "/eosmls/local/linux/lib/python/matplotlib/transforms.py", line
182, in ?
    from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY
ImportError: cannot import name POLAR

Cheers,
Cory.


-- 
))))))))))))))))))))))))))))))))))))))))))))
Cory Davis
Meteorology
School of GeoSciences
University of Edinburgh
King's Buildings
EDINBURGH EH9 3JZ

ph: +44(0)131 6505092
fax +44(0)131 6505780
cd...@st...
co...@me...
http://www.geos.ed.ac.uk/contacts/homes/cdavis
))))))))))))))))))))))))))))))))))))))))))))

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 ?