matplotlib-devel Mailing List for matplotlib

On Wednesday 15 October 2008 04:59:28 pm John Hunter wrote:
> I just took the plunge and pushed the beta website live. We are now
> purely driven off the sphinx living in the doc dir.
It looks great, really nice work guys. Sorry I havent been able to keep up 
with the list recently, unfortunately its unlikely to change for a while.
I noticed that the PDF download link at 
http://matplotlib.sourceforge.net/contents.html is broken.
Darren

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 <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
>
>
-- 
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...

Manuel,
Although it doesn't hurt, I don't think it is worthwhile changing range 
to xrange. From the 2.5 docs:
xrange( [start,] stop[, step])
 This function is very similar to range(), but returns an ``xrange 
object'' instead of a list. This is an opaque sequence type which yields 
the same values as the corresponding list, without actually storing them 
all simultaneously. The advantage of xrange() over range() is minimal 
(since xrange() still has to create the values when asked for them) 
except when a very large range is used on a memory-starved machine or 
when all of the range's elements are never used (such as when the loop 
is usually terminated with break).
Note "minimal" advantage. xrange was intended for special-case use, not 
general use.
And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
xrange() renamed to range(), so range() will no longer produce a list 
but an iterable yielding integers when iterated over.
This implies to me that range is the preferred form, and xrange is 
intended to go away.
Eric
mme...@us... wrote:
> Revision: 6217
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6217&view=rev
> Author: mmetz_bn
> Date: 2008年10月16日 11:15:25 +0000 (2008年10月16日)
> 
> Log Message:
> -----------
> minor optimizations: replacing range by xrange in for loops
> 
> Modified Paths:
> --------------
> trunk/matplotlib/lib/matplotlib/axes.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/axes.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/axes.py	2008年10月15日 20:53:09 UTC (rev 6216)
> +++ trunk/matplotlib/lib/matplotlib/axes.py	2008年10月16日 11:15:25 UTC (rev 6217)
> @@ -243,7 +243,7 @@
> x, y, multicol = self._xy_from_y(y)
> 
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> color = self._get_next_cycle_color()
> seg = mlines.Line2D(x, y[:,j],
> color = color,
> @@ -285,7 +285,7 @@
> ret.append(seg)
> 
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> makeline(x[:,j], y[:,j])
> else:
> makeline(x, y)
> @@ -324,7 +324,7 @@
> closed = kwargs.get('closed', True)
> func = makefill
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> func(x[:,j], y[:,j])
> else:
> func(x, y)
> @@ -372,7 +372,7 @@
> func = makefill
> 
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> func(x[:,j], y[:,j])
> else:
> func(x, y)
> @@ -3897,9 +3897,9 @@
> pass
> elif align == 'center':
> if orientation == 'vertical':
> - left = [left[i] - width[i]/2. for i in range(len(left))]
> + left = [left[i] - width[i]/2. for i in xrange(len(left))]
> elif orientation == 'horizontal':
> - bottom = [bottom[i] - height[i]/2. for i in range(len(bottom))]
> + bottom = [bottom[i] - height[i]/2. for i in xrange(len(bottom))]
> 
> else:
> raise ValueError, 'invalid alignment: %s' % align
> @@ -4571,7 +4571,7 @@
> elif nc == 1:
> x = [x.ravel()]
> else:
> - x = [x[:,i] for i in range(nc)]
> + x = [x[:,i] for i in xrange(nc)]
> else:
> raise ValueError, "input x can have no more than 2 dimensions"
> if not hasattr(x[0], '__len__'):
> @@ -4665,7 +4665,7 @@
> else:
> def doplot(*args):
> shuffled = []
> - for i in range(0, len(args), 3):
> + for i in xrange(0, len(args), 3):
> shuffled.extend([args[i+1], args[i], args[i+2]])
> return self.plot(*shuffled)
> 
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> 
> -------------------------------------------------------------------------
> 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-checkins mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

On Oct 13, 2008, at 4:59 PM, Anne Archibald wrote:
> but I have written a simple line
> integral convolution operator I'd be happy to contribute.
Anne-
I would be interested in seeing the code, regardless of where it finds 
a home.
Would you mind sharing, or would you rather wait?
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

> Eric Firing wrote:
>
> Andrew Hawryluk wrote:
>> The interpolation algorithm used in imshow() can produce spurious 
>> results, as has been noted before:
>> 
>> _http://article.gmane.org/gmane.comp.python.matplotlib.general/12062_
>> 
>> This happens because the data is converted to RGB before the 
>> interpolation/resampling, rather than after. How hard would it be to 
>> reverse this so that the data array is first interpolated & resampled
>> and then converted by cmap to RGB?
>
> To me, it looks very hard. The color mapping is done first, in
python, and not repeated with
> every draw. The interpolation is done by agg at rendering time.
Logically, I don't know any
> reason why agg shouldn't do what you suggest: interpolate the scalar
field and then convert
> to rgb.
> Maybe agg can do it this way. If so, it would still take quite a
bit of work by someone
> comfortable with agg (i.e., not me) to make the change.
>
> Eric
Ah, that is certainly more difficult that what I would be prepared to
attempt, which is unfortunate because it would greatly improve the
output and reduce the interpolation's computation by a factor of three
(RGB).
Until someone feels up to the challenge, I will just add a manual
interpolation step when necessary for my data. e.g.:
import matplotlib.pyplot as p
import numpy as n
import scipy.ndimage
a = n.random.normal(size=(10,10))
p.imshow(a,interpolation='nearest') # the actual data
p.figure()
p.imshow(a,interpolation='bicubic') # an AGG interpolation of the RGB
values
b = scipy.ndimage.zoom(a,25)[:-24,:-24]
p.figure()
p.imshow(b) # the data interpolated at 25x magnification with a cubic
spline
Thanks for the information,
Andrew

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

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
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>

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 <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
>
>
> --
> ---------------------------------------
> Manuel Metz ............ Stw@AIfA
> Argelander Institut fuer Astronomie
> Auf dem Huegel 71 (room 3.06)
> D - 53121 Bonn
>
> E-Mail: mm...@as...
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>