matplotlib-devel Mailing List for matplotlib (Page 15)

On Fri, Jul 11, 2008 at 03:22:30PM +0200, David M. Kaplan wrote:
> The way I have implemented it is by adding an additional class
> BlockingKeyMouseInput, which is quite similar to BlockingMouseInput, but
> waits for both key and mouse events. A smarter person than I could
> probably combine these two classes and make something that would serve
> both functions. But I am basically new to python and don't feel
> comfortable. Perhaps someone else could take a look and make
> improvements/simplifications?
The only significantly different lines are the two lines where an
mplconnect is done to register the callback. You could abstract this in a
method and then have a base class and two sub classes for each call: the
blocking from mouse and the blocking from button.
> The other thing that I have noticed with both ginput and
> waitforbuttonpress is that if you use ctrl-c to break out of either,
> then the callback functions remain attached to their respective events
> (e.g., try ginput(n=-1,timeout=-1,verbose=True) and hit ctrl-c). This
> probably isn't a huge problem, but it would be nice if there was a way
> to say "if ctrl-c is pressed, cleanup nicely". Does someone know if
> that is possible?
I think this is a good usecase for a try: ... finally: ... .
I don't have time to do these changes right now, as I am very busy both
with IPython and Mayavi, and will be travelling next two weeks, but you
can have a good at them, and someone else will probably commit your
patch, if you removed the code duplication.
Cheers,
Gaël

Hi,
Following Gael Varoquaux's lead on adding a ginput command to matplotlib
(nice job!), I added a waitforbuttonpress function to matplotlib. The
patch is attached (generate using svn diff from the
matplotlib/trunk/matplotlib directory). waitforbuttonpress is a simple
function with a matlab equivalent that returns a list of true/false's -
true for a keyboard click and false for a mouse click. I use it in
matlab regularly as a simple yes/no question (often to decide whether or
not to save a figure). 
The way I have implemented it is by adding an additional class
BlockingKeyMouseInput, which is quite similar to BlockingMouseInput, but
waits for both key and mouse events. A smarter person than I could
probably combine these two classes and make something that would serve
both functions. But I am basically new to python and don't feel
comfortable. Perhaps someone else could take a look and make
improvements/simplifications?
The other thing that I have noticed with both ginput and
waitforbuttonpress is that if you use ctrl-c to break out of either,
then the callback functions remain attached to their respective events
(e.g., try ginput(n=-1,timeout=-1,verbose=True) and hit ctrl-c). This
probably isn't a huge problem, but it would be nice if there was a way
to say "if ctrl-c is pressed, cleanup nicely". Does someone know if
that is possible?
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************
-- 
**********************************
David M. Kaplan
Assistant Researcher
UCSC / Institute of Marine Sciences
Ocean Sciences
1156 High St.
SC, CA 95064
Phone: 831-459-4789
Fax: 831-459-4882
http://pmc.ucsc.edu/~dmk/
**********************************

Hello,
This is a reminder that early registration for SciPy 2008 ends in two
days on Friday, July 11th. To register, please see:
 http://conference.scipy.org/to_register
This year's conference has two days for tutorials, two days of
presentations, and ends with a two day coding sprint. If you want to
learn more see my blog post:
http://jarrodmillman.blogspot.com/2008/07/scipy-2008-conference-program-posted.html
Cheers,
-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/

