matplotlib-users Mailing List for matplotlib

John Hunter wrote:

>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>>            
>>>>>>
>
>    Peter> Yes, thanks.  Just one more question. Recently (in the last
>    Peter> couple of versions I think), there has been a change and
>    Peter> now the 'o' line markers (circles) are filled in by
>    Peter> default.  For example:
>
>    Peter>     plot(xp,yp,'ok')
>
>    Peter> gives sold black circles.
>
>Just do
>
> >>> plot(x, y, 'ok', markerfacecolor=None)
>
>  
>
Aghh.. yes. Thanks.

>This raises the question of what the default behavior of plot should
>be.  If you say
>
> >>> plot(x, y, 'ro')
>
>should the red apply to the facecolor, edgecolor, or both? 
>
I think both is good. It seems like it's really easy to change in any case.

>I could add some aliases like mfc=markerfacecolor, ec=edgecolor,
>lw=linewidth if people often find themselves overriding the defaults
>and think these are useful shortcuts. 
>
Might be a good idea.

On another note, interesting to see how much matplotlib has matured in 
the last six months. Great job John!

Peter

>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:

    Vineet> That's fine. I'll start using
    Vineet> ax.viewLim.intervaly().get_bounds() # the y limits

    Vineet> to get the y limits.

Hi Vineet,

This is not recommended.  I pointed you to limit attributes these so
you can compare what is happening with the data and view limits
separately, and to give you some insight into how to poke around if
you need to.  There is no reason for you to call
ax.viewLim.intervaly().get_bounds() since this is what get_ylim calls
anyway.  The set_ylim and get_ylim functions are fixed as part of the
matlab API; The viewLim and dataLim attributes are not.  When
possible, stick with the documented API, so your code will be
compatible with future matplotlib releases.

    Vineet> In any case though, the order in which the plot functions
    Vineet> are called should not change the value returned by
    Vineet> self.axMiddle.get_ylim. I think that is a bug.

There may be a bug, but let's be clear to find out.  Here is what is
happening.

Every time you issue a plot command, the ax.dataLim are updated.
These should exactly bound the min and max of the x and y range of
your data.  After that, ax.autoscale_view is called.  This updates the
min and max of the x and y *view* limits, which should include, but
may exceed, the datalim.  Exactly how this view limit update is done
depends on the tick locator you have chosen.  The default locator is
matplotlib.ticker.AutoLocator, but you can customize this.

if you issue repeated plot commands

    ax.plot(something)
    ax.plot(something_else)
    ax.plot(still_mode)
    print 'datalim', ax.dataLim.intervaly().get_bounds()     
    print 'viewlim', ax.get_ylim()  

neither the viewlim nor the datalim after all plot commands have been
issued should not be affected by the order of the plot commands.  Of
course, you need to apply the patch I posted in my previous email (to
the has_data function) because there was a bug.  

The viewlim *will* be changed after each plot command, and will depend
on the order, as in

    ax.plot(something)
    print 'viewlim', ax.get_ylim()  
    ax.plot(something_else)
    print 'viewlim', ax.get_ylim()  
    ax.plot(still_mode)
    print 'viewlim', ax.get_ylim()  

but again, the final viewlim should be order independent.  Is this
what you observe?

If the plot order does affect the final limits, let me know.  If the
viewlim differs from the data lim, that is unsurprising, as that is by
design.  If you are unhappy with the way to the autolocator is
choosing the view limits, you have a couple of choices: 1) let me know
by giving me the requisite datalim and viewlim boundaries, what is
happening, and what you think should be happening and I'll look in to
fixing it or 2) use a custom locator that autoscales the view limits
in the way you want.

JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:

    Peter> Yes, thanks.  Just one more question. Recently (in the last
    Peter> couple of versions I think), there has been a change and
    Peter> now the 'o' line markers (circles) are filled in by
    Peter> default.  For example:

    Peter>     plot(xp,yp,'ok')

    Peter> gives sold black circles.

Just do

 >>> plot(x, y, 'ok', markerfacecolor=None)

This raises the question of what the default behavior of plot should
be.  If you say

 >>> plot(x, y, 'ro')

should the red apply to the facecolor, edgecolor, or both?  Both is
the current behavior, which I think is in accord with the principal of
least surprise.  If it should apply to only one, say the edge color,
the facecolor would fall back on lines.markerfacecolor.

I could add some aliases like mfc=markerfacecolor, ec=edgecolor,
lw=linewidth if people often find themselves overriding the defaults
and think these are useful shortcuts.  I've already added these to the
rc command, and adding them to the lines/patches classed would be
easy.


JDH

That's fine. I'll start using

	  ax.viewLim.intervaly().get_bounds()  # the y limits

to get the y limits.

In any case though, the order in which the plot functions are called should
not change the value returned by self.axMiddle.get_ylim. I think that is a
bug.

VJ


-----Original Message-----
From: mat...@li...
[mailto:mat...@li...]On Behalf Of John
Hunter
Sent: Monday, August 02, 2004 10:56 AM
To: Vineet Jain
Cc: matplotlib-users
Subject: Re: [Matplotlib-users] Settling y-axis scaling


>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:

    Vineet> After making changes to has_data I get the following:
    Vineet> (0.0, 400.0) (0.0, 400.0) (0.0, 400.0)

    Vineet> which is not correct it should be:

    Vineet> (300.0, 400.0) (100.0, 400.0) (100.0, 400.0)

I'm not sure this is incorrect.  matplotlib distinguishes between the
data limits and the view limits.  The latter are automatically
adjusted to include the data limits but may incorporate more.  For
example, the x data limits in [0.1, 10] may produce view limits
[0,10].

If you need the view limits to always equal the data limits, you could
provide a custom ticker, as described in
http://matplotlib.sourceforge.net/matplotlib.ticker.html and
illustrated in the example
http://matplotlib.sourceforge.net/examples/custom_ticker1.py.

You might want to verify that the data limits are correct by printing

  ax.dataLim.intervalx().get_bounds()  # the x limits
  ax.dataLim.intervaly().get_bounds()  # the y limits

where ax is your Axes instance.  You can compare these with

  ax.viewLim.intervalx().get_bounds()  # the x limits
  ax.viewLim.intervaly().get_bounds()  # the y limits

JDH


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users