matplotlib-devel Mailing List for matplotlib (Page 6)

He really meant matplotlib-0.87.2, I think :-)
JDH

Compiled against numpy-0.9.6
http://sourceforge.net/project/showfiles.php?group_id=3D80706
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2006年03月16日 Released 0.87.2
2006年03月15日 Fixed bug in MaxNLocator revealed by da...@in....
 The main change is that Locator.nonsingular now adjusts
 vmin and vmax if they are nearly the same, not just if
 they are equal. A new kwarg, "tiny", sets the threshold. -
 EF
2006年03月14日 Added import of compatibility library for newer numpy
 linear_algebra - TEO
2006年03月12日 Extended "load" function to support individual columns and
 moved "load" and "save" into matplotlib.mlab so they can be
 used outside of pylab -- see examples/load_converter.py -
 JDH
2006年03月12日 Added AutoDateFormatter and AutoDateLocator submitted
 by James Evans. Try the load_converter.py example for a
 demo. - ADS
2006年03月11日 Added subprocess module from python-2.4 - DSD
2006年03月11日 Fixed landscape orientation support with the usetex
 option. The backend_ps print_figure method was
 getting complicated, I added a _print_figure_tex
 method to maintain some degree of sanity - DSD
2006年03月11日 Added "papertype" savefig kwarg for setting
 postscript papersizes. papertype and ps.papersize
 rc setting can also be set to "auto" to autoscale
 pagesizes - DSD
2006年03月09日 Apply P-J's patch to make pstoeps work on windows
 patch report # 1445612 - DSD
2006年03月09日 Make backend rc parameter case-insensitive - DSD
2006年03月07日 Fixed bug in backend_ps related to C0-C6 papersizes,
 which were causing problems with postscript viewers.
 Supported page sizes include letter, legal, ledger,
 A0-A10, and B0-B10 - DSD

John Hunter wrote:
> Hey Travis,
> 
> I was just browsing your latest numerix commit and had two questions
> 
> elif which[0] == "numpy":
> from numpy.linalg import *
> try:
> from numpy.linalg.old import *
> except:
> pass
> 
> 
> is this expected to work with numpy <0.9.6 as well as the latest
> release, or just the latest? I'm happy either way, but just want to
> know how to advise the users on which numpy versions are supported.
It should work with older versions, too. This change moved the Numeric
LinearAlgebra-compatibility aliases into numpy.linalg.old . If numpy.linalg.old
doesn't exist because numpy is not current, then the aliases should still be in
numpy.linalg .
> And on the try/except, would it suffice to just catch an ImportError?
> We've been bitten before on these catchall exceptions. 
Yes, I believe so.
-- 
Robert Kern
rob...@gm...
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Hey Travis,
I was just browsing your latest numerix commit and had two questions
elif which[0] == "numpy":
 from numpy.linalg import *
 try:
 from numpy.linalg.old import *
 except:
 pass
is this expected to work with numpy <0.9.6 as well as the latest
release, or just the latest? I'm happy either way, but just want to
know how to advise the users on which numpy versions are supported.
And on the try/except, would it suffice to just catch an ImportError?
We've been bitten before on these catchall exceptions. 
Thanks
JDH

On 3/14/06, Darren Dale <dd...@co...> wrote:
> On Tuesday 14 March 2006 9:28 pm, Darren Dale wrote:
> > Perhaps bugs tend to sneak in because there is little or no warning bef=
ore
> > releases.
>
> Sorry, I didnt mean that to sound so blunt or argumentative. I have been
> spending the last two days recovering a trashed system, the one on which =
I do
> all my MPL development. I havent seen any bug reports related to my recen=
t
> changes, but I had wanted to get the new API (draw_markers) together for =
the
> next release. That can wait.
You're absolutley right. I have just been helping with the last few
releases and it's still a leaning process. I'll hold off until
Thursday or Friday for 0.87.2. In the future we'll give a few days
warning on minor releases.
- Charlie

On Tuesday 14 March 2006 9:56 pm, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> On Tuesday 14 March 2006 9:28 pm, Darren Dale wrote:
> >> Perhaps bugs tend to sneak in because there is little or no
> >> warning before releases.
>
> How much warning is desirable? I think for major point releases more
> is good, but for bug fix releases perhaps it is less important?
In this case, since it was announced that this release would hopefully stand 
for some time, I think it would be good to have a few days warning.

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> On Tuesday 14 March 2006 9:28 pm, Darren Dale wrote:
 >> Perhaps bugs tend to sneak in because there is little or no
 >> warning before releases.