On Wednesday 09 July 2008 09:41:08 am Michael Droettboom wrote:
> Ondrej Certik wrote:
> > Hi,
> >
> > I have a question regarding the pure python latex rendering engine. If
> > I look here:
> >
> > http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts
> >
> > was this generated using it? If so, it seems to me it doesn't look
> > exactly as TeX output, for example in the sqrt(2), the upper line is
> > slightly over the edge of the \/ line in the sqrt.
>
> The fudge factor to get this in the right place (since the position of
> the tick isn't exactly as the metrics would lead us to believe), was dpi
> dependent. This has been fixed.
>
> > Or in the s(t) = Asin(wt)
> >
> > the "A" and "sin" is too much close to each other. Or if you scroll to
> > the very bottom of the page, the Sum and x_i are also too much close
> > to each other.
>
> This is a harder problem. Unfortunately, unlike TeX, we don't have any
> tables of cross-font kerning information. This could perhaps be
> remedied by making everything a little looser, but I don't see a way out
> outside of writing kerning tables or doing autokerning (haven't looked
> deep enough to know how hard that might be). We could hard code some
> hacks for the common cases (especially the summation symbol), which
> would at least create a framework for custom kerning tables, even if we
> only fill in some of the combinations. And of course, since we support
> three different font sets (cm, stix and stixsans), these hacks will have
> to be customized for each.
>
> > Is it a font problem? If yes, how could this be fixed? If not, would
> > it be difficult to find the problem in the algorithm and fix it? I
> > haven't studied the TeX algorithm deeply,
> > so I cannot judge if it's a trivial fix, or something very difficult.
> >
> > Otherwise it looks good. We were thinking with Stefan that when we get
> > to Austin together on around August 8, we'll polish it and get it to
> > sphinx by default, so that any other project, like numpy or sympy
> > could use it as well easily.
>
> Look at mathpng.py in the matplotlib/doc/sphinxext directory. That
> (plus an installation of matplotlib) should be all you need. It
> probably needs to be generalized to put the image files in the right
> place. (Currently in puts them in _static/ -- maybe that should be
> somewhere under build/).
>
> Or course, matplotlib is using this approach for its docs as a matter of
> "dogfooding". It may be that the more appropriate choice for Sphinx in
> general is something that uses latex/dvipng, since latex is already a
> requirement for Sphinx in general.
I agree.

Ondrej Certik wrote:
> Hi,
>
> I have a question regarding the pure python latex rendering engine. If
> I look here:
>
> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts
>
> was this generated using it? If so, it seems to me it doesn't look
> exactly as TeX output, for example in the sqrt(2), the upper line is
> slightly over the edge of the \/ line in the sqrt.
> 
The fudge factor to get this in the right place (since the position of 
the tick isn't exactly as the metrics would lead us to believe), was dpi 
dependent. This has been fixed.
> Or in the s(t) = Asin(wt)
>
> the "A" and "sin" is too much close to each other. Or if you scroll to
> the very bottom of the page, the Sum and x_i are also too much close
> to each other.
> 
This is a harder problem. Unfortunately, unlike TeX, we don't have any 
tables of cross-font kerning information. This could perhaps be 
remedied by making everything a little looser, but I don't see a way out 
outside of writing kerning tables or doing autokerning (haven't looked 
deep enough to know how hard that might be). We could hard code some 
hacks for the common cases (especially the summation symbol), which 
would at least create a framework for custom kerning tables, even if we 
only fill in some of the combinations. And of course, since we support 
three different font sets (cm, stix and stixsans), these hacks will have 
to be customized for each.
> Is it a font problem? If yes, how could this be fixed? If not, would
> it be difficult to find the problem in the algorithm and fix it? I
> haven't studied the TeX algorithm deeply,
> so I cannot judge if it's a trivial fix, or something very difficult.
>
> Otherwise it looks good. We were thinking with Stefan that when we get
> to Austin together on around August 8, we'll polish it and get it to
> sphinx by default, so that any other project, like numpy or sympy
> could use it as well easily.
> 
Look at mathpng.py in the matplotlib/doc/sphinxext directory. That 
(plus an installation of matplotlib) should be all you need. It 
probably needs to be generalized to put the image files in the right 
place. (Currently in puts them in _static/ -- maybe that should be 
somewhere under build/).
Or course, matplotlib is using this approach for its docs as a matter of 
"dogfooding". It may be that the more appropriate choice for Sphinx in 
general is something that uses latex/dvipng, since latex is already a 
requirement for Sphinx in general.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I have a question regarding the pure python latex rendering engine. If
I look here:
http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts
was this generated using it? If so, it seems to me it doesn't look
exactly as TeX output, for example in the sqrt(2), the upper line is
slightly over the edge of the \/ line in the sqrt.
Or in the s(t) = Asin(wt)
the "A" and "sin" is too much close to each other. Or if you scroll to
the very bottom of the page, the Sum and x_i are also too much close
to each other.
Is it a font problem? If yes, how could this be fixed? If not, would
it be difficult to find the problem in the algorithm and fix it? I
haven't studied the TeX algorithm deeply,
so I cannot judge if it's a trivial fix, or something very difficult.
Otherwise it looks good. We were thinking with Stefan that when we get
to Austin together on around August 8, we'll polish it and get it to
sphinx by default, so that any other project, like numpy or sympy
could use it as well easily.
Thanks a lot,
Ondrej

Hi,
I just wanted to say that I like the current matplotlib's (0.98.1)
line thickness and colors.
I don't know what exactly has changed since before, but the figures
now look really great. It's a pleasure to look at it. Thanks!
Ondrej

Yes, I believe so, barring any other side effects we inadvertently 
create in the future... ;)
Mike
Darren Dale wrote:
> On Monday 07 July 2008 02:33:40 pm Michael Droettboom wrote:
> 
>> Fernando Perez wrote:
>> 
>>> On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> 
>>> 
> wrote:
> 
>>>> Thank you for finding this! That is indeed the case.
>>>>
>>>> I think we need to rework the plot generation code to avoid side effects
>>>> by forcibly resetting state between plots. Maybe we should just fork
>>>> another Python process for each plot. Darren, since (I believe) you
>>>> wrote the initial documentation plotting code, do you have any thoughts?
>>>> 
>>> Isn't that unnecessarily slow? Why not have each plot simply make a
>>> call to load a clean state? rc_defaults() or somesuch? This little
>>> call could even be auto-run by the doc generation code, without
>>> requiring a full process restart.
>>> 
>> Agreed, and that does seem to fix this particular issue.
>> 
>
> Sorry I didn't respond before now, I got back into town last night. Tony, 
> thank you for tracking this down, that was a really good find. I don't think 
> I would have ever thought to look in the right place. 
>
> Mike, is the issue settled?
>
> Darren
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Monday 07 July 2008 02:33:40 pm Michael Droettboom wrote:
> Fernando Perez wrote:
> > On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> 
wrote:
> >> Thank you for finding this! That is indeed the case.
> >>
> >> I think we need to rework the plot generation code to avoid side effects
> >> by forcibly resetting state between plots. Maybe we should just fork
> >> another Python process for each plot. Darren, since (I believe) you
> >> wrote the initial documentation plotting code, do you have any thoughts?
> >
> > Isn't that unnecessarily slow? Why not have each plot simply make a
> > call to load a clean state? rc_defaults() or somesuch? This little
> > call could even be auto-run by the doc generation code, without
> > requiring a full process restart.
>
> Agreed, and that does seem to fix this particular issue.
Sorry I didn't respond before now, I got back into town last night. Tony, 
thank you for tracking this down, that was a really good find. I don't think 
I would have ever thought to look in the right place. 
Mike, is the issue settled?
Darren

Fernando Perez wrote:
> On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> wrote:
> 
>> Thank you for finding this! That is indeed the case.
>>
>> I think we need to rework the plot generation code to avoid side effects
>> by forcibly resetting state between plots. Maybe we should just fork
>> another Python process for each plot. Darren, since (I believe) you
>> wrote the initial documentation plotting code, do you have any thoughts?
>> 
>
> Isn't that unnecessarily slow? Why not have each plot simply make a
> call to load a clean state? rc_defaults() or somesuch? This little
> call could even be auto-run by the doc generation code, without
> requiring a full process restart.
> 
Agreed, and that does seem to fix this particular issue.
> Basically I think MPL should be stateless enough to tolerate working
> in a long-lived process with repeatable results. Anything else should
> be considered a bug IMHO ;) (I know rcParams is precisely a stateful
> system, but it should be trivial to obtain a known clean state always,
> with a single call).
> 
For the most part, I think that's correct. There are still some 
lingering uses where certain objects and values are cached at startup 
time based on rcParams. (For example, in backend_pdf, and some things 
mathtext used to do). But that's sort of a different issue, because 
there the problem is with some values being immutable after startup, not 
being unable to reset back to the startup state.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Jul 7, 2008 at 10:28 AM, Michael Droettboom <md...@st...> wrote:
> Thank you for finding this! That is indeed the case.
>
> I think we need to rework the plot generation code to avoid side effects
> by forcibly resetting state between plots. Maybe we should just fork
> another Python process for each plot. Darren, since (I believe) you
> wrote the initial documentation plotting code, do you have any thoughts?
Isn't that unnecessarily slow? Why not have each plot simply make a
call to load a clean state? rc_defaults() or somesuch? This little
call could even be auto-run by the doc generation code, without
requiring a full process restart.
Basically I think MPL should be stateless enough to tolerate working
in a long-lived process with repeatable results. Anything else should
be considered a bug IMHO ;) (I know rcParams is precisely a stateful
system, but it should be trivial to obtain a known clean state always,
with a single call).
Cheers,
f

