Menu
▾
▴
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
|
From: Jae-Joon L. <lee...@gm...> - 2008-10-31 10:42:13
|
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 <eri...@gm...> 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 <eri...@gm...> 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 <eri...@gm...> 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 <lee...@gm...> 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 <mm...@as...> 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 <mm...@as...> 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 <mm...@as...> 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 >>>>> Mat...@li... >>>>> 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 >>>> Mat...@li... >>>> 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 >> eto...@uc... >> > > > > -- > 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 > eto...@uc... > |
