matplotlib-devel Mailing List for matplotlib

Thanks a lot Andrew. This looks great.
I'm just reporting some of issues I encountered in a hope that you can
address these (I'll also take a look if have chance).
 * cla() does not reset spines (positions, color, etc). I think it is
better to be reset, since all other things are. For example, cla()
resets visibility of ticks, etc.
* better support for log scale.
ax = subplot(131)
ax.spines["bottom"].set_position("center")
ax.semilogx()
# this works
ax = subplot(132)
ax.semilogx()
ax.spines["bottom"].set_position("center")
# this does NOT
ax = subplot(133)
ax.spines["bottom"].set_position(("data", 1))
ax.loglog()
# this does NOT work regardless the position of loglog.
▶◀
-JJ
On Wed, May 27, 2009 at 12:33 PM, Andrew Straw <str...@as...> wrote:
> I've gone ahead and committed my arbitrary spine location implementation
> to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
> To get you started, try the new demo:
> examples/pylab_examples/spine_placement_demo.py
>
> I believe I addressed all the issues raised with the patch I emailed the
> list last week and I tried to avoid any breakage. Thanks to all who
> commented -- you made this a better implementation.
>
> Note that Axes.frame no longer exists, and I made a note of this in
> api_changes.rst and a hopefully carefully worded AttributeError will be
> raised if you try to access it.
>
> Also, as excercised by the demo, in addition to support for a offset of
> spines specified in points, one may specify spine placement in both axes
> and data coordinates. Here is the docstring for Spine.set_position:
>
> """
> set the position of the spine
>
> Spine position is specified by a 2 tuple of (position type,
> amount). The position types are:
>
> * 'outward' : place the spine out from the data area by the
> specified number of points. (Negative values specify placing the
> spine inward.)
>
> * 'axes' : place the spine at the specified Axes coordinate (from
> 0.0-1.0).
>
> * 'data' : place the spine at the specified data coordinate.
>
> Additionally, shorthand notations define a special positions:
>
> * 'center' -> ('axes',0.5)
> * 'zero' -> ('data', 0.0)
> """
>
> As always, please let me know of any suggestions or comments.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, May 27, 2009 at 12:53 PM, Eric Firing <ef...@ha...> wrote:
> No problem--it can be done later, no rush. Your replacement of the
> frame with spines is a *big* improvement. Thank you for the great work.
Yes, this looks great -- thanks again Andrew.
Something that would be nice would be a Formatter that is aware of the
spines which would drop the label in the places near the spine
intersection (eg the zeros in the centered example). Nothing obvious
comes to mind, but I just wanted to throw it out there in case someone
wants to dig in.
JDH

A review of a book primarily on matplotlib, numpy and scipy has hit the 
front page of Slashdot.
http://books.slashdot.org/article.pl?sid=09/05/27/1327255&from=rss
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Andrew Straw wrote:
> Andrew Straw wrote:
>> I believe I addressed all the issues raised with the patch I emailed the
>> list last week and I tried to avoid any breakage. Thanks to all who
>> commented -- you made this a better implementation.
> 
> Upon further reflection, I realize I didn't add any Axes convenience 
> methods as Eric suggested. This is simply due to a lack of time -- not a 
> lack of enthusiasm.
Andrew,
No problem--it can be done later, no rush. Your replacement of the 
frame with spines is a *big* improvement. Thank you for the great work.
Eric

Andrew Straw wrote:
> I believe I addressed all the issues raised with the patch I emailed the
> list last week and I tried to avoid any breakage. Thanks to all who
> commented -- you made this a better implementation.
Upon further reflection, I realize I didn't add any Axes convenience 
methods as Eric suggested. This is simply due to a lack of time -- not a 
lack of enthusiasm.
-Andrew

I've gone ahead and committed my arbitrary spine location implementation
to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
To get you started, try the new demo:
examples/pylab_examples/spine_placement_demo.py
I believe I addressed all the issues raised with the patch I emailed the
list last week and I tried to avoid any breakage. Thanks to all who
commented -- you made this a better implementation.
Note that Axes.frame no longer exists, and I made a note of this in
api_changes.rst and a hopefully carefully worded AttributeError will be
raised if you try to access it.
Also, as excercised by the demo, in addition to support for a offset of
spines specified in points, one may specify spine placement in both axes
and data coordinates. Here is the docstring for Spine.set_position:
"""
set the position of the spine
Spine position is specified by a 2 tuple of (position type,
amount). The position types are:
* 'outward' : place the spine out from the data area by the
 specified number of points. (Negative values specify placing the
 spine inward.)
* 'axes' : place the spine at the specified Axes coordinate (from
 0.0-1.0).
* 'data' : place the spine at the specified data coordinate.
Additionally, shorthand notations define a special positions:
* 'center' -> ('axes',0.5)
* 'zero' -> ('data', 0.0)
"""
As always, please let me know of any suggestions or comments.
-Andrew