matplotlib-devel Mailing List for matplotlib

Jouni K. Seppänen wrote:
> Christopher Barker <Chr...@no...> writes:
> 
>> 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. 
>> I think to do this right, you'd need to completely re-design MPL to be 
>> based on a more declarative structure: [...] but it seems that MPL is 
>> built to be used from a scripting interface instead: a series of 
>> commands that builds the figure.
> 
> I don't think that is the real problem. How matplotlib works is that the
> plotting commands build up a data structure consisting of various
> objects pointing to each other, and when you call show or savefig, the
> data structure is traversed and the appropriate backend functions are
> called. In principle it should not be very difficult to serialize this
> data structure, but since extension objects are involved, some work
> might be needed to get it right.
> 
> What I think is the really difficult part is keeping the serialized
> format somehow usable across different versions of matplotlib. When
> anything changes in the various classes, the developers would need to
> decide how the change is reflected in the on-disk format, how files
> corresponding to the old class should be read in using the new class,
> etc. Perhaps something like Google's protocol buffers could be used to
> make this easier, but it would still be an burden on all subsequent
> development.
> 
Exactly. I *strongly* oppose any move in this direction. It would be 
enabling bad workflow strategy on the part of users, providing no 
benefit that cannot be achieved better with a good workflow strategy, 
and adding complexity. We have enough of that already. We need to 
think about how to clean up mpl and make it easier to maintain and 
improve, not clutter it with ever more complexity.
Eric

Christopher Barker <Chr...@no...> writes:
> 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. 
>
> I think to do this right, you'd need to completely re-design MPL to be 
> based on a more declarative structure: [...] but it seems that MPL is 
> built to be used from a scripting interface instead: a series of 
> commands that builds the figure.
I don't think that is the real problem. How matplotlib works is that the
plotting commands build up a data structure consisting of various
objects pointing to each other, and when you call show or savefig, the
data structure is traversed and the appropriate backend functions are
called. In principle it should not be very difficult to serialize this
data structure, but since extension objects are involved, some work
might be needed to get it right.
What I think is the really difficult part is keeping the serialized
format somehow usable across different versions of matplotlib. When
anything changes in the various classes, the developers would need to
decide how the change is reflected in the on-disk format, how files
corresponding to the old class should be read in using the new class,
etc. Perhaps something like Google's protocol buffers could be used to
make this easier, but it would still be an burden on all subsequent
development.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Pierre GM wrote:
> On Dec 18, 2009, at 10:34 PM, Andrew Straw wrote:
> 
>> Fernando Perez wrote:
>> 
>>> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw <str...@as...> wrote:
>>>
>>> 
>>>> (This still leaves open the question of what the notches actually _are_...)
>>>>
>>>> 
>>> No idea. I'd still leave the code instead written as
>>>
>>> notch_max = med + (iq/2) * (pi/np.sqrt(row))
>>>
>>> 
>> Further searching turned this up: 
>> http://seismo.berkeley.edu/~kirchner/eps_120/Toolkits/Toolkit_01.pdf
>>
>> It says that
>>
>> median +/- 1.57 * (iq / sqrt(n)) is the median, plus or minus its standard error.
>>
>>
>> I can't find any further support for this notion, though.
>> 
>
>
> Looks like the std error of the median is (1.253*std error of the mean=1.253*std dev/sqrt(nb of obs)).
> The 1.57 looks like it's 1.253^2, but I wouldn't bet anything on it...
>
> 
Also, I think that formula is only for normally distributed data. Which, 
especially if you're using boxplots, medians, and quartiles, may not be 
a valid assumption.
Maybe we should at least raise a warning when someone uses notch=1. The 
current implementation seems dubious, at best, IMO.
-Andrew

Fernando Perez wrote:
> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw <str...@as...> wrote:
> 
>> (This still leaves open the question of what the notches actually _are_...)
>> 
>
> No idea. I'd still leave the code instead written as
>
> notch_max = med + (iq/2) * (pi/np.sqrt(row))
> 
Further searching turned this up: 
http://seismo.berkeley.edu/~kirchner/eps_120/Toolkits/Toolkit_01.pdf
It says that
median +/- 1.57 * (iq / sqrt(n)) is the median, plus or minus its standard error.
I can't find any further support for this notion, though.
I've decided not to use notches on my own plots, so I'm leaving this 
issue for now...
-Andrew

On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw <str...@as...> wrote:
> (This still leaves open the question of what the notches actually _are_...)
No idea. I'd still leave the code instead written as
notch_max = med + (iq/2) * (pi/np.sqrt(row))
as that's what it appears to be doing (unless 1.57 is *not* pi/2 in
this case). That might help someone spot what formula the factors
come from. Even better would be to get from the original author an
explanation of where those factors come from :) I did look around
some more, couldn't find an answer...
Cheers,
f