Ah - that makes sense. I guess I didn't catch that change in the release notes. Thanks again!
-----Original Message-----
From: Manuel Metz [mailto:mm...@as...]
Sent: 7 Jul 2008 11:49 AM
To: mat...@li...
Cc: Andrew Hawryluk
Subject: Re: [matplotlib-devel] hist doesn't work with 2D arrays
Andrew Hawryluk wrote:
> Hopefully this isn't old news for you. Since the 0.98 release, the histogram plot doesn't work properly with 2D arrays: it is quite slow and the output is wrong. Passing a flattened array produces the quick, correct output that we are accustomed to. Here is the test code I ran, and the attached image shows the output compared with the previous version.
> 
> import numpy as n
> import matplotlib.pyplot as p
> 
> a = n.random.normal(size=10000)
> a = a.reshape((100,100)) # make a 2D array of normally-distributed random numbers
> p.hist(a)
> 
> 
> Thanks for your work on matplotlib!
Hi Andrew,
 2D arrays are now treated differently. An (N,M) 2D array is 
interpreted as M data-sets with N elements each, e.g.
a = n.random.normal(size=10000)
a = a.reshape((1000,10))
is interpreted as 10 data-sets with 1000 elements each. See 
histogram_demo_extended.py in examples/pylab_examples.
To reproduce the old behaviour you should use pylab.hist(a.flat).
Manuel
> Andrew Hawryluk
> Calgary, Canada
> <<hist-comparison.png>> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Andrew Hawryluk wrote:
> Hopefully this isn't old news for you. Since the 0.98 release, the histogram plot doesn't work properly with 2D arrays: it is quite slow and the output is wrong. Passing a flattened array produces the quick, correct output that we are accustomed to. Here is the test code I ran, and the attached image shows the output compared with the previous version.
> 
> import numpy as n
> import matplotlib.pyplot as p
> 
> a = n.random.normal(size=10000)
> a = a.reshape((100,100)) # make a 2D array of normally-distributed random numbers
> p.hist(a)
> 
> 
> Thanks for your work on matplotlib!
Hi Andrew,
 2D arrays are now treated differently. An (N,M) 2D array is 
