I see most of your points and the current version is definitely better
in many respects... I had originally tried to update the collections
rather than make new ones, but didn't understand enough of the
internals to implement the update_from method.
But regarding the size variation... I think the size variation is
important because, in my view, the purpose of the legend for a scatter
plot is to as accurately as possible reflect the data represented. I
have certainly seen plots where there are two sets of symbols, one of
which ranges over a bunch of sizes, and others that are uniform. If
they appear almost the same on the legend, it takes much more time to
figure out which is which, especially in cases where most of the
symbols are small (so that the shape and color are somewhat harder to
see). The eye is very good at picking out gross features in size
variation, and I think that's important. I'm not totally stuck on it
(I was somewhat dissatisfied in the initial implementation in that if
you have very big or very small symbols, the legend is difficult to
read... I meant to implement some smarter scaling of the legend but
wanted to see what other people thought before doing that work).
As for the y-offsets... The main justification there is to distinguish
scatter plots from line plots that just aren't joining the points
together. I personally have made plots where one set of data is best
represented as data points with a trend, but it also makes sense to
overlay a scatter plot of data on top of it. In that case, seeing
data that appear "scattered" in the legend helps clarify the
distinction between the two sets of data.
So while I like most of the changes, I still think the y offsets and
size variation should at least be an option (and I personally would
want them on by default), although I am much more attached to the
y-offsets than the size issue. Your thoughts?
On Thu, Oct 16, 2008 at 4:43 AM, Manuel Metz <mmetz@...459...> wrote:
Manuel Metz wrote:
Jae-Joon Lee wrote:
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.
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.
On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mmetz@...459...> wrote:
-------- 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
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?
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)
so here is my revised version of the patch. What do you think ?
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
Matplotlib-devel mailing list
Center For Cosmology
Department of Physics and Astronomy
2142 Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2587