How much warning is desirable? I think for major point releases more
is good, but for bug fix releases perhaps it is less important?
 Darren> Sorry, I didnt mean that to sound so blunt or
 Darren> argumentative. I have been spending the last two days
 Darren> recovering a trashed system, the one on which I do all my
 Darren> MPL development. I havent seen any bug reports related to
 Darren> my recent changes, but I had wanted to get the new API
 Darren> (draw_markers) together for the next release. That can
 Darren> wait.
I think this would best go into a major release in any case, but I
glad to hear you are revisiting it.
JDH

On Tuesday 14 March 2006 9:28 pm, Darren Dale wrote:
> Perhaps bugs tend to sneak in because there is little or no warning before
> releases.
Sorry, I didnt mean that to sound so blunt or argumentative. I have been 
spending the last two days recovering a trashed system, the one on which I do 
all my MPL development. I havent seen any bug reports related to my recent 
changes, but I had wanted to get the new API (draw_markers) together for the 
next release. That can wait. 
Darren
> On Tuesday 14 March 2006 8:05 pm, Charlie Moad wrote:
> > Please check in anything you want to make the 0.87.2 release
> > tomorrow. The last two releases have had last minute bugs sneak in so
> > please hold off on major changes and test the small ones before
> > committing. It will hopefully be a stable release to ride for a
> > little while barring anymore numpy bumps.
> >
> > Thanks,
> > Charlie
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid 0944&bid1720ドル&dat 1642
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Perhaps bugs tend to sneak in because there is little or no warning before 
releases.
Darren
On Tuesday 14 March 2006 8:05 pm, Charlie Moad wrote:
> Please check in anything you want to make the 0.87.2 release
> tomorrow. The last two releases have had last minute bugs sneak in so
> please hold off on major changes and test the small ones before
> committing. It will hopefully be a stable release to ride for a
> little while barring anymore numpy bumps.
>
> Thanks,
> Charlie
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid1720ドル&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
dd...@co...

 Please check in anything you want to make the 0.87.2 release
tomorrow. The last two releases have had last minute bugs sneak in so
please hold off on major changes and test the small ones before
committing. It will hopefully be a stable release to ride for a
little while barring anymore numpy bumps.
Thanks,
 Charlie

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Here is a simple illustration of the problem and
 Eric> inconsistency, using just the first few points in
 Eric> Tennessee's plot and a few lines from his script. With a
 Eric> log scale for y, the Agg backends are leaving gaps (breaking
 Eric> the line) at the points where y==0; the PS and SVG backends
 Eric> are removing those points, but *not* breaking the line. I
 Eric> think the Agg behavior is much better. But maybe it would
 Eric> be better yet to raise an exception, forcing the user to
 Eric> deal with the error explicitly. For example, the user might
 Eric> want to change the zero values to a very small number, and
 Eric> then explicitly set the y range to exclude the small
 Eric> numbers. This is illustrated in the second subplot.
This issue has a long history, which I'll summarize here. In the old
days, we raised an exception when non-positive numbers were passed to
log plotting. Most people found this objectionable, and prefer to see
the valid points plotted rather than nothing (though a warning would
be nice). This is what matlab does. I needed to make some
architectural changes to support this, because the transformations
happened in the lines class which passed the transformed data to the
backend. 
I looked into filtering the data in the lines class (basically what
you did for ma data) but did not think it would be fast enough,
because we potentially would have had to create a lot of line
segments.
So I changed the backend API and modified draw_lines to take the
transformation as an argument. Then the backend can do the following
(eg _backend_agg)
 if (needNonlinear)
 try {
	mpltransform->nonlinear_only_api(&thisx, &thisy);
 }
 catch (...) {
	moveto = true;
	continue;
 }
