hmm
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
scatleg.patch (3.01 KB)
···
-------- Original Message --------
--
---------------------------------------
Manuel Metz ............ Stw@...468...
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: mmetz@...459...
Web: www.astro.uni-bonn.de/~mmetz
Phone: (+49) 228 / 73-3660
Fax: (+49) 228 / 73-3672
---------------------------------------
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.
Also, is it okay to update properties without checking its length?. It
does not seem to cause any problems though.
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 <mmetz@...459...> 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
--
---------------------------------------
Manuel Metz ............ Stw@...468...
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: mmetz@...459...
Web: www.astro.uni-bonn.de/~mmetz
Phone: (+49) 228 / 73-3660
Fax: (+49) 228 / 73-3672
---------------------------------------
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
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 <mmetz@...459...> 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
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
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
hmm
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
scatleg.patch (3.31 KB)
···
On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mmetz@...459...> wrote:
-------- Original Message --------
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:
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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
--
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
etolleru@...244...
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.
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.
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
scatleg_jj.diff (6.12 KB)
···
On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
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.
Hope this helps,
JDH
···
On Thu, Oct 16, 2008 at 9:57 PM, Jae-Joon Lee <lee.j.joon@...149...> 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.
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
scatleg_mm.patch (5.95 KB)
···
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 <mmetz@...459...> 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 <mmetz@...459...> 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
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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
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.j.joon@...149...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
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).
scatleg_et_2.diff (8.76 KB)
···
On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud <erik.tollerud@...149...> 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.j.joon@...149...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
--
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
etolleru@...244...
No more thoughts on this? Or was some version of the patch committed?
···
On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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.j.joon@...149...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
--
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
etolleru@...244...
--
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
etolleru@...244...
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 <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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.j.joon@...149...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
--
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
etolleru@...244...
--
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
etolleru@...244...
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...
scatterpoints_et.diff (4.16 KB)
···
On Fri, Oct 31, 2008 at 2:42 AM, Jae-Joon Lee <lee.j.joon@...149...> 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 <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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.j.joon@...149...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
etolleru@...244...
--
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
etolleru@...244...
--
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
etolleru@...244...
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 <erik.tollerud@...149...> 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 <lee.j.joon@...149...> 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 <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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 <erik.tollerud@...149...> 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.j.joon@...149...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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 <mmetz@...459...> 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
matplotlib-devel List Signup and Options
-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
--
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
etolleru@...244...
--
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
etolleru@...244...
--
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
etolleru@...244...