interpreted as M data-sets with N elements each, e.g.
a = n.random.normal(size=10000)
a = a.reshape((1000,10))
is interpreted as 10 data-sets with 1000 elements each. See 
histogram_demo_extended.py in examples/pylab_examples.
To reproduce the old behaviour you should use pylab.hist(a.flat).
Manuel
> Andrew Hawryluk
> Calgary, Canada
> <<hist-comparison.png>> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Thank you for finding this! That is indeed the case.
I think we need to rework the plot generation code to avoid side effects 
by forcibly resetting state between plots. Maybe we should just fork 
another Python process for each plot. Darren, since (I believe) you 
wrote the initial documentation plotting code, do you have any thoughts?
Cheers,
Mike
Tony Yu wrote:
>
> On Jul 7, 2008, at 12:19 PM, Michael Droettboom wrote:
>
>> I noticed today that the examples in the docs have the ticks on the
>> outside of the axes. You can see it here:
>>
>> http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html
>>
>> I'm having a terrible time tracking down the cause -- maybe I'm just not
>> thinking clearly today. By version bisection, I determined that it
>> broke with revision 5690:
>>
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690 
>>
>>
>> I've verified this twice (cleaning all build and installation remnants
>> out in between), and I'm pretty sure that's the revision where things 
>> break.
>>
>> But there's nothing in that revision that leaps out as a cause
>> (particularly since the effect is global and affects plots that weren't
>> even updated in that revision).
>
> I think this problem is actually caused by contour_demo.py which sets
>
> >>> matplotlib.rcParams['xtick.direction'] = 'out'
> >>> matplotlib.rcParams['ytick.direction'] = 'out'
>
> Every plot called after contour_demo.py will probably have ticks 
> outside of the axes. I think this problem has to do with how Python 
> does imports (I'm on shaky ground here, so my explanation may be 
> wrong). If matplotlib is already imported then a new call to `import 
> matplotlib` doesn't actually do anything. So the above change rcParams 
> never gets reinitialized to the default values.
>
> Try adding
>
> >>> matplotlib.rcParams['xtick.direction'] = 'in'
> >>> matplotlib.rcParams['ytick.direction'] = 'in'
>
> to the end of contour_demo.py.
>
>
> -Tony
>
>>
>> One other tidbit of information -- the example plots work fine when
>> called directly. This only seems to affect plots generated for the 
>> docs.
>>
>> Any ideas?
>>
>> Mike
>>
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Removing all contents of the doc/matplotlibrc and 
doc/pyplots/matplotlibrc files (reverting to the defaults), or removing 
the files completely, does not fix the tick outside the axes issue... 
Removing my ~/.matplotlib/matplotlibrc does not resolve the issue. 
However, other rcparam values do change and have the expected impact, so 
it isn't just that the doc/matplotlibrc and doc/pyplot/matplotlibrc 
aren't being read.
Cheers,
Mike
Fernando Perez wrote:
> On Mon, Jul 7, 2008 at 10:14 AM, Michael Droettboom <md...@st...> wrote:
> 
>> Yes, but curiously, it doesn't change between those revisions...
>> 
>
> But it's different from *your* user rc file. That might point to the
> setting that causes the problem...
>
> f
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jul 7, 2008, at 12:19 PM, Michael Droettboom wrote:
> I noticed today that the examples in the docs have the ticks on the
> outside of the axes. You can see it here:
>
> http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html
>
> I'm having a terrible time tracking down the cause -- maybe I'm just 
> not
> thinking clearly today. By version bisection, I determined that it
> broke with revision 5690:
>
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690
>
> I've verified this twice (cleaning all build and installation remnants
> out in between), and I'm pretty sure that's the revision where 
> things break.
>
> But there's nothing in that revision that leaps out as a cause
> (particularly since the effect is global and affects plots that 
> weren't
> even updated in that revision).
I think this problem is actually caused by contour_demo.py which sets
 >>> matplotlib.rcParams['xtick.direction'] = 'out'
 >>> matplotlib.rcParams['ytick.direction'] = 'out'
