SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S






1
(1)
2
3
(12)
4
(12)
5
(22)
6
(19)
7
(9)
8
9
10
(5)
11
(1)
12
(16)
13
(8)
14
(2)
15
(1)
16
(2)
17
18
(10)
19
(14)
20
(9)
21
(4)
22
23
(2)
24
(6)
25
(2)
26
(7)
27
(7)
28
29
30






Showing 9 results of 9

From: John H. <jdh...@ac...> - 2006年04月20日 18:38:15
>>>>> "N" == N Volbers <mit...@we...> writes:
 John> I think the easiest solution might be to use nans in the
 John> transform module rather than raise an exception when
 John> transforming an array. And the clients of the transform, eg
 John> the legend auto-scaling code, can ignore the nans when
 John> deciding where to place the legend.
I just modified the transforms numerix_x_y function to insert nan
instead of raising when the transformation of an element of the
sequence fails
 In [8]: x, y = randn(2,10)
 In [9]: xt, yt = trans.numerix_x_y(x,y)
 In [11]: y
 Out[11]:
 [-0.09215005,-0.08206097, 0.92980313,-0.22293784, 0.83486353,
 0.33593831,
 -1.66880057,-0.1844854 , 0.3235668 ,-0.08853855,]
 In [12]: yt
 Out[12]:
 [ nan, nan,428.96553625,
 nan,424.47508718,386.52091534,
 nan, nan,384.95653999, nan,]
 In [13]: nx.isnan(yt)
 Out[13]: [1,1,0,1,0,0,1,1,0,1,]
Do people think this is the desired behavior? It will probably make
these functions easier to use by backend writers, who currently have
to fall back on transforming individual elements in try/except blocks
 def drawone(x, y, skip):
 try:
 if skip: raise(ValueError)
 xt, yt = transform.xy_tup((x, y))
 ret = '%g %g %c' % (xt, yt, drawone.state)
 except ValueError:
 drawone.state = 'm'
 else:
 drawone.state = 'l'
 return ret
which is probably a good bit slower.
Should all the transform methods have these symantics (nan on fail
rather than raise) or should the methods that transform single points
raise and the methods that transform sequences insert nans when
individual points fail?
I used the std c++ numeric_limits quiet_NaN
 http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/structstd_1_1numeric__limits.html#std_1_1numeric__limitse5
which worked with the MPL_isnan test from numerix on linux with
Numeric, numarray and numpy. It would probably be worth testing on
other platforms
 from pylab import subplot, nx 
 ax = subplot(111)
 ax.semilogy(nx.arange(10), nx.mlab.rand(10)) 
 trans = ax.transData
 x,y = nx.mlab.randn(2,10)
 xt,yt = trans.numerix_x_y(x,y)
 print yt
 print nx.isnan(yt)
JDH
From: John H. <jdh...@ac...> - 2006年04月20日 18:08:43
>>>>> "N" == N Volbers <mit...@we...> writes:
 N> I guess this can be considered a bug, or not?
Yes, it's a bug. We try to handle invalid transformations w/o
failing.
I think the easiest solution might be to use nans in the transform
module rather than raise an exception when transforming an array. And
the clients of the transform, eg the legend auto-scaling code, can
ignore the nans when deciding where to place the legend.
JDH
From: N. V. <mit...@we...> - 2006年04月20日 18:02:38
Hello Steven,
Steven Chaplin wrote:
>On Wed, 2006年04月19日 at 17:47 +0200, N. Volbers wrote:
> 
>
>>Consider the following settings for the Axes ax:
>>
>>ax.set_yscale('log')
>>ax.set_ylim(min=-5)
>>
>>and then redraw the axes. The negative minimum value raised an exception 
>>in my case:
>> 
>>
>
>I think it should be "ax.set_ylim(ymin=-5)".
>set_ylim() already catches this type of error.
>
>#!/usr/bin/env python
>from pylab import *
>x = arange(0.0, 20.0, 0.01)
>y = x - 10
>semilogy(x, y)
>ylabel('semilogy')
>grid(True)
>ylim(ymin=-5)
>show()
>
>Running the above script gives:
> File "./logtest.py", line 8, in ?
> ylim(ymin=-5)
> File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
>1131, in ylim
> ret = ax.set_ylim(*args, **kwargs)
> File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1314,
>in set_ylim
> raise ValueError('Cannot set nonpositive limits with log transform')
>ValueError: Cannot set nonpositive limits with log transform
>
> 
>
Yes, you are absolutely right.
Somehow I did not really understand my problem at all, but now I do!
The problem was not at all the limits. Some of my sample data contained 
a negative value, and the error message in my previous posting was 
simply saying, that you can't apply the logarithmic transformation to 
this data point. Now, whenever this happens, my error dialog appears, 
which triggers the expose event for the canvas, which again will raise 
the ValueError! There it is, my infinity loop.
But of course it is not that easy! You had negative values as well in 
your example, and nothing happened! This was because you had no legend 
that was autopositioned. Try this and see how it fails:
#!/usr/bin/env python
from pylab import *
x = arange(0.0, 20.0, 0.01)
y = x - 10
ylabel('semilogy')
grid(True)
ylim(ymin=-5)
semilogy(x, y)
legend(loc='best')
show()
I guess this can be considered a bug, or not?
Best regards,
Niklas.
From: John H. <jdh...@ac...> - 2006年04月20日 15:55:47
>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 >> 
 Jordan> No, as I said before, matplotlib 0.72 does the same thing,
 Jordan> and I have installed and run matplotlib-0.72 under cygwin
 Jordan> before, so I assume this means that cygwin is at fault
 Jordan> somehow. I'm just trying to see if I can find where it is
 Jordan> at fault so I have something specific to pester the cygwin
 Jordan> devs about.
 Jordan> Jordan