Ie if there is a nonlinear transformation that raises an exception,
the path state is changed from lineto to moveto. This is very fast,
at least an order of magnitude faster than trying to compute the
segments at the python level I suspect.
At the same time I introduced some optimizations for marker drawing
with a new backend method called draw_markers that also does the
transformations in the backend. This made marker drawing up to 25
times faster (we used to draw every marker as a separate function call
in lines.py)
We decided to support both old and new style APIs in the "transition
period" which made it easy for other backends to do ..... nothing. So
that is why the other backends haven't implemented this feature yet.
Steve worked on it a bit for Cairo and Darren and I both did for PS
but never got a working product. You can see the attempt in
backend_ps _draw_markers method (underscore hidden) and in
backend_cairo's draw_markers_OLD method. There was extensive
discussion on this list with the API and implementation details so
just search for draw_markers if you are interested.
So the backend is now in what I call a schizophrenic state, in two
ways. 
 1) some backends use the old and some use the "newstyle" API
 2) Even in the newstyle API, some methods do the transformation in
 the front end (draw_rectangle) and some in the backend
 (draw_markers). 
There is a need to simplify, unify and rationalize this API, but since
it mostly works, there has not been a lot of pressure to do so. And
it would break a lot of backends that may not be actively maintained.
A modest short term goal should be to get the newstyle draw_lines and
draw_markers working for the PS backend, both to fix this log problem
and because it is faster and potentially much smaller in terms of PS
file sizes. Something for a rainy day.
JDH

John Hunter wrote:
>>>>>>"Tennessee" == Tennessee Leeuwenburg <ten...@te...> writes:
> 
> Tennessee> That could certainly explain it.
> 
> Tennessee> I don't know that I agree that it's correct -- I'm not
> Tennessee> graphing log(X), I'm graphing X, and 0 is a valid value
> Tennessee> for it. Only the scale is logarithmic, but it still
> Tennessee> contains a 0. I'll bow to a more expert opinion if
> Tennessee> there's disagreement.
> 
> If you posst your script, we might be able to give a more informed
> opinion of what the desired output should be :-) I understand that
> there are some largish data files that you don't want to post, but if
> we could just read the script alone that might be enough.
> 
> JDH
John,
Here is a simple illustration of the problem and inconsistency, using 
just the first few points in Tennessee's plot and a few lines from his 
script. With a log scale for y, the Agg backends are leaving gaps 
(breaking the line) at the points where y==0; the PS and SVG backends 
are removing those points, but *not* breaking the line. I think the Agg 
behavior is much better. But maybe it would be better yet to raise an 
exception, forcing the user to deal with the error explicitly. For 
example, the user might want to change the zero values to a very small 
number, and then explicitly set the y range to exclude the small 
numbers. This is illustrated in the second subplot.
I haven't looked into it, but I suspect the log(0) values are becoming 
nans, so what we are seeing is differences in nan-handling among the 
backends.
Eric

>>>>> "Tennessee" == Tennessee Leeuwenburg <ten...@te...> writes:
 Tennessee> That could certainly explain it.
 Tennessee> I don't know that I agree that it's correct -- I'm not
 Tennessee> graphing log(X), I'm graphing X, and 0 is a valid value
 Tennessee> for it. Only the scale is logarithmic, but it still
 Tennessee> contains a 0. I'll bow to a more expert opinion if
 Tennessee> there's disagreement.
If you posst your script, we might be able to give a more informed
opinion of what the desired output should be :-) I understand that
there are some largish data files that you don't want to post, but if
we could just read the script alone that might be enough.
JDH

On Mon, 2006年03月13日 at 20:08 -1000, Eric Firing wrote:
> Tennessee Leeuwenburg wrote:
> > I've sent Eric the files off-list. Anyone else who wants them, let me
> > know. The bundle is about 400Kb -- not huge but not tiny. The script
> > itself is small, it's just the data file and the output images which
> > take up the space.
> > 
> > The .png and onscreen renderer are both missing line segments, and
> > behave in the same way. The .svg renderer behaves as expected.
> > 
> > I'm running a very up-to-date linux, and I installed matplotlib newly
> > about 4 days ago.
> > 
> > Cheers,
> > -T
> 
> Tennessee,
> 
> The first thing I notice is that you are trying to plot with log-log 
> scales, but some of your y values are zero. Log(0) is undefined. The 
> Agg renderers are doing something sensible: leaving out the 0 values. 
> It is actually the ps and svg renderers that are incorrect, in that they 
> seem to be substituting a value of 1 for each zero; they are bridging 
> what *should* be gaps.
> 
> Eric
That could certainly explain it. 
I don't know that I agree that it's correct -- I'm not graphing log(X),
I'm graphing X, and 0 is a valid value for it. Only the scale is
logarithmic, but it still contains a 0. I'll bow to a more expert
opinion if there's disagreement.
Cheers,
-T