Every plot called after contour_demo.py will probably have ticks 
outside of the axes. I think this problem has to do with how Python 
does imports (I'm on shaky ground here, so my explanation may be 
wrong). If matplotlib is already imported then a new call to `import 
matplotlib` doesn't actually do anything. So the above change rcParams 
never gets reinitialized to the default values.
Try adding
 >>> matplotlib.rcParams['xtick.direction'] = 'in'
 >>> matplotlib.rcParams['ytick.direction'] = 'in'
to the end of contour_demo.py.
-Tony
>
> One other tidbit of information -- the example plots work fine when
> called directly. This only seems to affect plots generated for the 
> docs.
>
> Any ideas?
>
> Mike
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Jul 7, 2008 at 10:14 AM, Michael Droettboom <md...@st...> wrote:
> Yes, but curiously, it doesn't change between those revisions...
But it's different from *your* user rc file. That might point to the
setting that causes the problem...
f

Hopefully this isn't old news for you. Since the 0.98 release, the histogram plot doesn't work properly with 2D arrays: it is quite slow and the output is wrong. Passing a flattened array produces the quick, correct output that we are accustomed to. Here is the test code I ran, and the attached image shows the output compared with the previous version.
import numpy as n
import matplotlib.pyplot as p
a = n.random.normal(size=10000)
a = a.reshape((100,100)) # make a 2D array of normally-distributed random numbers
p.hist(a)
Thanks for your work on matplotlib!
Andrew Hawryluk
Calgary, Canada
 <<hist-comparison.png>> 