Oh, I misunderstood this. Have you tried building other C extension
modules before? How about C++ extension modules? You might try and
create a minimal SWIG C++ example and see if you can build that, and if
not you could submit that as a bug to the SWIG/cygwin devs. What is
your gcc version? Can you upgrade gcc or are you using the latest?
I use the mingw environment under win32, but not cygwin. That way you
can use gcc and gnu tools, but native win32 python and binaries. Much
easer, IMO.
JDH
From: Steven C. <ste...@ya...> - 2006年04月20日 15:49:04
On Wed, 2006年04月19日 at 17:47 +0200, N. Volbers wrote:
> Consider the following settings for the Axes ax:
> 
> ax.set_yscale('log')
> ax.set_ylim(min=-5)
> 
> and then redraw the axes. The negative minimum value raised an exception 
> in my case:
I think it should be "ax.set_ylim(ymin=-5)".
set_ylim() already catches this type of error.
#!/usr/bin/env python
from pylab import *
x = arange(0.0, 20.0, 0.01)
y = x - 10
semilogy(x, y)
ylabel('semilogy')
grid(True)
ylim(ymin=-5)
show()
Running the above script gives:
 File "./logtest.py", line 8, in ?
 ylim(ymin=-5)
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
1131, in ylim
 ret = ax.set_ylim(*args, **kwargs)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1314,
in set_ylim
 raise ValueError('Cannot set nonpositive limits with log transform')
