Eric, I've seen the comment Why is the copy needed? that you've added
to the axes' hist method. I think this was introduced by me some time
ago. Indeed, I think it is not really needed. If I remember correctly, I
had done the copying to avoid that the input x gets modified (I had bad
experience
Olle Engdegård wrote:
Hi,
Combining stepfilled with log scale sometimes gives inappropriate plots:
a=[4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5]
hist(a, range=(0,10), bins=10, histtype=stepfilled, log=True)
The problem is not restricted to the case here with more bins than unique
elements,
Hi,
I just noted a strange behavior of contour(). When a contour plot is
created with negative values and using a single color instead of a cmap,
contour _always_ uses the contour.negative_linestyle, even if linestyles
are specifically provided:
x = linspace(-pi,pi,100)
X,Y = meshgrid(x,x)
I just noted that mathtext and LaTeX rendering behave differently
when using a single $ character in a text string. This happened to me
when looking at the dollar_ticks example from the docs because I use
LaTeX rendering by default. The problem is here:
formatter =
Jae-Joon Lee wrote:
I just committed the change. Although the change is trivial, I didn't
tested it in the numpy 1.2 or the svn version.
Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
since 0.98.5 is released...
-JJ
On Sun, Dec 7, 2008 at 3:24 PM, John Hunter
Manuel Metz wrote:
Jae-Joon Lee wrote:
I just committed the change. Although the change is trivial, I didn't
tested it in the numpy 1.2 or the svn version.
Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
since 0.98.5 is released...
See here: http://projects.scipy.org
, with the
proviso that it uses math- rather than text-rendering for the numbers.
Mike
In that case I suggest to note this somewhere in the docs (and User
Guide) with three exclamation marks (or is it ???).
Manuel
Manuel Metz wrote:
I just noted that mathtext and LaTeX rendering behave differently
when
Manuel Metz wrote:
Manuel Metz wrote:
Jae-Joon Lee wrote:
I just committed the change. Although the change is trivial, I didn't
tested it in the numpy 1.2 or the svn version.
Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
since 0.98.5 is released
Michael Droettboom wrote:
Manuel Metz wrote:
Michael Droettboom wrote:
There was a discussion on this list around a year ago about this. The
concern was that not rendering $ as $ would break (matplotlib) backward
compatibility with scripts that don't care about math at all but use a
lot
Sandro Tosi wrote:
On Mon, Oct 27, 2008 at 15:25, Manuel Metz [EMAIL PROTECTED] wrote:
Just put the Debian bugreport on the list here. I will look at this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
Thanks Manuel, and sorry for not forwarding it and being a little bit
absent
Sandro Tosi wrote:
Hello guys!
A Debian Developers just reported a bug[1] on debian matplotlib during
his preparation to introduce GCC 4.4: matplotlib will fail to build
with GCC 4.4 due to a missing include.
Attached is a patch to fix this problem, forged from an updated trunk;
hope you
Just put the Debian bugreport on the list here. I will look at this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
mm
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the
David Huard wrote:
On Mon, Oct 20, 2008 at 10:19 AM, John Hunter [EMAIL PROTECTED] wrote:
On Mon, Oct 20, 2008 at 9:01 AM, David Huard [EMAIL PROTECTED] wrote:
I would oppose any change to histogram calling convention that does not
fix a critical bug. I agree that using a built-in name as an
John Hunter wrote:
On Sat, Oct 18, 2008 at 8:34 AM, Manuel Metz [EMAIL PROTECTED] wrote:
With a clear checkout building the docs fails:
[...]
Sphinx v0.4.2, building html
trying to load pickled env... not found
building [html]: targets for 348 source files that are out of date
updating
Please see the end of the mail for the important point !!!
Eric Firing wrote:
Manuel,
Although it doesn't hurt, I don't think it is worthwhile changing range
to xrange. From the 2.5 docs:
[...snip...]
Note minimal advantage. xrange was intended for special-case use, not
general use.
With a clear checkout building the docs fails:
[...]
Sphinx v0.4.2, building html
trying to load pickled env... not found
building [html]: targets for 348 source files that are out of date
updating environment: 348 added, 0 changed, 0 removed
reading... api/afm_api api/artist_api Exception
, 2008 at 8:43 PM, Manuel Metz [EMAIL PROTECTED] wrote:
Manuel Metz wrote:
Jae-Joon Lee wrote:
Hi Manuel,
I think it is a good to introduce the update_from method in Collections.
But, I'm not sure if it is a good idea to also update sizes, paths and
rotation (in RegularPolyCoolection). My
, Manuel Metz [EMAIL PROTECTED] wrote:
hmm
Original Message
Jae-Joon Lee wrote:
- the parameter numpoints should be used (it's ignored right now)
Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
- Some private variables are accessed and a new
Manuel Metz wrote:
Jae-Joon Lee wrote:
Hi Manuel,
I think it is a good to introduce the update_from method in Collections.
But, I'm not sure if it is a good idea to also update sizes, paths and
rotation (in RegularPolyCoolection). My impression is that update_from
method is to update gc
I found a few typos in artists.rst. Added a patch (don't want to commit
it, because I'm not actively working on the docs)
The first sentence of the section Object containers also needs to be
fixed (or I don't understand it):
Now that we know how to inspect set the properties of a given object
Jae-Joon Lee wrote:
- the parameter numpoints should be used (it's ignored right now)
Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
- Some private variables are accessed and a new RegularPolycollection is
created (does this work eg. with a
with the patch and
haven't commit anything yet)
mm
--
---
Manuel Metz [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: [EMAIL PROTECTED]
Web:www.astro.uni-bonn.de/~mmetz
Jae-Joon Lee wrote:
- the parameter numpoints should be used (it's ignored right now)
Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
- Some private variables are accessed and a new RegularPolycollection is
created (does this work eg. with a
John Hunter wrote:
On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud [EMAIL PROTECTED] wrote:
Ah, that makes more sense Jae-Joon - thanks!
Jae-Joon -- could you handle this patch submission?
Thanks,
JDH
Hi,
I also had a look at this patch -- as that's a feature I was
interested in, too.
Hi Mike,
I just stumbled over this bug report (#2126188) on sourceforge. This
seems to appear in version 5471, committed by you.
Manuel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Hi all,
I think I have finally found a nice way to implement step-plots with
different linestyles. The way this is done required some re-writing of
lines.py, but I think it is done in a consistent manner:
A new property *drawstyle* is introduced. By default this just
connects the datapoints
Hi,
I think there is bug in get_xticklabels(). According to the doc it
should return a list of Text instances, instead it returns a list of
TextWithDash instances. This also makes the following impossible (which
should work of course):
xtl = ax.get_xticklabels()
Hi all,
I ran into a problem where I wanted to plot a step-plot with dashed
lines instead of solid lines which can be important for print media.
This isn't possible with the current matplotlib version, so I added
support for this. The patch is attached, but I didn't commit it yet
since I
Manuel Metz wrote:
Hi all,
I ran into a problem where I wanted to plot a step-plot with dashed
lines instead of solid lines which can be important for print media.
This isn't possible with the current matplotlib version, so I added
support for this. The patch is attached, but I didn't
Hi,
I just committed a patch that allows for multiple histogram where each
data-set might have a different length (see example
histogram_demo_extended.py). I don't think that it breaks any existing
code, but I would feel much better if someone could check that ...
Manuel
Hi,
I think the section Controlling axes properties of
http://matplotlib.sourceforge.net/tutorial.html needs to be updated, since
frame = gca(gca(), 'frame')
setp(frame, 'linewidth', 2)
doesn't work any more with mpl 0.98.x ...
Manuel
[ 2008303 ] AttributeError: Unknown property histtype
I think this bug can be closed.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK
John Hunter wrote:
On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan [EMAIL PROTECTED] wrote:
Thanks for the submission -- I await more informed commentary from
those who actually use contouring
Just because the discussion about clabel started, I want to post a short
snipplet of code
Paul Kienzle wrote:
On Thu, Jul 17, 2008 at 08:50:03AM +0200, Manuel Metz wrote:
Just because the discussion about clabel started, I want to post a short
snipplet of code that I found useful. It was some sort of hack to get a
nicer float formating for contours: contour lines represented
Andrew Hawryluk wrote:
Hopefully this isn't old news for you. Since the 0.98 release, the histogram
plot doesn't work properly with 2D arrays: it is quite slow and the output is
wrong. Passing a flattened array produces the quick, correct output that we
are accustomed to. Here is the test
Hi,
just want to point to a bug (2002836) reported on sourceforge.
I could track this a little bit more down and found that a subscript
like r'x_{\leftarrow}' fails, whereas r'x_\leftarrow' works (!); also
fails e.g. for r'x_{\leftrightarrow}'. Anything that starts with \right
or \Left
Olle Engdegård wrote:
hist(histtype=step) worked fine in rev5412, but in the latest I get
hist(randn(1000), histtype=step)
Traceback (most recent call last):
/.../
raise TypeError, 'There is no patch property %s'%key
TypeError: There is no patch property closed
Changing
closed =
John Hunter wrote:
On Thu, Jun 12, 2008 at 8:56 PM, T J [EMAIL PROTECTED] wrote:
I am making a scatter plot and want the legend to display the symbols.
This functionality doesn't seem to exist, so I have followed the
workaround outlined here:
When looking, e.g. at axes.py, I see 3 different arguments passed to
numpy astype()/array()/zero() and friends:
x = np.asarray(x).astype(np.float32)
x = np.zeros( x, np.float_ )
x = np.ones((col,), float)
Is there a preferred one to stick to ?!
Manuel
Michael Droettboom wrote:
Thanks. I have fixed 1), and added a closed kwarg to fill() and
Polygon.__init__() (which defaults to True to mimic behavior of 0.91 and
earlier). hist() has been updated to call fill() with closed=False.
Cheers,
Mike
Great - thanks. So, I committed a patch
Olle Engdegård wrote:
Hi,
Some more thoughts about hist():
A range parameter should be added and used in histogram()
Hi Olle,
what do you mean by range parameter. What should this parameter
actually do ?
I just committed a patch to the trunk that adds the features as you
and also
Erik Tollerud wrote:
While going through and updating some scripts to use the new features
that were recently added to hist(), I found myself very confused by
the align keywords - I had to go and look at Manuel Metz's post a
couple weeks ago to believe it wasn't a typo in the documentation...
Dear all,
as there was no disagreeing feedback ;-) I continued my work on the
hist() method. I just committed a patch with some major re-writing of
the hist() method to the trunk. I personally think it is very useful.
hist() now
- supports 2D input data (i.e. multiple data, but not yet
Hi,
I had one or two more looks at the hist() function. There are a few
things I wondered about:
(I) Isn't it more intuitive to interpret the width keyword as width
relative to the real width of a bin rather than as an absolute value ?
Here is an example, why I think so: Say I want to
,
Johann
Manuel Metz wrote:
Eric Firing wrote:
John Hunter wrote:
On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud [EMAIL PROTECTED] wrote:
are slightly different). There's a slight compatibility issue in that
as it stands in that the returned tuple now has 4 values (I
Erik Tollerud wrote:
It'd be nice to get this into the new release unless it has been
somehow fixed by some other code path in the latest svn... the line
numbers on the diff are no longer accurate, but the idea is still the
same - just change all lines of the form
caplines.extend(
Hi,
while adding the step-histogram I learned about the change of
numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
idea to switch to the new histogram, i.e. use new=True. Indeed, this
is required to be able to allow to give bin-edges, which is possible
with MPL 0.91.
Here's the link to the numpy wiki:
http://projects.scipy.org/scipy/numpy/roadmap#Semanticchangeforhistogram
Manuel Metz wrote:
Hi,
while adding the step-histogram I learned about the change of
numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
idea to switch
Erik Tollerud wrote:
No one thinks this is worth committing to SVN? I find myself using it
quite a bit in my own work - different fields have different ideas
about the right way to draw a histogram, so it's good to have
options, I think...
On Wed, Apr 2, 2008 at 4:39 PM, Erik Tollerud
Eric Firing wrote:
John Hunter wrote:
On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud [EMAIL PROTECTED] wrote:
are slightly different). There's a slight compatibility issue in that
as it stands in that the returned tuple now has 4 values (I added a
list of the lines that are generated if
Hi,
I have fixed the double-zoom Bug in the trunk (revision 5053), but
not in the 0_91maint branch. In 0.91 it's not so easy to find out
whether an axes is shared with another (cbook:Group is nice ;-) ) For
0.91: is it always guaranteed that the release_zoom event for the master
is called
John Hunter wrote:
On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz [EMAIL PROTECTED] wrote:
Hi,
in matplotlib 0.91 there was a function draw_point for the backends.
This seems to be gone (except for backend_agg2.py and backend_emf.py
!?). I guess it wasn't used very often; instead I see
Hello,
I have attached a patch that addresses the following:
plot accepts the linestyles arguments '-','--','-.',':' [+ some more]
and the Collection class accepts the
linestyle arguments 'solid','dashed','dashdot','dotted'.
This patch allows to use both notations. A test script is
Paul Novak wrote:
A few weeks ago there was a discussion about putting scatter symbols in
the legend (see
http://www.nabble.com/Show-shapes-on-scatterplot-legend--to15744380.html).
I would like to implement scatter symbols in the legend, but I am having
some problems doing so. In the
Happend with your commit from version 4979 - 4989. Who's going to fix
that ? Whom can I directly contact ?
Original Message
Subject: [matplotlib-devel] axes.py scatter doc-bug
Date: Wed, 12 Mar 2008 12:30:12 +0100
From: Manuel Metz [EMAIL PROTECTED]
To: matplotlib-devel
Hi,
the doc-string of the axes scatter method is buggy. Somehow the
svn-conflict messages got committed to the repository:
I mean this
.working
[...]
===
[...]
.merge-right.r4987
... stuff)
Manuel
-
This SF.net
Erik Tollerud wrote:
I use the scatter(x,y) command to make scatter plots, but I noticed
today (on the SVN version of mpl) that when I call legend() after
giving scatter(x,y,label='somelabel') , the legend doesn't show the
marker symbols - it only has a square patch colored in the color that
Hi,
might I ask again whether anyone can attend to update the doc-string of
the scatter function ?
Manuel
Manuel Metz wrote:
There was a question on the matplotlib-users list about symbols in
[snip]
Btw: shouldn't the
verts keyword be removed, since marker=(verts,0) is equivalent
There was a question on the matplotlib-users list about symbols in
scatter, that made me realize that the new marker = (5,0) ... syntax,
that I contributed some time ago, were not documented. So I tried to
write a doc string.
Can anyone please check this and add the patch? Btw: shouldn't the
Hi all,
I find the usage of linestyle very _unconvenient_, since there are these
two options - linestyle='--' and linestyle='dashed' - which are not
exchangable.
I had some code where I initially used the Line2D class, so I had to use
linestyle='--'. Now I changed my code to use a
Hi,
I figured out a bug in the FancyArrow class (sorry, I didn't track it
down, yet). Might be related to my strange axes limits ?
Please have a look at the attached example. As you can see, in the lower
panel the head is not rendered correctly.
I used the lates svn, revision 4730.
Manuel
Michael Droettboom wrote:
Manuel Metz wrote:
Hi,
I figured out a bug in the FancyArrow class (sorry, I didn't track it
down, yet). Might be related to my strange axes limits ?
Please have a look at the attached example. As you can see, in the
lower panel the head is not rendered correctly
Darren Dale wrote:
On Friday 19 October 2007 10:20:43 am John Hunter wrote:
On 10/19/07, Darren Dale [EMAIL PROTECTED] wrote:
I don't remember how to find the answer. It looks like scatter() creates
polygons, while plot() uses draw_markers:
I see -- scatter uses collections, and the defaut
it will
support anything but float (especially not the unit types).
Eric
Ted
At 07:59 AM 8/14/2007, Manuel Metz wrote:
Hi,
I have created a patch against latest svn that adds a function step
to the axes class to plot step-functions ;-) It's really simple but
nice ... Any interest in adding
--
---
Manuel Metz [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: [EMAIL PROTECTED]
Web:www.astro.uni-bonn.de/~mmetz
Phone: (+49) 228 / 73-3660
Fax:(+49) 228 / 73
, matplotlib and inkscape.
matplotlib has no need to put the definitions inside the group and can
simply avoid that, but still inkscape should cope with this kind of
(legal!) SVG code in a better way.
Manuel Metz wrote:
Hi,
I have a problem with the svg output of matplotlib. I created
--
---
Manuel Metz [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: [EMAIL PROTECTED]
Web:www.astro.uni-bonn.de/~mmetz
Phone: (+49) 228 / 73-3660
Fax:(+49) 228 / 73-3672
Hi,
I'm not quite sure, but I think there is a bug in backend_agg.py in the
function draw_point(). I got an error when trying to use this function,
and the attached patch fixed the problem. As you can see, it seems that
there is just a parameter (rotation) missing.
Manuel
Index: backend_agg.py
reads:
if marker is None and not (verts is None):
^^
I've attached a patch... I apologize again ...
Manuel
Manuel Metz wrote:
John Hunter wrote:
Manuel == Manuel Metz [EMAIL PROTECTED] writes:
Manuel There is a subtle but essential difference ;-) : for i
John Hunter wrote:
Manuel == Manuel Metz [EMAIL PROTECTED] writes:
Manuel Argh - okay - this is a mistranslation from german to
Manuel english - sorry. I wanted to say starlike. So probably
Manuel StarlikeRegularPolygon is a better name...
OK, I see. Perhaps we should just
John Hunter wrote:
Manuel == Manuel Metz [EMAIL PROTECTED] writes:
Manuel There is a subtle but essential difference ;-) : for i in
Manuel xrange(1,len(r), 2 ) ^^^ , i.e. every second value gets
Manuel rescaled. But there is probably a more pythonic way to
Manuel do
John Hunter wrote:
Manuel == Manuel Metz [EMAIL PROTECTED] writes:
Manuel Hi, I just submitted a patch to sourceforge and also
Manuel attached it to this email:
Manuel The applied patch modifies the files axes.py and
Manuel collections.py.
Manuel I added a class
Hi,
first of all scatter_custom_symbol.py is great ! I really like this.
But...
May I express some idea/suggestions concerning custom symbols:
I came from supermongo to matplotlib. And I liked the way you could
define symbols in supermongo:
PTYPE n s
where s gives the style of the symbol:
s
73 matches
Mail list logo