Yes, but curiously, it doesn't change between those revisions...
Mike
Fernando Perez wrote:
> On Mon, Jul 7, 2008 at 9:19 AM, Michael Droettboom <md...@st...> wrote:
>
> 
>> One other tidbit of information -- the example plots work fine when
>> called directly. This only seems to affect plots generated for the docs.
>> 
>
> Are the docs built with a custom .matplotlibrc? Maybe there's a
> different setting there that's triggering a bug...
>
> Cheers,
>
> f
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Jul 7, 2008 at 9:19 AM, Michael Droettboom <md...@st...> wrote:
> One other tidbit of information -- the example plots work fine when
> called directly. This only seems to affect plots generated for the docs.
Are the docs built with a custom .matplotlibrc? Maybe there's a
different setting there that's triggering a bug...
Cheers,
f

I noticed today that the examples in the docs have the ticks on the 
outside of the axes. You can see it here:
 http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html
I'm having a terrible time tracking down the cause -- maybe I'm just not 
thinking clearly today. By version bisection, I determined that it 
broke with revision 5690:
 
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690
I've verified this twice (cleaning all build and installation remnants 
out in between), and I'm pretty sure that's the revision where things break.
But there's nothing in that revision that leaps out as a cause 
(particularly since the effect is global and affects plots that weren't 
even updated in that revision).
One other tidbit of information -- the example plots work fine when 
called directly. This only seems to affect plots generated for the docs.
Any ideas?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks Michael and Eric for your constructive replies and your help.
It is know clear for me why my code was luckily working with 0.91 but 
not with 0.98. This is certainly going to help me finding a robust 
solution for both cases.
Regards,
David
Michael Droettboom a écrit :
> David,
> 
> There is no code in matplotlib to autoscale shared axes, and as far as I 
> know, there never has been. Unfortunately, it's more or less a 
> requirement that you have to set the limits manually when using shared 
> axes. (All of the shared axes examples do this).
> 
> I think, 0.91 is broken also, it just happens to use the first plotted 
> line rather than the second (it truncates the red line, rather than the 
> blue one). The difference in ordering is due to the fact that sharing 
> is now always bi-directional in 0.98 and it uses dictionaries with a 
> somewhat random ordering, rather than lists. If you see different 
> behavior than my plots (attached) let me know.
> Eric Firing wrote:
>> This looks like a rather fundamental problem in the present 
>> architecture. I thought I had a solution figured out, but I was 
>> wrong, and now I am not confident that I can come up with a good 
>> solution quickly. Some consultation with, or intervention by, Mike D. 
>> may be needed--he might even see a solution in a matter of minutes. 
>> The problem is that the dataLim for each axes object is a Bbox, and in 
>> this implementation there is no way to share an x-interval or a 
>> y-interval among Bboxes. So there is a single xaxis major locator 
>> that is shared, but it is only getting its dataLim updated from one of 
>> the shared axes.
>> 
> 
> Just to clarify: this limitation is not new to the 0.98 architecture. 
> 0.91 also uses Bboxes for data limits and does not directly share the x- 
> or y-limits: they are updated using callbacks when the limits change. 
> The difference in 0.98 is that the references between axes are set up 
> (effectively) bidirectionally so there's no longer a notion of a 
> "controlling" axes and "following" axes. It was easy in 0.91 to set up 
> a situation where shared axes would only update if one, but not both, of 
> the pair were zoomed/panned, and that bug has been fixed.
> 
> Back when the 0.98 transformations were being written, John and I had a 
> long discussion about whether data limits should be Bbox-like or 
> pair-of-intervals-like, and we ultimately decided to leave things as-is 
> to avoid creating too much newness at once. IMHO, however, the real 
> problem is that the shared axes mechanism doesn't know whether the 
> limits are changing because of autoscaling (in which case the limits 
> should be unioned together), or panning/zooming, in which case the 
> limits need to be replaced. The second problem is probably necessary to 
> fix whether we use Bboxes or not.
> 
> Cheers,
> Mike
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 