Tennessee Leeuwenburg wrote:
> I've sent Eric the files off-list. Anyone else who wants them, let me
> know. The bundle is about 400Kb -- not huge but not tiny. The script
> itself is small, it's just the data file and the output images which
> take up the space.
> 
> The .png and onscreen renderer are both missing line segments, and
> behave in the same way. The .svg renderer behaves as expected.
> 
> I'm running a very up-to-date linux, and I installed matplotlib newly
> about 4 days ago.
> 
> Cheers,
> -T
Tennessee,
The first thing I notice is that you are trying to plot with log-log 
scales, but some of your y values are zero. Log(0) is undefined. The 
Agg renderers are doing something sensible: leaving out the 0 values. 
It is actually the ps and svg renderers that are incorrect, in that they 
seem to be substituting a value of 1 for each zero; they are bridging 
what *should* be gaps.
Eric

I've sent Eric the files off-list. Anyone else who wants them, let me
know. The bundle is about 400Kb -- not huge but not tiny. The script
itself is small, it's just the data file and the output images which
take up the space.
The .png and onscreen renderer are both missing line segments, and
behave in the same way. The .svg renderer behaves as expected.
I'm running a very up-to-date linux, and I installed matplotlib newly
about 4 days ago.
Cheers,
-T

James Evans wrote:
>Andrew,
>
>The easiest way to see this bug is to use the QtAgg backend, then type the following:
>
> 
>
>>>>import pylab
>>>>pylab.figure(figsize=(1, 1))
>>>>pylab.show()
>>>> 
>>>>
>
>and the window you get will most definitly not be using the sizes you set forth.
> 
>
OK, I see the issue using QtAgg. Patched in 2143.
I thought I tested the resize events by, well, resizing windows by
dragging the corner, and everything seemed fine. Strangely, though, the
patch I just applied doesn't seem necessary on a Qt (not QtAgg) backend.

>>>>> "James" == James Evans <jre...@ea...> writes:
 James> the problem being that this will only set the property of
 James> the first 'n' labels, where 'n' is the number of tickmarks
 James> present when you initially set the property. So if the
 James> number of tick marks increases when zooming in (or out),
 James> then the remaining labels above 'n' will not have the
 James> property set. You can see this by running the example
 James> script "simple_plot.py" and rotating the labels (as above)
 James> and then zooming in and out until you have more than the
 James> initial number of ticks.
Hmm, this shouldn't happen. There is logic in the axis class when
creating a new tick to copy the properties of the existing ticks.
There is a "protoTick" ie the prototype tick, which is used to get the
properties when creating a new tick. The Axis._copy_tick_props method
is used to transfer the properties from the protoTick to the new tick.
That in turn calls the "update_from" method of the text instances,
which does copy the rotation value.
So it *should* work on a quick code read, but clearly it doesn't from
your reported problem. You may want to poke around this section of
the code to see where the logic is failing.
JDH

John,
I had noticed that as well, and when I used it I was rotating the labels by "-90" degrees to
see them more clearly. But doing so uncovers a bug/feature when using any AutoTickLocator
mechanism.
When you want to rotate the labels, you do so by doing something like the following:
>>> ax = subplot(111)
>>> plot_date(dates, values, '-')
>>> labels.ax.get_xticklabels()
>>> setp(labels, rotation=-90)
the problem being that this will only set the property of the first 'n' labels, where 'n' is
the number of tickmarks present when you initially set the property. So if the number of
tick marks increases when zooming in (or out), then the remaining labels above 'n' will not
have the property set. You can see this by running the example script "simple_plot.py" and
rotating the labels (as above) and then zooming in and out until you have more than the
initial number of ticks.
Perhaps a solution would be to set "default" properties for the axis in question, which
would then always set those properties for the tickmarks, unless specifically overridden by
the user as in the above case.
--James Evans
-----Original Message-----
From: John Hunter [mailto:jdh...@ac...] 
Sent: Monday, March 13, 2006 7:54 AM
To: Andrew Straw
Cc: James Evans; mat...@li...
Subject: Re: [matplotlib-devel] AutoDateLocator
>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Committed into svn 2142.
Thanks for the patch James, the auto date functionality is very
nice. Just a minor comment. In the load_converter.py example, the
default ticks overlap each other with the default window size. I
think we are using a format string that is too long for this date
range.
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Committed into svn 2142.
Thanks for the patch James, the auto date functionality is very
nice. Just a minor comment. In the load_converter.py example, the
default ticks overlap each other with the default window size. I
think we are using a format string that is too long for this date
range.
JDH

