You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
| 2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
| 2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
| 2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
| 2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
| 2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
| 2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
| 2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
| 2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
| 2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
| 2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
| 2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
| 2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
| 2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
(3) |
|
3
(1) |
4
(7) |
5
(11) |
6
(6) |
7
(3) |
8
(6) |
9
|
|
10
(1) |
11
(4) |
12
(5) |
13
(7) |
14
(8) |
15
|
16
(2) |
|
17
(3) |
18
|
19
(1) |
20
(7) |
21
(7) |
22
|
23
|
|
24
(1) |
25
(2) |
26
(7) |
27
(8) |
28
(3) |
29
(6) |
30
|
|
31
|
|
|
|
|
|
|
|
From: John H. <jdh...@ac...> - 2004-10-11 13:52:18
|
>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:
Alan> On Fri, 08 Oct 2004, John Hunter apparently wrote:
>> Could you send some example code when axis is used first with a
>> description of what looks wrong to you on the plot?
Alan> from scipy import * from matplotlib.matlab import *
Alan> days=arange(31) dp = 3 plot(days,dp*days,'ro') #produce a
Alan> zero axis axis([0,30,-40,100])
Alan> axhline(linewidth=0.5,color=(0,0,0)) show()
Alan> Version is 0.63. Ordered as above: axis is not honored.
Alan> Switch the order of axis() and axhline(), and all is well.
I see. Note this isn't specific to axhline. For example, in
from matplotlib.matlab import *
days=arange(31)
dp = 3
axis([0,30,-40,100])
plot(days,dp*days,'ro')
show()
the axis setting is also not obeyed because the plot command
autoscales the axes. FYI, I just tested this, and matlab behaves the
same way.
In general, I agree it would be nice in some cases to have sticky axis
limits. Probably the easiest and least intrusive way to do this would
be via a setting autoscale(False) or autoscale(True), and you could
set the default via rc. It would be easy in to check this setting in
the autoscale code before doing any work. It would be nice to be able
to access these settings in the axis or xlim/ylim commands
axis(rect, autoscale=False) # autoscaling is off for x and y axis
xlim(lim, autoscale=False) # autoscaling is off for x
and so on.
Whether this is sufficiently useful to justify coding it is an open
question.
JDH
|
|
From: John H. <jdh...@ac...> - 2004-10-11 13:33:58
|
>>>>> "Jean-Michel" == Jean-Michel Philippe <jea...@ir...> writes:
Jean-Michel> Perfect! This is exactly what I needed for one of my
Jean-Michel> apps.
Glad that worked for you.
>> But if you really want full control with no magic globals, I
>> suggest using the matplotlib API rather than the matlab
>> interface. Here is a minimal example with the SVG backend to
>> create a figure w/o the matlab interface
Jean-Michel> Well, what do you exactly mean by full control? The
Jean-Michel> fact that the figure is no more controlled by
Jean-Michel> matplotlib.matlab (as matlab does) but under my own
Jean-Michel> control? So that the application is now fully
Jean-Michel> responsible for displaying it?
Jean-Michel> NB: currently I'm targeting TkAgg.
What I mean is that is that if you want to explicitly control when
your figure windows are shown, you need to use the matplotlib API, and
example of which for tkagg is at
http://matplotlib.sf.net/examples/embedding_in_tk.py. In this case,
you explicitly make the calls to show or hide your window when you
want. If you use the matlab interface, you are constrained either to
1) if interactive is False, show all of your figures at the end of the
script when you call show or 2) if interactive is True, show all your
windows at the time of their creation.
Actually, you may have a 3rd (untested, unsupported) option with the
matlab interface. Thanks to the changes Fernando and I introduced to
support ipython, I believe as of matplotlib 0.62 it is safe to call
show repeatedly without blocking script execution. You may want to
test this and report back.
Jean-Michel> I'm afraid I don't understand why this should remove
Jean-Michel> "magic" globals, I feel some globals are still
Jean-Michel> required...
Some people do not like to use the matlab interface because it manages
the current figure and axes for them, behind the scenes. Eg when you
type plot(x,y), the plot command is sent to the current figure and
axes, as in matlab, which are stored as "global" (actually module
level) variables in matplotlib.matlab. In the matplotlib API, you
have to explicitly instantiate the figure and axes, and direct your
plotting, saving, etc commands to these instances, as in
from matplotlib.numerix import arange, sin, pi
from matplotlib.figure import Figure
f = Figure(figsize=(5,4), dpi=100)
a = f.add_subplot(111)
t = arange(0.0,3.0,0.01)
s = sin(2*pi*t)
a.plot(t,s)
In a complex, nested application or script, it is sometimes nice to
have this extra degree of clarity.
Hope this helps,
JDH
|
|
From: Jean-Michel P. <jea...@ir...> - 2004-10-11 08:17:37
|
jdh...@ac... wrote: > In 0.63, we introduced a flag on the > matplotlib.backends.draw_if_interactive function. If I must say I'm really impressed how fast matplotlib gets improved! > Eg , at the end of your script > > if draw_if_interactive._called: show() > > Note if you are using a pure image backend (eg agg, svg, ps) you do > not need show at all; this is for GUI backends only. Just call > savefig anywhere in your code. Perfect! This is exactly what I needed for one of my apps. > But if you really want full control with no magic globals, I suggest > using the matplotlib API rather than the matlab interface. Here is a > minimal example with the SVG backend to create a figure w/o the matlab > interface Well, what do you exactly mean by full control? The fact that the figure is no more controlled by matplotlib.matlab (as matlab does) but under my own control? So that the application is now fully responsible for displaying it? I'm afraid I don't understand why this should remove "magic" globals, I feel some globals are still required... NB: currently I'm targeting TkAgg. JM. Philippe |
|
From: Todd M. <jm...@st...> - 2004-10-11 00:29:56
|
On Sun, 2004-10-10 at 15:47, Darren Dale wrote: > Hello, > > I am getting invalid numeric result exceptions when dividing a complex array > by zero. Is this the desired behavior? This is what I would have expected, and examining the definition I have for complex division in numarray/Include/numarray/numcomplex.h, I don't see a problem. The definition should probably be checked by an extra set of eyes. Looks OK to me. > Also, while trying to find a way around the above problem, I ran > ieeespecial.test and got the following output. I am running numarray 1.1 on > python 2.3.3. Todd, this might be correlated with the numerix package in > matplotlib. I tried importing numarray and ieeespecial without matplotlib and > the ieeespecial.test was successful. > I tried this with an ordinary Python shell and ieeespecial.test() completed without errors. Looking at your test output, I noticed it was skewed, and guessed there was an I/O synchronization issue messing up doctest. I tried the same test under IPython w/o matplotlib and duplicated your results, so I think the problem is an IPython/doctest issue. Regards, Todd > Thanks, > > Darren > > > In [31]: ieeespecial.test() > Out[31]: inf > ***************************************************************** > Failure in example: > inf # the repr() of inf may vary from platform to platform > from line #6 of numarray.ieeespecial > Expected: inf > Got: > Out[31]: nan > ***************************************************************** > Failure in example: > nan # the repr() of nan may vary from platform to platform > from line #8 of numarray.ieeespecial > Expected: nan > Got: > Out[31]: (array([0, 2]), array([0, 3])) > ***************************************************************** > Failure in example: getinf(b) > from line #20 of numarray.ieeespecial > Expected: (array([0, 2]), array([0, 3])) > Got: > Out[31]: > array([[ 999., 1., 2., 3.], > [ 4., 5., 6., 7.], > [ 8., 9., 10., 999.], > [ 12., 13., 14., 15.]]) > ***************************************************************** > Failure in example: a > from line #26 of numarray.ieeespecial > Expected: > array([[ 999., 1., 2., 3.], > [ 4., 5., 6., 7.], > [ 8., 9., 10., 999.], > [ 12., 13., 14., 15.]]) > Got: > Out[31]: (array([0, 1, 2]), array([1, 2, 3])) > ***************************************************************** > Failure in example: getnan(a) > from line #35 of numarray.ieeespecial > Expected: (array([0, 1, 2]), array([1, 2, 3])) > Got: > ***************************************************************** > 1 items had failures: > 5 of 11 in numarray.ieeespecial > ***Test Failed*** 5 failures. > Out[31]: (5, 11) -- |