David,
There is no code in matplotlib to autoscale shared axes, and as far as I 
know, there never has been. Unfortunately, it's more or less a 
requirement that you have to set the limits manually when using shared 
axes. (All of the shared axes examples do this).
I think, 0.91 is broken also, it just happens to use the first plotted 
line rather than the second (it truncates the red line, rather than the 
blue one). The difference in ordering is due to the fact that sharing 
is now always bi-directional in 0.98 and it uses dictionaries with a 
somewhat random ordering, rather than lists. If you see different 
behavior than my plots (attached) let me know. 
Eric Firing wrote:
> This looks like a rather fundamental problem in the present 
> architecture. I thought I had a solution figured out, but I was wrong, 
> and now I am not confident that I can come up with a good solution 
> quickly. Some consultation with, or intervention by, Mike D. may be 
> needed--he might even see a solution in a matter of minutes. The 
> problem is that the dataLim for each axes object is a Bbox, and in this 
> implementation there is no way to share an x-interval or a y-interval 
> among Bboxes. So there is a single xaxis major locator that is shared, 
> but it is only getting its dataLim updated from one of the shared axes.
> 
Just to clarify: this limitation is not new to the 0.98 architecture. 
0.91 also uses Bboxes for data limits and does not directly share the x- 
or y-limits: they are updated using callbacks when the limits change. 
The difference in 0.98 is that the references between axes are set up 
(effectively) bidirectionally so there's no longer a notion of a 
"controlling" axes and "following" axes. It was easy in 0.91 to set up 
a situation where shared axes would only update if one, but not both, of 
the pair were zoomed/panned, and that bug has been fixed.
Back when the 0.98 transformations were being written, John and I had a 
long discussion about whether data limits should be Bbox-like or 
pair-of-intervals-like, and we ultimately decided to leave things as-is 
to avoid creating too much newness at once. IMHO, however, the real 
problem is that the shared axes mechanism doesn't know whether the 
limits are changing because of autoscaling (in which case the limits 
should be unioned together), or panning/zooming, in which case the 
limits need to be replaced. The second problem is probably necessary to 
fix whether we use Bboxes or not.
Cheers,
Mike