Andrew,
The easiest way to see this bug is to use the QtAgg backend, then type the following:
>>> import pylab
>>> pylab.figure(figsize=(1, 1))
>>> pylab.show()
and the window you get will most definitly not be using the sizes you set forth.
--James Evans
-----Original Message-----
From: Andrew Straw [mailto:str...@as...] 
Sent: Sunday, March 12, 2006 12:01 PM
To: James Evans; mat...@li...
Subject: Re: [matplotlib-devel] (no subject)
James Evans wrote:
>When using the Qt backend, resize events were not
>getting passed along properly so the window was created
>based off of some other criteria. The attatched patch
>file will fix the problem and make the window be
>resized appropriatly on construction.
>
> 
>
Admittedly I'm no Qt person (this was my opportunity to install Qt on my
system), but I couldn't find any problems with the current
implementation. Could you give a specific, reproducible problem case
that your patch fixes?
Cheers!
Andrew

Tennessee,
Maybe I missed it, but I did not see any reply to your message. We 
welcome simple scripts that expose bugs--and the simpler the better. If 
something more than a simple script is required, then instead of sending 
 a big file to the list, you could put it on an ftp server if you have 
access to one, or send it to one of us off-list upon request.
Tennessee Leeuwenburg wrote:
[...]
> I wrote some code to generate a pair of lists about 300 elements long,
> and plotted them. I found that the line plot didn't have all the data
> points connected.
What backend were you using, and what operating system? What mpl 
version? Was the lack of connectedness at the level of a missing 
pixel, or was a whole line segment missing?
> 
> When I saved to SVG, the output was correct.
So it sounds like it must be a problem with a particular backend.
> 
> Also, when I tried to perform a scatter plot, I got runtime errors and
> no plot was drawn. These problems occur 100% of the time on my machine
> with my test files.
Until a recent change in SVN, scatter required an array, not a list, for 
its colors argument. Could this be the problem in your case?
> 
> I'm not sure if this list accepts files or not, but I am happy to
> provide the code and sample files which demonstrate this error, and/or
> respond to the bugfixing process.
Eric

James Evans wrote:
>When using the Qt backend, resize events were not
>getting passed along properly so the window was created
>based off of some other criteria. The attatched patch
>file will fix the problem and make the window be
>resized appropriatly on construction.
>
> 
>
Admittedly I'm no Qt person (this was my opportunity to install Qt on my
system), but I couldn't find any problems with the current
implementation. Could you give a specific, reproducible problem case
that your patch fixes?
Cheers!
Andrew

James Evans wrote:
>I am uploading a newer patch that is against the SVN
>repository as of "MAR 10, 2006 13:55". This also
>contains a few minor cosmetic fixes/tweaks.
>
> 
>
Committed into svn 2142.
Watch those indents! For some reason, your patch had 3 space indents
(instead of 4) in some places. I also took the liberty of running
lib/matplotlib/dates.py through pylint and fixing some long lines.
Cheers!
Andrew

Andrew Straw wrote:
>After testing this patch, I tried checking it in, but I'm getting an error:
>
>$ svn commit src
>Authentication realm: <https://svn.sourceforge.net:443> SourceForge
>Subversion area
>Password for 'astraw':
>svn: Commit failed (details follow):
>svn: MKACTIVITY of
>'/svnroot/matplotlib/!svn/act/451cc94f-c20e-0410-914b-b8458948145c': 403
>Forbidden (https://svn.sourceforge.net)
>svn: Your commit message was left in a temporary file:
>svn: 
>'/home/astraw/other-peoples-src/matplotlib/matplotlib.svn/svn-commit.2.tmp'
>
>I tried a couple of times to make sure I got the password right, but it
>still didn't go. Does anyone know what's going on? This would have been
>my first commit since we switched to subversion.
> 
>
Weird, SF disables write access by default to the subversion repository:
http://sourceforge.net/tracker/?group_id=1&atid=200001&func=detail&aid=1443846
What's more bizarre is that apparently all the MPL devs aside from me
apparently had no problem committing despite this fact!
Anyhow, I found our permissions page and am in the process of adding
write access to all MPL devs.
https://sourceforge.net/project/admin/userperms.php?group_id=80706
James, your first patch (strict C/C++ conformance) is svn 2141 and I'll
work on your others in short order.