Sorry for the dealyed reply - I've been out of town... I posted to the
patch tracker, and am dutifully pinging :)
On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>>
ue, Sep 23, 2008 at 11:41 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>> Attached is a diff against revision 6115 that contains a patch to
>> improve the behavior of the legend function when showing le
handle.set_offsets(zip(xvals, yvals))
>
> # Set the data for the legend patch
> bbox = self._get_handle_text_bbox(renderer)
>
>
>
> On Tue, Oct 7, 2008 at 12:15 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>> Does anyone have anything n
t;>>>
>>>>> -JJ
>>>> Attached is my current version of the patch. I've moved all of the
>>>> properties-copying stuff to collections, which makes the changes
>>>> legend.py more clearer (but I'm not fully happy
The current patch looks good to me... it satisfies all the use cases I
had in mind, and I can't think of much else that would be wanted.
Thanks!
I also very much like the idea of the "sizebar," although that's
probably a substantially larger job to implement. I may look into it
though, time permit
ut it can also be the same number for both if so
desired. I've attached a patch based on the last one that does this,
although it probably needs to be changed to allow for an rcParam
'legend.scatterplot' (I don't really know the procedure for adding a
new rcParam).
On Mon,
No more thoughts on this? Or was some version of the patch committed?
On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
> Actually, looking more closely, there is one thing that's still
> bothering me: as it is now, it's impossible to have, say,
ou make a new patch against the current SVN?
> Some of the patch was applied (but without scatterpoints option) in the SVN.
> Thanks,
>
> -JJ
>
>
>
>
> On Thu, Oct 30, 2008 at 1:58 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>> No more thoughts on this? Or w
Personally, I think traits must be kept out of MPL, for three main reasons:
1. As Eric Bruning points out, while traits is a very powerful tool,
it also closes a lot of doors by forcing everything to be written in a
trait-like fashion for it to play nice with everything else. While
this is great
I was looking through this, and have a suggestion as well:
You have a line that reads
In[10]: plt.hist(lum_img)
This should probably be
plt.hist(lum_img.ravel(),bins=)
As it is right now, you are making a histogram of each line
individually, and my experience has been that this tends to cause
is
In mpl_toolkits.mplot3d, I noticed that if I want to add text in the
Axes3D, I need to use Axes3D.text3D . However, that method doesn't
pass in kwargs to set the text properties onto the Axes.text method.
Hence, I made this simple modification that passes kwargs on text3D on
to text so that the pr
I noticed some odd behavior in the legend and managed to track down
the source of the problem and make a fix (a diff against the current
svn is attached). Specifically, two things were fixed:
*The "markerscale" argument for the legend seems to do nothing... The
attached diff properly applies the
gt;>> Thanks for reporting these.
>>> I took a look at your patch and slight revised it (see the attached).
>>> While I believe that my patch is compatible to yours, it'll be great
>>> if you check my patch to see if I missed anything.
>>> I'll c
. That fix
is attached as a diff against the current svn in mpl3d-ticks-fix.diff
. Now setting ticks seems to work just fine, so I've included another
diff that additionally implements set_?ticks3d and get_?ticks3d
methods for Axes3D - that's attached as
mpl3d-ticks-fix-add-methods.diff .
I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::
import matplotlib
matplotlib.interactive(True)
matplotli
Just a quick ping about this - did it get applied, or was there
something wrong with it? (Or am I just too impatient?)
On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud wrote:
> I noticed some odd behavior when trying to set ticks on 3d plots made
> using mplot3d.Axes3D ... specifically,
say it's a
> great addition. I'll test tomorrow and push it if it works (which I
> assume it does).
>
> Cheers,
> Reinier
>
> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud
> wrote:
>> Just a quick ping about this - did it get applied, or was there
>> somethi
-
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> ___
> Matplotlib-deve
I just realized the patch I sent before includes some other changes...
the attached version should only be the fix for this particular bug.
On Mon, Aug 23, 2010 at 7:23 PM, Erik Tollerud wrote:
> This is definitely a bug, but I thought I'd clarify and add in a little
> more
Did this fix ever get applied? I was looking at some other svn
changes and it still says none of this part of legend.py has been
altered...
On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee wrote:
> On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud wrote:
>> Jae-Joon, your patch lo
Sorry for the re-ping if it was taken care of in some way I didn't
undertand, but this doesn't seem to have been changed on the trunk
svn... should it have been, or is there some other branch that this
stuff is being worked on?
On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud wrote:
&g
Whoops, yes, that should be True... Also realized a slight error in
the description of how the mimum is set - both of those are fixed in
the attached diff.
On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing wrote:
> On 08/24/2010 08:39 AM, Erik Tollerud wrote:
>> I just realized the pat
2010 at 9:04 PM, Benjamin Root wrote:
>> On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud
>> wrote:
>>>
>>> Sorry for the re-ping if it was taken care of in some way I didn't
>>> undertand, but this doesn't seem to have been changed on the t
n 08/25/2010 04:50 AM, Benjamin Root wrote:
>>
>> On Wed, Aug 25, 2010 at 12:00 AM, Anne Archibald
>> mailto:aarch...@physics.mcgill.ca>> wrote:
>>
>> On 24 August 2010 22:22, Benjamin Root > <mailto:ben.r...@ou.edu>> wrote:
>> > On Tue, Aug 24
I noticed while making some plots with upper bound error bars that
whenever Axes.errorbars is called with any of the errorbars chosen as
upper or lower bounds, that the color cycle was off, skipping over 2
colors each time another errorbar plot was made (e.g. the first would
be green and the second
I've been working on an application that uses matplotlib as its
plotting library, and I've been noticing a steady decrease in
performance over time. I figured out the cause as coming from the
matplotlib SpanSelector widget - I had to create a new widget every
time the axes were cleared, as the Spa
meone must have renamed some variables and
didn't go and change them further up or something. Changing the
variable name in a couple places seems to make it all work on my
setup. The diff is attached.
On Feb 12, 2008 6:11 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 7:0
After a little testing on the subversion repository, the attached diff
seems to work.
On Feb 10, 2008 12:12 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
> I noticed while making some plots with upper bound error bars that
> whenever Axes.errorbars is called with any of the errorba
iny)
self.to_draw.set_width(maxx-minx) # set width and height of box
self.to_draw.set_height(maxy-miny)
self.update()
On Feb 11, 2008 7:48 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Feb 10, 2008 5:12 PM, Erik Tollerud <[EMAIL PROTECTED]&g
;s the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.
ershoots the rest of the
outline by a very tiny bit... if anyone knows how to cut off the upper
row of pixels to make it flush with the rest of the outline... it's
perfectly usable as-is, though - that's just a tiny little aesthetic
quibble)
--
Erik Tollerud
Graduate Student
Center For C
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 <[EMAIL
I don't see why anything would have changed...
On Tue, Feb 12, 2008 at 10:46 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
> After a little testing on the subversion repository, the attached diff
> seems to work.
>
> On Feb 10, 2008 12:12 AM, Erik Tollerud <[EMAIL PROTE
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...
"center" and "edge" are ex
vices for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Erik Tollerud
Graduate Stu
35 matches
Mail list logo