We have received a large number of excellent contributions for papers for
the SciPy 2008 conference. The program committee has had to make a
difficult selection and we are happy to bring to you a preliminary
schedule:
Thursday
=========
**8:00** Registration/Breakfast
**8:55** Welcome (Travis Vaught)
**9:10** Keynote (Alex Martelli)
**10:00** State of SciPy (Travis Vaught, Jarrod Millman)
**10:40** -- Break --
**11:00** Sympy - Python library for symbolic mathematics: introduction
and applications (Ondřej Čertik)
**11:40** Interval arithmetic: Python implementation and applications
(Stefano Taschini)
**12:00** Experiences Using Scipy for Computer Vision Research (Damian
Eads)
**12:20** -- Lunch --
**1:40** The new NumPy documentation framework (Stéfan Van der Walt)
**2:00** Matplotlib solves the riddle of the sphinx (Michael Droettboom)
**2:40** The SciPy documentation project (Joe Harrington)
**3:00** -- Break --
**3:40** Sage: creating a viable free Python-based open source
alternatice to Magma, Maple, Mathematica and Matlab (William Stein)
**4:20** Open space for lightning talks
Friday
========
**8:30** Breakfast
**9:00** Pysynphot: A Python Re-Implementation of a Legacy App in
Astronomy
(Perry Greenfield)
**9:40** How the Large Synoptic Survey Telescope (LSST) is using
Python (Robert Lupton)
**10:00** Real-time Astronomical Time-series Classification and Broadcast
Pipeline (Dan Starr)
**10:20** Analysis and Visualization of Multi-Scale Astrophysical
Simulations using Python and NumPy (Matthew Turk)
**10:40** -- Break --
**11:00** Exploring network structure, dynamics, and function using
NetworkX (Aric Hagberg)
**11:40** Mayavi: Making 3D data visualization reusable (Prabhu
Ramachandran, Gaël Varoquaux)
**12:00** Finite Element Modeling of Contact and Impact Problems Using
Python (Ryan Krauss)
**12:20** -- Lunch --
**2:00** PyCircuitScape: A Tool for Landscape Ecology (Viral Shah)
**2:20** Summarizing Complexity in High Dimensional Spaces (Karl Young)
**2:40** UFuncs: A generic function mechanism in Python (Travis Oliphant)
**3:20** -- Break --
**3:40** NumPy Optimization: Manual tuning and automated approaches (Evan
Patterson)
**4:00** Converting Python functions to dynamically-compiled C (Ilan
Schnell)
**4:20** unPython: Converting Python numerical programs into C
(Rahul Garg)
**4:40** Implementing the Grammar of Graphics for Python (Robert Kern)
**5:00** Ask the experts session.
A more detailled booklet including the abstract text will be available
soon.
We are looking forward to seeing you in Caltech,
Gaël Varoquaux, on behalf of the program committee.
--
SciPy2008 conference.
Program committee
Anne Archibald, McGill University
Matthew Brett
Perry Greenfield, Space Telescope Science Institute
Charles Harris
Ryan Krauss, Southern Illinois University
Gaël Varoquaux
Stéfan van der Walt, University of Stellenbosch

David Trem wrote:
> Hi,
> 
> I narrowed down the problem I've posted on the matplotlib user list
> and now it looks like I found a matplotlib bug in 0.98 version.
> 
> The shared axes auto-scaling is not properly working in 0.98 (works
> with the 0.91). Indeed, As shown, in the small attached script, the
> shared x scale does not show the full curves (axs1 blue curve should go 
> up to 120 on axis).
> In fact, if x axes is shared, the figure xmin and xmax are defined by 
> the last plotted axes (axs2) and does not take into account the min/max 
> from the first one which cut it. One would expect to see both curve 
> entirely.
> 
> Could someone have look at this problem. I will try to dive in 
> matplotlib code but I'm not an expert at all...
David,
This looks like a rather fundamental problem in the present 
architecture. I thought I had a solution figured out, but I was wrong, 
and now I am not confident that I can come up with a good solution 
quickly. Some consultation with, or intervention by, Mike D. may be 
needed--he might even see a solution in a matter of minutes. The 
problem is that the dataLim for each axes object is a Bbox, and in this 
implementation there is no way to share an x-interval or a y-interval 
among Bboxes. So there is a single xaxis major locator that is shared, 
but it is only getting its dataLim updated from one of the shared axes.
Eric
> 
> Thanks in advance,
> 
> David