ValueError: Cannot set nonpositive limits with log transform
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 
From: Jordan D. <jdawe@u.washington.edu> - 2006年04月20日 15:41:24
> The VERBOSE flags generate runtime, not compile time information, so
> try reimporting a module that fails and see if you get any extra
> info. Eg matplotlib.backends._backend_agg
>
> Also, please confirm that matplotlib._agg also dumps.
> 
Oh! Ok, yeah, they all still dump, including matplotlib._agg, and the 
verbose compile doesn't seem to add any new info.
> I find it odd that an extension built with SWIG, and one built with
> PYCXX, have the same behavior, since their is almost no overlap in
> these tools. It suggests something may be wrong with your setup
> rather than matplotlib. In your current environment, can you still
> build and run an older mpl?
> 
No, as I said before, matplotlib 0.72 does the same thing, and I have 
installed and run matplotlib-0.72 under cygwin before, so I assume this 
means that cygwin is at fault somehow. I'm just trying to see if I can 
find where it is at fault so I have something specific to pester the 
cygwin devs about.
Jordan
From: Jordan D. <jdawe@u.washington.edu> - 2006年04月20日 15:06:15
>
> First thing to try is simply rm -rf the site-packages/matplotlib and
> build subdirs and get a clean install. Installing a new version over
> a pretty old version has been known to cause trouble, segfault, etc.
> 
I always wipe the install and build directories before installing a new 
version.
> Try importing these packages individually
>
> import matplotlib._image
> import matplotlib._transforms
>
> #one of these three depending on which numerix package you are using
> import matplotlib.backends._na_backend_agg # for numarray
> import matplotlib.backends._nc_backend_agg # for Numeric
> import matplotlib.backends._ns_backend_agg # for numpy
>
> import matplotlib.backends._tkagg
> import matplotlib._agg
> 
All of them simply dump to the command line (though I only tried 
Numeric, not numpy or numarray).
> If that shed additional light, again flush the build and install dirs,
> and try setting VERBOSE=True in setup.py before doing a clean install.
> The VERBOSE setting will generate lots of extra output and may help
> indicate where the segfault is occurring 
Hmm. There are a bunch of warnings that one might be using variables 
uninitialized (which I'm ignoring as compiler whining), and a series of 
warning like this:
./CXX/Extensions.hxx: In constructor 
`Py::PythonExtension<T>::PythonExtension() [with T = LazyValue]':
src/_transforms.h:57: instantiated from here
./CXX/Extensions.hxx:477: warning: right-hand operand of comma has no 
effect
I suspect these are harmless as well, but I don't really know c++ so I 
can't tell what it's complaining about.
Jordan
From: John H. <jdh...@ac...> - 2006年04月20日 13:38:48
>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 Jordan> I've tried this with Numeric 24.2, Numeric 24.0, numpy
 Jordan> 0.9.6, matplotlib svn, matplotlib-0.86, and
 Jordan> matplotlib-0.74; all give the same result. I believe this
 Jordan> is a problem with cygwin, because a year or so ago I
 Jordan> installed matplotlib-0.74 with Numeric-24.0 and it worked
 Jordan> fine. Note that "import matplotlib" appears to work, but
 Jordan> "import matplotlib.pylab" does not. Any idea what's going
 Jordan> wrong, or suggestions about where to start hacking?
First thing to try is simply rm -rf the site-packages/matplotlib and
build subdirs and get a clean install. Installing a new version over
a pretty old version has been known to cause trouble, segfault, etc.
Try importing these packages individually
 import matplotlib._image
 import matplotlib._transforms
 #one of these three depending on which numerix package you are using
 import matplotlib.backends._na_backend_agg # for numarray
 import matplotlib.backends._nc_backend_agg # for Numeric
 import matplotlib.backends._ns_backend_agg # for numpy
 import matplotlib.backends._tkagg
 import matplotlib._agg
If the last two work and the others don't, it is likely you need to
upgrade your gcc, because on some platforms (OS X for sure) old
versions of gcc cannot compile new versions of pycxx, which matplotlib
uses for building some but not all of it's extensions. Report back
which if any work or segfault or raise tracebacks,
If that shed additional light, again flush the build and install dirs,
and try setting VERBOSE=True in setup.py before doing a clean install.
The VERBOSE setting will generate lots of extra output and may help
indicate where the segfault is occurring 
JDH
PS I just added these instructions to svn in a file called SEGFAULTS.
We should add tricks and trips for diagnosing segfaults here.
From: Jordan D. <jdawe@u.washington.edu> - 2006年04月20日 04:28:10
Does anyone have any idea why matplotlib now crashes python under 
cygwin? Here's what I did:
1. Install cygwin, including gcc, python, and the libpng and libfreetype 
development packages.
2. Install Numeric 24.2 from tar.gz file. This works fine.
3. Install matplotlib from svn. This works fine.
4. Execute "from pylab import *" inside python. Instant dump to the 
bash shell without error message. Setting verbose=debug-annoying 
doesn't add any information.
Let's show the whole thing in gory detail, shall we?
-----------------------------
freedryk@jlaptop ~
$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from pylab import *
loaded rc file /cygdrive/d/freedryk/.matplotlib/matplotlibrc
matplotlib version 0.88
verbose.level debug-annoying
interactive is False
platform is cygwin
loaded modules: ['pylab', '_bisect', '__future__', 'copy_reg', 
'sre_compile', 'd
istutils', 'itertools', '_sre', '__main__', 'site', '__builtin__', 
'datetime', '
matplotlib.re', 'matplotlib.tempfile', 'encodings', 'pytz.datetime', 
'shutil', '
distutils.string', 'dateutil', 'matplotlib.datetime', 'posixpath', 
'_random', 't
empfile', 'errno', 'matplotlib.warnings', 'binascii', 
'encodings.codecs', 'sre_c
onstants', 're', 'matplotlib.md5', 'os.path', 'pytz.sys', '_codecs', 
'distutils.
sysconfig', 'encodings.exceptions', 'pytz.sets', 'math', 'fcntl', 
'stat', 'zipim
port', 'string', 'warnings', 'encodings.types', 'UserDict', 
'encodings.ascii', '
matplotlib.sys', 'matplotlib', 'distutils.os', 'sys', 'pytz.tzinfo', 
'pytz', 'ma
tplotlib.__future__', 'codecs', 'distutils.re', 'readline', 
'matplotlib.pytz', '
types', 'md5', 'matplotlib.dateutil', 'matplotlib.os', 'thread', 'sre', 
'bisect'
, 'matplotlib.distutils', 'signal', 'distutils.errors', 'random', 
'linecache', '
matplotlib.shutil', 'posix', 'encodings.aliases', 'sets', 'exceptions', 
'sre_par
se', 'pytz.bisect', 'distutils.sys', 'os', 'strop']
numerix Numeric 24.2
freedryk@jlaptop ~
$
--------------------------------
I've tried this with Numeric 24.2, Numeric 24.0, numpy 0.9.6, matplotlib 
svn, matplotlib-0.86, and matplotlib-0.74; all give the same result. I 
believe this is a problem with cygwin, because a year or so ago I 
installed matplotlib-0.74 with Numeric-24.0 and it worked fine. Note 
that "import matplotlib" appears to work, but "import matplotlib.pylab" 
does not. Any idea what's going wrong, or suggestions about where to 
start hacking?
Jordan Dawe

Showing 9 results of 9

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /