I'm so sorry Erik. I missed your last email. I just submitted your patch with a slight modification. As far as I know, matplotlib still supports python 2.4, and Conditional Expressions are introduced in 2.5.
Regards, -JJ On Tue, Nov 11, 2008 at 9:22 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: > Patch against today's svn is attached. Sorry for the long delay... > > Right now, "scatterpoints" is just set to 3 in Legend.__init__, but > presumably that should be an rcParam... > > On Fri, Oct 31, 2008 at 2:42 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: >> Sorry Erik. >> Can you 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 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, 2 points >>>> for plotted values, and 3 points for scatter plots on the same legend >>>> (you have to give a numpoints=# command that's shared by everything in >>>> the legend, if I'm understanding it). It'd be nice to have a >>>> property, say, "scatterpoints" (and presumably then an associated >>>> rcParam "legend.scatterpoints" ) that sets the number of points to use >>>> for scatter plots. That way, I can make plots just like in the >>>> original form, but 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, Oct 20, 2008 at 3:22 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote: >>>>> 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 permitting... >>>>> >>>>> On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: >>>>>>> To help clarify the original purpose of "update_from": I wrote this >>>>>>> method when writing the original legend implementation so the legend >>>>>>> proxy objects could easily copy their style attributes from the >>>>>>> underlying objects they were a proxy for (so not every property is >>>>>>> copied, eg the xdata for line objects is not copied). So the >>>>>>> operating question should be: what properties do I need to copy to >>>>>>> make the legend representation of the object. While you are in >>>>>>> there, perhaps you could clarify this in the docstrings of the >>>>>>> update_from method. >>>>>> >>>>>> Thanks for clarifying this, John. >>>>>> >>>>>> Manuel, >>>>>> The patch looks good to me. We may submit the patch (I hope Erik is >>>>>> okay with the current patch) and it would be great if you handle the >>>>>> submission. >>>>>> >>>>>> -JJ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <[EMAIL PROTECTED]> wrote: >>>>>>> Jae-Joon Lee wrote: >>>>>>>> Thanks Manuel. >>>>>>>> >>>>>>>> Yes, we need rotation value and etc, but my point is, do we need to >>>>>>>> update it within the update_from() method? Although my preference is >>>>>>>> not to do it, it may not matter much as far as we state what this >>>>>>>> method does clearly in the doc. >>>>>>> >>>>>>> Okay, it's probably better to create the object correctly (numsides ...) >>>>>>> instead of copying the properties (see also JDHs mail !) >>>>>>> >>>>>>>> And, in your patch, I don't think updating the numsides value has any >>>>>>>> effect as it does not recreate the paths. >>>>>>>> >>>>>>>> I'm attaching the revised patch. In this patch, update_from() only >>>>>>>> update gc-related properties. And numsides, size, and rotations are >>>>>>>> given during the object creation time. >>>>>>> >>>>>>> Yes, this looks better. But creating handle_sizes is a little bit too >>>>>>> much effort. This is done internally. It will do passing a sizes list, >>>>>>> that may or may not be shorter/longer than numpoints (see revised >>>>>>> patch). >>>>>>> >>>>>>> I also changed the way the yoffsets are updated in _update_positions(). >>>>>>> >>>>>>> One additional thing I have in mind (for a later time) is a "sizesbar" >>>>>>> similar to a colorbar where you can read off values corresponding to >>>>>>> marker sizes... >>>>>>> >>>>>>> Cheers, >>>>>>> Manuel >>>>>>> >>>>>>>> Erik, >>>>>>>> I see your points. My main concern is that the yoffsets makes the >>>>>>>> results a bit funny when numpoints is 2. The attached patch has a >>>>>>>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only >>>>>>>> introduced when numpints > 2 and you can also provide it as an >>>>>>>> optional argument. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -JJ >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 16, 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 impression is that >>>>>>>>>>> update_from >>>>>>>>>>> method is to update gc related attributes. For comparison, >>>>>>>>>>> Patch.update_from() does not update the path. >>>>>>>>>> That's exactly the point why I wasn't fully happy with the patch. The >>>>>>>>>> path is generated by the _path_generator, so instead of copying the >>>>>>>>>> path >>>>>>>>>> it seems to be better to create an instance of the corresponding >>>>>>>>>> class >>>>>>>>>> (e.g. the StarPolygonCollection class, as suggested before). >>>>>>>>>> >>>>>>>>>> One should update the rotation attribute (!!); it's only one >>>>>>>>>> number. A >>>>>>>>>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has >>>>>>>>>> rotation=pi/4. That's the only difference between those two ! >>>>>>>>>> >>>>>>>>>>> Also, is it okay to update properties without checking its length?. >>>>>>>>>>> It >>>>>>>>>>> does not seem to cause any problems though. >>>>>>>>>> It's in principal not a problem to copy the sizes attribute without >>>>>>>>>> checking the length. If it's shorter the the number of items the >>>>>>>>>> sizes >>>>>>>>>> are repeated; if it's longer it gets truncated. >>>>>>>>>> >>>>>>>>>> mm >>>>>>>>>> >>>>>>>>>>> I guess It would better to use xdata_markers than xdata in the >>>>>>>>>>> get_handle() method. The difference is when numpoints==1. Using >>>>>>>>>>> xdata >>>>>>>>>>> gives two marker points. >>>>>>>>>>> >>>>>>>>>>> I was actually about to to commit my patch. I'll try to account your >>>>>>>>>>> changes and post my version of patch later today. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> -JJ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 15, 2008 at 4:07 PM, 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 >>>>>>>>>>>>>> RegularPolycollection is >>>>>>>>>>>>>> created (does this work eg. with a StarPolygonCollection? I >>>>>>>>>>>>>> haven't >>>>>>>>>>>>>> checked, but I don't think so !). Instead of creating a new >>>>>>>>>>>>>> RegularPolyCollection it might be more useful to make a copy of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> existing object... I was thinking about a update_from() method >>>>>>>>>>>>>> for the >>>>>>>>>>>>>> Collection class(es) similar to update_from() for lines. >>>>>>>>>>>>>> >>>>>>>>>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works >>>>>>>>>>>>> for >>>>>>>>>>>>> StarPolygonCollection. >>>>>>>>>>>>> >>>>>>>>>>>>> In Erik's current implementation, the markers in the legend have >>>>>>>>>>>>> varying colors, sizes, and y offsets. >>>>>>>>>>>>> The color variation seems fine. But do we need to vary the sizes >>>>>>>>>>>>> and >>>>>>>>>>>>> y-offsets? My inclination is to use a fixed size (median?) and a >>>>>>>>>>>>> fixed >>>>>>>>>>>>> y offset. How does Erik and others think? >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> -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 with the patch and >>>>>>>>>>>> haven't commit anything yet) >>>>>>>>>>>> >>>>>>>>>>>> mm >>>>>>>>>>>> >>>>>>>>> Hi Jae-Joon, >>>>>>>>> so here is my revised version of the patch. What do you think ? >>>>>>>>> >>>>>>>>> Manuel >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>>>> challenge >>>>>>> Build the coolest Linux based applications with Moblin SDK & win great >>>>>>> prizes >>>>>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>>>>> world >>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>>> _______________________________________________ >>>>>>> Matplotlib-devel mailing list >>>>>>> Matplotlib-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>>> challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win great >>>>>> prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>>>> world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Matplotlib-devel mailing list >>>>>> Matplotlib-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Erik Tollerud >>>> Graduate Student >>>> Center For Cosmology >>>> Department of Physics and Astronomy >>>> 2142 Frederick Reines Hall >>>> University of California, Irvine >>>> Office Phone: (949)824-2587 >>>> Cell: (651)307-9409 >>>> [EMAIL PROTECTED] >>>> >>> >>> >>> >>> -- >>> Erik Tollerud >>> Graduate Student >>> Center For Cosmology >>> Department of Physics and Astronomy >>> 2142 Frederick Reines Hall >>> University of California, Irvine >>> Office Phone: (949)824-2587 >>> Cell: (651)307-9409 >>> [EMAIL PROTECTED] >>> >> > > > > -- > Erik Tollerud > Graduate Student > Center For Cosmology > Department of Physics and Astronomy > 2142 Frederick Reines Hall > University of California, Irvine > Office Phone: (949)824-2587 > Cell: (651)307-9409 > [EMAIL PROTECTED] > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
