Menu
▾
▴
matplotlib-devel
|
From: Mark B. <ma...@gm...> - 2008-10-21 10:13:54
|
Hello list (especially Erik, who can fix this I hope) - I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom. My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug: ax1 = subplot(211) plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot? But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'. ax1 = subplot(211,aspect='equal') plot([1,2,3]) subplot(212,sharex=ax1) The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore ax1.set_xlim(0,2) draw() Thanks for your help. I am willing to help in testing any changes. Best regards, Mark |
|
From: Eric F. <ef...@ha...> - 2008-10-22 08:58:34
|
Mark Bakker wrote: > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the axis > has an aspect ratio that is set 'equal'. It has been discussed on the > list before (mostly with Erik Firing), but it hasn't been fixed yet. > What I want to do is have two plots. The top plot has an aspect ratio > that is 'equal'. The idea is to have a contour plot in the top figure, > while the bottom figure gives a cross-sectional picture of what I am > plotting. This used to work well (quite some time ago), including > zooming and such. But now I cannot plot it at all, let alone zoom. > > My first problem is when I add a subplot with a shared x-axis, it > changes the limits on the original x-axis. That seems to be a bug: > ax1 = subplot(211) > plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. > subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. > > After all, the new subplot shares the axis with the existing subplot, so > why doesn't it copy the axis limits from that subplot? I may have the fix for this, but I need more time to check and refine it--and try to make sure that I don't break anything else in the process. > > But the bigger problem occurs when I want the aspect ratio of one of the > first axis to be 'equal'. > > ax1 = subplot(211,aspect='equal') > plot([1,2,3]) > subplot(212,sharex=ax1) > > The second subplot is added, but the length of the graph is not the same > as for the first subplot. It also resets the xlimits to go from 0 to 1, > as before, which means the first subplot becomes unreadable (it still > enforces 'equal' in the first subplot by changing the limits of the > y-axis). When I now change the limits on the x-axis, the aspect ratio is > not equal anymore > I will see what I can do. There are definitely some bugs that need to be squashed. Eric > ax1.set_xlim(0,2) > draw() > > Thanks for your help. I am willing to help in testing any changes. > > Best regards, Mark |
|
From: Mark B. <ma...@gm...> - 2008-10-22 09:39:57
|
Thanks Eric. You know that this has been on my wish list for a long time. Let me know if I can test anything or help in any other way, Mark On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha...> wrote: > Mark Bakker wrote: > >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the axis has >> an aspect ratio that is set 'equal'. It has been discussed on the list >> before (mostly with Erik Firing), but it hasn't been fixed yet. What I want >> to do is have two plots. The top plot has an aspect ratio that is 'equal'. >> The idea is to have a contour plot in the top figure, while the bottom >> figure gives a cross-sectional picture of what I am plotting. This used to >> work well (quite some time ago), including zooming and such. But now I >> cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, it changes >> the limits on the original x-axis. That seems to be a bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. >> >> After all, the new subplot shares the axis with the existing subplot, so >> why doesn't it copy the axis limits from that subplot? >> > > I may have the fix for this, but I need more time to check and refine > it--and try to make sure that I don't break anything else in the process. > > >> But the bigger problem occurs when I want the aspect ratio of one of the >> first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> >> The second subplot is added, but the length of the graph is not the same >> as for the first subplot. It also resets the xlimits to go from 0 to 1, as >> before, which means the first subplot becomes unreadable (it still enforces >> 'equal' in the first subplot by changing the limits of the y-axis). When I >> now change the limits on the x-axis, the aspect ratio is not equal anymore >> >> > I will see what I can do. There are definitely some bugs that need to be > squashed. > > Eric > > > ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> > |
|
From: David T. <dav...@gm...> - 2008-10-23 07:38:29
|
Hi, Eric, I will be happy to test your possible fix too. I have similar problem with autoscaling shared axes like you Mark. David Mark Bakker a écrit : > Thanks Eric. > > You know that this has been on my wish list for a long time. > > Let me know if I can test anything or help in any other way, > > Mark > > On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > Mark Bakker wrote: > > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the > axis has an aspect ratio that is set 'equal'. It has been > discussed on the list before (mostly with Erik Firing), but it > hasn't been fixed yet. What I want to do is have two plots. The > top plot has an aspect ratio that is 'equal'. The idea is to > have a contour plot in the top figure, while the bottom figure > gives a cross-sectional picture of what I am plotting. This used > to work well (quite some time ago), including zooming and such. > But now I cannot plot it at all, let alone zoom. > > My first problem is when I add a subplot with a shared x-axis, > it changes the limits on the original x-axis. That seems to be a > bug: > ax1 = subplot(211) > plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. > subplot(212,sharex=ax1) # Now the limits of both x-axis go from > 0 to 1. > > After all, the new subplot shares the axis with the existing > subplot, so why doesn't it copy the axis limits from that subplot? > > > I may have the fix for this, but I need more time to check and > refine it--and try to make sure that I don't break anything else in > the process. > > > > But the bigger problem occurs when I want the aspect ratio of > one of the first axis to be 'equal'. > > ax1 = subplot(211,aspect='equal') > plot([1,2,3]) subplot(212,sharex=ax1) > > The second subplot is added, but the length of the graph is not > the same as for the first subplot. It also resets the xlimits to > go from 0 to 1, as before, which means the first subplot becomes > unreadable (it still enforces 'equal' in the first subplot by > changing the limits of the y-axis). When I now change the limits > on the x-axis, the aspect ratio is not equal anymore > > > I will see what I can do. There are definitely some bugs that need > to be squashed. > > Eric > > > ax1.set_xlim(0,2) > draw() > > Thanks for your help. I am willing to help in testing any changes. > > Best regards, Mark > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 |
|
From: Eric F. <ef...@ha...> - 2008-10-24 00:51:07
|
David Trem wrote: > Hi, > > Eric, I will be happy to test your possible fix too. I have similar > problem with autoscaling shared axes like you Mark. > > David I have committed to svn some changes to support autoscaling with shared axes, so please test. I have done only very simple and cursory checking. You might try reversed axes, log axes, etc. I have not yet addressed the aspect ratio part of Mark's original post, below, but I think my changes have fixed the first of the two problems, in addition to adding autoscaling support, which I don't think we ever had before. At present, autoscaling does not work with shared axes if an aspect ratio is specified. Eric > > Mark Bakker a écrit : >> Thanks Eric. >> >> You know that this has been on my wish list for a long time. >> >> Let me know if I can test anything or help in any other way, >> >> Mark >> >> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha... >> <mailto:ef...@ha...>> wrote: >> >> Mark Bakker wrote: >> >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the >> axis has an aspect ratio that is set 'equal'. It has been >> discussed on the list before (mostly with Erik Firing), but it >> hasn't been fixed yet. What I want to do is have two plots. The >> top plot has an aspect ratio that is 'equal'. The idea is to >> have a contour plot in the top figure, while the bottom figure >> gives a cross-sectional picture of what I am plotting. This used >> to work well (quite some time ago), including zooming and such. >> But now I cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, >> it changes the limits on the original x-axis. That seems to be a >> bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from >> 0 to 1. >> >> After all, the new subplot shares the axis with the existing >> subplot, so why doesn't it copy the axis limits from that subplot? >> >> >> I may have the fix for this, but I need more time to check and >> refine it--and try to make sure that I don't break anything else in >> the process. >> >> >> >> But the bigger problem occurs when I want the aspect ratio of >> one of the first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> >> The second subplot is added, but the length of the graph is not >> the same as for the first subplot. It also resets the xlimits to >> go from 0 to 1, as before, which means the first subplot becomes >> unreadable (it still enforces 'equal' in the first subplot by >> changing the limits of the y-axis). When I now change the limits >> on the x-axis, the aspect ratio is not equal anymore >> >> >> I will see what I can do. There are definitely some bugs that need >> to be squashed. >> >> Eric >> >> >> ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > 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 |
|
From: David T. <dav...@gm...> - 2008-10-24 07:56:57
Attachments:
shared_yaxes_problem.py
|
Thank you very much Eric !
It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:
File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'
Hope it could help.
David
Eric Firing a écrit :
> David Trem wrote:
>> Hi,
>>
>> Eric, I will be happy to test your possible fix too. I have similar
>> problem with autoscaling shared axes like you Mark.
>>
>> David
>
> I have committed to svn some changes to support autoscaling with shared
> axes, so please test. I have done only very simple and cursory
> checking. You might try reversed axes, log axes, etc.
>
> I have not yet addressed the aspect ratio part of Mark's original post,
> below, but I think my changes have fixed the first of the two problems,
> in addition to adding autoscaling support, which I don't think we ever
> had before.
>
> At present, autoscaling does not work with shared axes if an aspect
> ratio is specified.
>
> Eric
>
>>
>> Mark Bakker a écrit :
>>> Thanks Eric.
>>>
>>> You know that this has been on my wish list for a long time.
>>>
>>> Let me know if I can test anything or help in any other way,
>>>
>>> Mark
>>>
>>> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha...
>>> <mailto:ef...@ha...>> wrote:
>>>
>>> Mark Bakker wrote:
>>>
>>> Hello list (especially Erik, who can fix this I hope) -
>>>
>>> I have had problems with shared axes, especially when one of the
>>> axis has an aspect ratio that is set 'equal'. It has been
>>> discussed on the list before (mostly with Erik Firing), but it
>>> hasn't been fixed yet. What I want to do is have two plots. The
>>> top plot has an aspect ratio that is 'equal'. The idea is to
>>> have a contour plot in the top figure, while the bottom figure
>>> gives a cross-sectional picture of what I am plotting. This used
>>> to work well (quite some time ago), including zooming and such.
>>> But now I cannot plot it at all, let alone zoom.
>>>
>>> My first problem is when I add a subplot with a shared x-axis,
>>> it changes the limits on the original x-axis. That seems to be a
>>> bug:
>>> ax1 = subplot(211)
>>> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
>>> subplot(212,sharex=ax1) # Now the limits of both x-axis go from
>>> 0 to 1.
>>>
>>> After all, the new subplot shares the axis with the existing
>>> subplot, so why doesn't it copy the axis limits from that
>>> subplot?
>>>
>>>
>>> I may have the fix for this, but I need more time to check and
>>> refine it--and try to make sure that I don't break anything else in
>>> the process.
>>>
>>>
>>>
>>> But the bigger problem occurs when I want the aspect ratio of
>>> one of the first axis to be 'equal'.
>>>
>>> ax1 = subplot(211,aspect='equal')
>>> plot([1,2,3]) subplot(212,sharex=ax1)
>>>
>>> The second subplot is added, but the length of the graph is not
>>> the same as for the first subplot. It also resets the xlimits to
>>> go from 0 to 1, as before, which means the first subplot becomes
>>> unreadable (it still enforces 'equal' in the first subplot by
>>> changing the limits of the y-axis). When I now change the limits
>>> on the x-axis, the aspect ratio is not equal anymore
>>>
>>>
>>> I will see what I can do. There are definitely some bugs that need
>>> to be squashed.
>>>
>>> Eric
>>>
>>>
>>> ax1.set_xlim(0,2)
>>> draw()
>>>
>>> Thanks for your help. I am willing to help in testing any
>>> changes.
>>>
>>> Best regards, Mark
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>>
>>> 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
>>
>>
>> -------------------------------------------------------------------------
>> 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
>
|
|
From: Eric F. <ef...@ha...> - 2008-10-24 06:57:52
|
Mark Bakker wrote: > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the axis > has an aspect ratio that is set 'equal'. It has been discussed on the > list before (mostly with Erik Firing), but it hasn't been fixed yet. > What I want to do is have two plots. The top plot has an aspect ratio > that is 'equal'. The idea is to have a contour plot in the top figure, > while the bottom figure gives a cross-sectional picture of what I am > plotting. This used to work well (quite some time ago), including > zooming and such. But now I cannot plot it at all, let alone zoom. > > My first problem is when I add a subplot with a shared x-axis, it > changes the limits on the original x-axis. That seems to be a bug: > ax1 = subplot(211) > plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. > subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. > > After all, the new subplot shares the axis with the existing subplot, so > why doesn't it copy the axis limits from that subplot? > > But the bigger problem occurs when I want the aspect ratio of one of the > first axis to be 'equal'. > > ax1 = subplot(211,aspect='equal') > plot([1,2,3]) > subplot(212,sharex=ax1) Mark, I made some more changes so that the above works by changing the adjustable to 'datalim'. Have I broken anything? Does this work for your applications? Eric > > The second subplot is added, but the length of the graph is not the same > as for the first subplot. It also resets the xlimits to go from 0 to 1, > as before, which means the first subplot becomes unreadable (it still > enforces 'equal' in the first subplot by changing the limits of the > y-axis). When I now change the limits on the x-axis, the aspect ratio is > not equal anymore > > ax1.set_xlim(0,2) > draw() > > Thanks for your help. I am willing to help in testing any changes. > > Best regards, Mark > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 |
|
From: Mark B. <ma...@gm...> - 2008-10-27 14:27:25
|
I was gone for the weekend (sorry, but that 'life' thing gets in the way of getting things done sometimes). I don't have a way to build stuff at the moment. Can I just check out the axes.py and replace my current one, or are there too many changes? Mark On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <ef...@ha...> wrote: > Mark Bakker wrote: > >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the axis has >> an aspect ratio that is set 'equal'. It has been discussed on the list >> before (mostly with Erik Firing), but it hasn't been fixed yet. What I want >> to do is have two plots. The top plot has an aspect ratio that is 'equal'. >> The idea is to have a contour plot in the top figure, while the bottom >> figure gives a cross-sectional picture of what I am plotting. This used to >> work well (quite some time ago), including zooming and such. But now I >> cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, it changes >> the limits on the original x-axis. That seems to be a bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. >> >> After all, the new subplot shares the axis with the existing subplot, so >> why doesn't it copy the axis limits from that subplot? >> >> But the bigger problem occurs when I want the aspect ratio of one of the >> first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> > > Mark, > > I made some more changes so that the above works by changing the adjustable > to 'datalim'. Have I broken anything? Does this work for your > applications? > > Eric > > >> The second subplot is added, but the length of the graph is not the same >> as for the first subplot. It also resets the xlimits to go from 0 to 1, as >> before, which means the first subplot becomes unreadable (it still enforces >> 'equal' in the first subplot by changing the limits of the y-axis). When I >> now change the limits on the x-axis, the aspect ratio is not equal anymore >> >> ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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 >> > > |
|
From: Eric F. <ef...@ha...> - 2008-10-27 18:29:23
|
Mark Bakker wrote: > I was gone for the weekend (sorry, but that 'life' thing gets in the way > of getting things done sometimes). I don't have a way to build stuff at > the moment. Can I just check out the axes.py and replace my current one, > or are there too many changes? The changes were in ticker.py and axes.py. Whether plugging in the current versions would work depends on the age of the other files you have. If you have a fairly recent svn build, then updating those two files probably would work. You could use svn to get the diffs specifically for my changes related to shared axes. Eric > > Mark > > On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > Mark Bakker wrote: > > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the > axis has an aspect ratio that is set 'equal'. It has been > discussed on the list before (mostly with Erik Firing), but it > hasn't been fixed yet. What I want to do is have two plots. The > top plot has an aspect ratio that is 'equal'. The idea is to > have a contour plot in the top figure, while the bottom figure > gives a cross-sectional picture of what I am plotting. This used > to work well (quite some time ago), including zooming and such. > But now I cannot plot it at all, let alone zoom. > > My first problem is when I add a subplot with a shared x-axis, > it changes the limits on the original x-axis. That seems to be a > bug: > ax1 = subplot(211) > plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. > subplot(212,sharex=ax1) # Now the limits of both x-axis go from > 0 to 1. > > After all, the new subplot shares the axis with the existing > subplot, so why doesn't it copy the axis limits from that subplot? > > But the bigger problem occurs when I want the aspect ratio of > one of the first axis to be 'equal'. > > ax1 = subplot(211,aspect='equal') > plot([1,2,3]) subplot(212,sharex=ax1) > > > Mark, > > I made some more changes so that the above works by changing the > adjustable to 'datalim'. Have I broken anything? Does this work > for your applications? > > Eric > > > The second subplot is added, but the length of the graph is not > the same as for the first subplot. It also resets the xlimits to > go from 0 to 1, as before, which means the first subplot becomes > unreadable (it still enforces 'equal' in the first subplot by > changing the limits of the y-axis). When I now change the limits > on the x-axis, the aspect ratio is not equal anymore > > ax1.set_xlim(0,2) > draw() > > Thanks for your help. I am willing to help in testing any changes. > > Best regards, Mark > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > |
|
From: Mark B. <ma...@gm...> - 2008-10-27 20:28:11
|
Dang, I looked at it, but so much has changed since 0.98.3 release that I have little chance of getting any changes implemented. Any plans for a new release that you know of? Thanks, Mark On Mon, Oct 27, 2008 at 7:29 PM, Eric Firing <ef...@ha...> wrote: > Mark Bakker wrote: > >> I was gone for the weekend (sorry, but that 'life' thing gets in the way >> of getting things done sometimes). I don't have a way to build stuff at the >> moment. Can I just check out the axes.py and replace my current one, or are >> there too many changes? >> > > The changes were in ticker.py and axes.py. Whether plugging in the current > versions would work depends on the age of the other files you have. If you > have a fairly recent svn build, then updating those two files probably would > work. You could use svn to get the diffs specifically for my changes > related to shared axes. > > Eric > > >> Mark >> >> >> On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <ef...@ha... <mailto: >> ef...@ha...>> wrote: >> >> Mark Bakker wrote: >> >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the >> axis has an aspect ratio that is set 'equal'. It has been >> discussed on the list before (mostly with Erik Firing), but it >> hasn't been fixed yet. What I want to do is have two plots. The >> top plot has an aspect ratio that is 'equal'. The idea is to >> have a contour plot in the top figure, while the bottom figure >> gives a cross-sectional picture of what I am plotting. This used >> to work well (quite some time ago), including zooming and such. >> But now I cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, >> it changes the limits on the original x-axis. That seems to be a >> bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from >> 0 to 1. >> >> After all, the new subplot shares the axis with the existing >> subplot, so why doesn't it copy the axis limits from that subplot? >> >> But the bigger problem occurs when I want the aspect ratio of >> one of the first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> >> >> Mark, >> >> I made some more changes so that the above works by changing the >> adjustable to 'datalim'. Have I broken anything? Does this work >> for your applications? >> >> Eric >> >> >> The second subplot is added, but the length of the graph is not >> the same as for the first subplot. It also resets the xlimits to >> go from 0 to 1, as before, which means the first subplot becomes >> unreadable (it still enforces 'equal' in the first subplot by >> changing the limits of the y-axis). When I now change the limits >> on the x-axis, the aspect ratio is not equal anymore >> >> ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------- >> 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=/ >> <http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> <mailto:Mat...@li...> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> > |
|
From: Eric F. <ef...@ha...> - 2008-10-27 21:10:11
|
Mark Bakker wrote: > Dang, I looked at it, but so much has changed since 0.98.3 release that > I have little chance of getting any changes implemented. > Any plans for a new release that you know of? > Thanks, Mark None that I know of. It would certainly be nice if we had the release package-building completely automated; or automated daily svn builds of the Win and OSX packages. Since I don't work with either Win or OSX, I don't know how hard this would be to set up. Eric |
|
From: John H. <jd...@gm...> - 2008-10-28 00:27:37
|
On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> wrote: > None that I know of. It would certainly be nice if we had the release > package-building completely automated; or automated daily svn builds of the > Win and OSX packages. Since I don't work with either Win or OSX, I don't > know how hard this would be to set up. Nightly builds would be excellent -- Charlie, to what extent do you think this is feasible from a scripting perspective? Ie, ignoring the hardware side for a minute, and assuming we had access to a build farm with OS X and win32, how hard would it be to setup a build bot for nightly builds? JDH |
|
From: Michael D. <md...@st...> - 2008-10-28 13:53:53
|
This may not be necessary if we can get a Windows box, but I thought I'd mention it. I wrote a distutils extension a couple of years ago to build Windows installers on a Linux box with Mingw32. This has been working perfectly for nightly builds on my home machine since around September 2007 for a project with much the same build requirements as matplotlib. It's really easy to install Mingw32 on Debian derivatives (maybe other dists as well.) See here: http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup Mike John Hunter wrote: > On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> wrote: > > >> None that I know of. It would certainly be nice if we had the release >> package-building completely automated; or automated daily svn builds of the >> Win and OSX packages. Since I don't work with either Win or OSX, I don't >> know how hard this would be to set up. >> > > Nightly builds would be excellent -- Charlie, to what extent do you > think this is feasible from a scripting perspective? Ie, ignoring the > hardware side for a minute, and assuming we had access to a build farm > with OS X and win32, how hard would it be to setup a build bot for > nightly builds? > > JDH > > ------------------------------------------------------------------------- > 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 > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Eric F. <ef...@ha...> - 2008-10-24 17:42:53
|
David Trem wrote: > Thank you very much Eric ! > > It basically works for me but I think there is still a small bug > related to sharing y axes. I attach a small script that reproduce the > problem. > The end of the related error message is the following: > > File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in > __init__ > if sharex._adjustable == 'box': > AttributeError: 'NoneType' object has no attribute '_adjustable' > > Hope it could help. It certainly does, thank you. In a cut'n'paste operation, I had neglected to change a couple of 'x's to 'y's. Fixed in svn. Thanks again, and keep testing! Eric |
|
From: David T. <dav...@gm...> - 2008-10-25 04:48:28
|
Thanks Eric, It works perfectly for me now! Actually, autoscale of shared axes simplify a lot my own code so I'm really really pleased to see this functionality is now directly integrated in matplotlib. I'll do me best to test the svn version regularly. Thanks again, David Eric Firing a écrit : > David Trem wrote: >> Thank you very much Eric ! >> >> It basically works for me but I think there is still a small bug >> related to sharing y axes. I attach a small script that reproduce the >> problem. >> The end of the related error message is the following: >> >> File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in >> __init__ >> if sharex._adjustable == 'box': >> AttributeError: 'NoneType' object has no attribute '_adjustable' >> >> Hope it could help. > > It certainly does, thank you. In a cut'n'paste operation, I had > neglected to change a couple of 'x's to 'y's. Fixed in svn. > > Thanks again, and keep testing! > > Eric |
|
From: Eric F. <ef...@ha...> - 2008-10-28 17:58:26
|
Michael Droettboom wrote: > This may not be necessary if we can get a Windows box, but I thought I'd > mention it. > > I wrote a distutils extension a couple of years ago to build Windows > installers on a Linux box with Mingw32. This has been working perfectly > for nightly builds on my home machine since around September 2007 for a > project with much the same build requirements as matplotlib. It's > really easy to install Mingw32 on Debian derivatives (maybe other dists > as well.) Mike, Thank you! I had no idea that mingw32 was available as an ubuntu package, for example, and never would have thought to look for it. Now I will have to try it out. Do you know if there is an scons builder that uses it? That might be the sticking point for my non-mpl C code, which is now all built with scons. I think that if your distutils extension works for building mpl for Win on a Linux box, then we should use it. Anything that reduces dependence o having an actual Windows machine around is a win. On second thought, there is one disadvantage: an automated build on a Win box could also run an automated test. I have some dim impression of having seen a caution regarding compatibility between mingw extensions and present or future official python.org Python builds. Does this ring any bells? Eric > > See here: > > http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup > > > Mike > > John Hunter wrote: >> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> wrote: >> >> >>> None that I know of. It would certainly be nice if we had the release >>> package-building completely automated; or automated daily svn builds >>> of the >>> Win and OSX packages. Since I don't work with either Win or OSX, I don't >>> know how hard this would be to set up. >>> >> >> Nightly builds would be excellent -- Charlie, to what extent do you >> think this is feasible from a scripting perspective? Ie, ignoring the >> hardware side for a minute, and assuming we had access to a build farm >> with OS X and win32, how hard would it be to setup a build bot for >> nightly builds? >> >> JDH >> >> ------------------------------------------------------------------------- >> 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 >> > |
|
From: Michael D. <md...@st...> - 2008-10-28 18:24:31
|
Eric Firing wrote: > Michael Droettboom wrote: >> This may not be necessary if we can get a Windows box, but I thought >> I'd mention it. >> >> I wrote a distutils extension a couple of years ago to build Windows >> installers on a Linux box with Mingw32. This has been working >> perfectly for nightly builds on my home machine since around >> September 2007 for a project with much the same build requirements as >> matplotlib. It's really easy to install Mingw32 on Debian >> derivatives (maybe other dists as well.) > > Mike, > > Thank you! I had no idea that mingw32 was available as an ubuntu > package, for example, and never would have thought to look for it. > Now I will have to try it out. Do you know if there is an scons > builder that uses it? That might be the sticking point for my non-mpl > C code, which is now all built with scons. No idea. Haven't spent much time with scons myself. > > I think that if your distutils extension works for building mpl for > Win on a Linux box, then we should use it. Anything that reduces > dependence o having an actual Windows machine around is a win. > > On second thought, there is one disadvantage: an automated build on a > Win box could also run an automated test. True. But there is always wine -- though I fear my head would start to spin. I'll admit that the advantages of cross-compiling can quickly be outweighed by the complexity of debugging and testing. > > I have some dim impression of having seen a caution regarding > compatibility between mingw extensions and present or future official > python.org Python builds. Does this ring any bells? It does. I haven't had problems up to Py2.5 -- but I don't know what's coming in that respect, and I don't closely follow Python-on-Windows development. Mike > > Eric > >> >> See here: >> >> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup >> >> >> Mike >> >> John Hunter wrote: >>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> >>> wrote: >>> >>> >>>> None that I know of. It would certainly be nice if we had the release >>>> package-building completely automated; or automated daily svn >>>> builds of the >>>> Win and OSX packages. Since I don't work with either Win or OSX, I >>>> don't >>>> know how hard this would be to set up. >>>> >>> >>> Nightly builds would be excellent -- Charlie, to what extent do you >>> think this is feasible from a scripting perspective? Ie, ignoring the >>> hardware side for a minute, and assuming we had access to a build farm >>> with OS X and win32, how hard would it be to setup a build bot for >>> nightly builds? >>> >>> JDH >>> >>> ------------------------------------------------------------------------- >>> >>> 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 >>> >> > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X