matplotlib-devel Mailing List for matplotlib

Andrew Straw wrote:
> The following (uncommitted) test currently fails. The reason is that 
> mlab.prctile(x,50) doesn't handle even length sequences according to the 
> numpy and wikipedia convention for the definition of median. Do we agree 
> that it should pass?
> 
I'll take the silence as +0. Therefore, I committed the test in r8038 
and the bugfix in r8039.
-Andrew

Fernando Perez wrote:
> Note that the code below does:
>
> if notch_max > q3:
> notch_max = q3
> if notch_min < q1:
> notch_min = q1
>
> though matlab explicitly states in:
>
> http://www.mathworks.com/access/helpdesk/help/toolbox/stats/boxplot.html
>
> that
>
> """
> Interval endpoints are the extremes of the notches or the centers of
> the triangular markers. When the sample size is small, notches may
> extend beyond the end of the box.
> """
>
> So it seems to me that the more principled thing to do would be to
> leave those notch markers outside the box if they land there, because
> that's a warning of the robustness of the estimation. Clipping them to
> q1/q3 is effectively hiding a problem...
>
> 
I agree. I disabled the boxplot notch shortening in r8040.
(This still leaves open the question of what the notches actually _are_...)
-Andrew

Joey Wilson wrote:
> I would like to be able to save the figures from 
> matplotlib in an editable form, without flattening down to an image 
> file. 
> Now, I understand that resources are limited, so I would be willing to 
> raise some money to get this feature added to Matplotlib. 
I think to do this right, you'd need to completely re-design MPL to be 
based on a more declarative structure: i.e. you'd define what the 
objects were in a figure, and MPL would generate the figure from the 
declaration -- much like how an drawing is generated from SVG. Maybe 
it's not as big a re-factor I think it is, but it seems that MPL is 
built to be used from a scripting interface instead: a series of 
commands that builds the figure.
Honestly, for your purposes, I don't know that there is much difference. 
I suppose what you are looking for a is a way to get a script that you 
could edit and re-run, but have it generated from a figure 
automatically, the figure itself could have been generated by a 
different script (intermeshed with computational code), or an 
interactive session, or....
That would be pretty cool, but I think a bit of re-factoring of your 
process would make it pretty easy to edit and re-run your scripts anyway.
> I 
> would really like to completely replace Matlab with Python,Scipy, and 
> Matplotlib.
How does Matlab handle this? In my Matlab days, I wrote scripts that 
generated my figures, and when I needed to change them, I edited the 
scripts and re-ran them -- exactly the workflow we're suggesting for 
Python/MPL. But that was 10 years ago...
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw <str...@as...> wrote:
> It's not clear to me if this proposal lets one specify any arbitrary affine
> transformation. Does it?
I believe it does. 3 coordinates will define 6 equations where we have
6 unknowns of the affine matrix.
The question is how user want to specify the transform.
The extended extent keyword would be useful for the cases like the
pseudo-perspective projection that you mentioned. But, it will not be
very convenient for the cases like simple rotation.
>
> In general -- very nice. Thanks.
>
> In specific, I think the way you have already implemented things is
> sufficient. I think if a user can write a little helper function (as in your
> demo) to avoid a dumbed-down API being part of MPL, that would be best.
> Anyone specifying their own affine transform is probably going to want a
> pretty precise level of control, anyway. (Of course if your extent keyword
> proposal is already a general purpose API, then please ignore this comment.)
I, personally, don't like the idea that user needs to define his/her
own transform to rotate/skew the image. Rotation and skew seems more
like properties of the image, rather than the transform.
Anyhow, unless others step in, I may leave it as is (partially because
I don't have much use case for rotated/skewed images for now). And, I
hope someone implement similar affine transform for other backends.
For the backends that requires resampling (agg, etc.), it might be
better if the affine transform is taken care during the resampling
(i.e., in the Image.draw method) rather than to be delegated to the
backends.
Regards,
-JJ
>
> -Andrew
>