matplotlib-users Mailing List for matplotlib (Page 1419)

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:

    Stephen> However, in either case, the bars' left edge is at the x
    Stephen> coordinate rather than being centered on it.  I know this
    Stephen> is the documented behavior, but Matlab centers the bars
    Stephen> on the given X coordinates.  How do people feel about
    Stephen> changing matplotlib to match the Matlab behavior?  I've
    Stephen> changed my copy locally.

Hi Stephen,
I'd be happy with this change.  I CCd Gary Ruben who has done a lot of
work on the bar function because he'll likely have an opinion.

If you could send me your code, I'll look into merging it if all
agree this is the desired behavior.

JDH

Personally, I agree with Stephen that "center the bar on the given x value" is 
more user friendly.

JC Hsu

On Thu, 2004-08-05 at 10:00, John Hunter wrote:
> >>>>> "Jin-chung" =3D=3D Jin-chung Hsu <hs...@st...> writes:
>=20
>     Jin-chung> When I do the bar(left, height) in matlab the first
>     Jin-chung> time, e.g.:
>     >>>> bar([4,5,6,7,8],[9,8,7,6,5])
>=20

> This was a bug in the way I update the datalim in axes.py, which is
> currently a bit too fragile for my tastes.  Below I'll include the
> modified matplotlib.axes.Axes.bar function.  Let me know if it passes
> all your tests...

I was interested in this report, and sorry if I butted in.  John's patch
fixes Jin-chung's problem with poor x-axis scaling here.  I'm using CVS,
not 0.60.2, and didn't see the "funny Y tick labels" he reported.

However, in either case, the bars' left edge is at the x coordinate
rather than being centered on it.  I know this is the documented
behavior, but Matlab centers the bars on the given X coordinates.  How
do people feel about changing matplotlib to match the Matlab behavior?=20
I've changed my copy locally.

--=20
Stephen Walton <ste...@cs...>
Dept. of Physics & Astronomy, Cal State Northridge

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:

    Jin-chung> When I do the bar(left, height) in matlab the first
    Jin-chung> time, e.g.:
    >>>> bar([4,5,6,7,8],[9,8,7,6,5])

Hi, thanks for the report.

This was a bug in the way I update the datalim in axes.py, which is
currently a bit too fragile for my tastes.  Below I'll include the
modified matplotlib.axes.Axes.bar function.  Let me know if it passes
all your tests...

Cheers,
JDH

    def bar(self, left, height, width=0.8, bottom=0,
            color='b', yerr=None, xerr=None, ecolor='k', capsize=3
            ):
        """
        BAR(left, height)
        
        Make a bar plot with rectangles at
          left, left+width, 0, height
        left and height are Numeric arrays

        Return value is a list of Rectangle patch instances

        BAR(left, height, width, bottom,
            color, yerr, xerr, capsize, yoff)

        xerr and yerr, if not None, will be used to generate errorbars
        on the bar chart

        color specifies the color of the bar
        ecolor specifies the color of any errorbar

        capsize determines the length in points of the error bar caps

        
        The optional arguments color, width and bottom can be either
        scalars or len(x) sequences

        This enables you to use bar as the basis for stacked bar
        charts, or candlestick plots
        """
        if not self._hold: self.cla()
        
        left = asarray(left)
        height = asarray(height)

        patches = []


        # if color looks like a color string, and RGB tuple or a
        # scalar, then repeat it by len(x)
        if (is_string_like(color) or
            (iterable(color) and len(color)==3 and len(left)!=3) or
            not iterable(color)):
            color = [color]*len(left)


        if not iterable(bottom):
            bottom = array([bottom]*len(left), Float)
        else:
            bottom = asarray(bottom)
        if not iterable(width):
            width = array([width]*len(left), Float)
        else:
            width = asarray(width)

        N = len(left)
        assert len(bottom)==N, 'bar arg bottom must be len(left)'
        assert len(width)==N, 'bar arg width must be len(left) or scalar'
        assert len(height)==N, 'bar arg height must be len(left) or scalar'
        assert len(color)==N, 'bar arg color must be len(left) or scalar'

        right = left + width
        top = bottom + height
        

        args = zip(left, bottom, width, height, color)
        for l, b, w, h, c in args:            
            if h<0:
                b += h
                h = abs(h)
            r = Rectangle(
                xy=(l, b), width=w, height=h,
                facecolor=c,
                )
            self.add_patch(r)
            patches.append(r)
 

        if xerr is not None or yerr is not None:
            self.errorbar(
                left+0.5*width, bottom+height,
                yerr=yerr, xerr=xerr,
                fmt=None, ecolor=ecolor, capsize=capsize)
        self.autoscale_view()
        return patches

When I do the bar(left, height) in matlab the first time, e.g.:

>>> bar([4,5,6,7,8],[9,8,7,6,5])

the plot does not have the "full" range : X starts at 4.5 (should be 4) and Y 
starts at 5 (shouldbe 0).  But if I reissue the same command without erasing the 
plot, the plot range is fine, but the Y tick labels are funny (3 and 9 seem to 
be at 2.5 and 8.5).

I also notice that if I use yerr:

>>> bar([4,5,6,7,8],[9,8,7,6,5],yerr=[1,.5,.5,.9,1])

The plot is fine the first time, both the range and the tick labels.

I am using matplotlib 0.60.1 on Solaris.

JC Hsu

Hi John:

DayMulitLocator is missing from the following line:

from ticker import YearLocator, MonthLocator, WeekdayLocator, \
     DayLocator, HourLocator, MinuteLocator, DateFormatter

in axes.py


-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

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

> .....
> But you can also create your own color maps at any time using the
> cm.get_cmap function
>
> >>> jet512 = cm.get_cmap('jet', 512)
> >> imshow(X, cmap=jet512)
>
> Should work.
>
Yes, thanks.
Just one more question. Recently (in the last couple of versions I 
think), there has been a change and now the 'o' line markers (circles) 
are filled in by default.
For example:

    plot(xp,yp,'ok')

gives sold black circles.

I would like my circles to not be filled; just have the border so that 
the inside is transparent.
Is this something that is settable?

Thanks,

-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

>>>>> "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

>>>>> "Kenneth" == Kenneth McDonald <ken...@sb...> writes:

    Kenneth> Does any exist? I looked through the distribution and
    Kenneth> didn't see anything, but then, that doesn't prove
    Kenneth> anything :-)

There is no official documentation, but there are a few resources

  * The class documentation at
    http://matplotlib.sourceforge.net/classdocs.html

  * the examples embedding_in*.py in the examples directory.

  * examples/pythonic_matplotlib.py describes the translation from the
    matlab style interface to the pythonic, OO interface

  * Another good resource is matlab.py.  This is just a thin wrapper
    to the API, so you can look and see how it is done there,
    translating all the gcf() calls to your figure instance, all the
    gca() calls to your axes instance, and so on.

Other than that, you can post here...

I'm working on some additional documentation but it is not ready yet.

JDH

>>>>> "Mathias" == Mathias Franzius <mat...@we...> writes:

    Mathias> Dear NG, I have a problem mwith the installation of
    Mathias> matplotlib under redhat 9 and python 2.3.2. I first
    Mathias> updated all relevant packages (see [1]).  Building
    Mathias> matplotlib with default setup.py seemd to be ok, except
    Mathias> two types of warnings (see [2]). Install showed no errors
    Mathias> as well.  When importing matplotlib I get the following
    Mathias> error:

The warnings you posted are completely harmless.  

    Mathias> What could be the problem?  The directory
    Mathias> /usr/lib/python2.3/site-packages/matplotlib/ contains
    Mathias> transforms.py and _transforms.so but no _transforms.py -
    Mathias> is that ok?

Yes, this is OK.  There is no _transforms.py

My guess is you are trying to run matplotlib from the build dir.  You
cannot do this, because python finds the matplotlib src dir named
matplotlib and tries to load that.  There is no _transforms module in
that dir, but there is in site-packages so you should be OK.  cd into
another directory, ie your home dir or the examples dir, and try from
there.

This problem bites a number of users.  Perhaps we should rename the
base matplotlib python dir in the src tree to something like
matplotlibpy.

JDH

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

    Peter> Hi: How many colors do images created via:

    Peter>         imshow(Zi, cmap=cm.jet)

    Peter> (Zi = some data matrix) have?

    Peter> Are these true color? 256? Is there a simple way to define
    Peter> these things?

The following image parameters can be configured from your rc file

### images
image.aspect : free          # free | preserve
image.interpolation  : bilinear  # see help(imshow) for options
image.cmap   : jet           # gray | jet
image.lut    : 256           # the size of the colormap lookup table
image.origin : upper         # lower | upper


The image.lut parameter controls the size of the lookup table.  You
can change the default in the rc file, or dynamically in a single
python session using the rc function.  Eg,

 # default cmap is now 100 level grayscale by cm.jet and cm.gray unaffected
 >>> rc('image', lut=100, cmap='gray')
 >>> imshow(X)  # show X with default cmap


But you can also create your own color maps at any time using the
cm.get_cmap function

  >>> jet512 = cm.get_cmap('jet', 512)
  >> imshow(X, cmap=jet512)

Should work.

JDH

Dear NG,

I have a problem mwith the installation of matplotlib under redhat 9 and 
python 2.3.2. I first updated all relevant packages (see [1]).
Building matplotlib with default setup.py seemd to be ok, except two 
types of warnings (see [2]). Install showed no errors as well.
When importing matplotlib I get the following error:
 >>> from matplotlib import matlab
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "matplotlib/matlab.py", line 142, in ?
     from axes import Axes
   File "matplotlib/axes.py", line 9, in ?
     from artist import Artist
   File "matplotlib/artist.py", line 4, in ?
     from transforms import identity_transform
   File "matplotlib/transforms.py", line 180, in ?
     from _transforms import Value, Point, Bbox, Affine
ImportError: No module named _transforms

What could be the problem?
The directory /usr/lib/python2.3/site-packages/matplotlib/
contains transforms.py and _transforms.so but no _transforms.py - is 
that ok?

Thanks for any help,
    Mathias

--------
[1]: zlib, zlib-devel, libpng, libpng-devel, freetype, freetype-devel, 
freetype-utils, gtk2-devel, gtk+-devel, pygtk2, glib-devel, 
pygtk2-devel, gnome-libs-devel, pygtk2-libglade,
tcl, tk, tkinter

[2]: In file included from /usr/include/python2.3/Python.h:8,
                  from CXX/Objects.hxx:9,
                  from CXX/Extensions.hxx:18,
                  from src/_transforms.h:10,
                  from src/_transforms.cpp:2:
/usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from 
/usr/include/c++/3.2.2/i386-redhat-linux/bits/os_defines.h:39,
                  from 
/usr/include/c++/3.2.2/i386-redhat-linux/bits/c++config.h:34,
                  from /usr/include/c++/3.2.2/functional:53,
                  from src/_transforms.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the 
previous definition

Hi all,

I was attempting to modify the file examples/embedding_in_tk.py so as to 
add a button allowing me to choose and (eventually) open a data file for 
plotting. Binding a function which uses tkFileDialog.askopenfilename() 
to a button was making the application stop with a "Fatal Python Error: 
PyEval_RestoreThread: NULL state", after the function returned.

eg:
Tk.Button(master=root, text="Open", command=lambda : 
sys.stdout.write(tkFileDialog.askopenfilename()).pack()

After you click the button and select the file, then the application 
stops with the complaint about threading as root.destroy has been called 
by the tkFileDialog (presumably on itself)

So is there some reason for the bits of the example?:

def destroy(e) : sys.exit()
[...]
root.bind("<destroy>",destroy)

changing to:

def destroy(e):
   print "root destroy called"
   sys.exit()

confirms the origin of the problem. Is there some reason for the method 
used? Commenting out the offending bind to root might make the example a 
little bit easier for slow thinking people such as myself to modify and 
then get going with...  I realise I might have been going about things 
the wrong way to randomly modify an example I don't fully understand, 
but the graphs looked so nice and tempting...

Perhaps other (scientist) programmers might be able to get going more 
easily if this little trap is removed? The quality and speed of the 
plotting is fantastic, I'm extremely impressed!

Thanks,

Jon

Hi:

How many colors do images created via:

        imshow(Zi, cmap=cm.jet)

(Zi = some data matrix) have?

Are these true color? 256? Is there a simple way to define these things?

Thanks.

-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

Does any exist? I looked through the distribution and didn't see 
anything,
but then, that doesn't prove anything :-)

Thanks,
Ken McDonald

After making changes to has_data I get the following:

(0.0, 400.0)
(0.0, 400.0)
(0.0, 400.0)

which is not correct it should be:

(300.0, 400.0)
(100.0, 400.0)
(100.0, 400.0)

-----Original Message-----
From: mat...@li...
[mailto:mat...@li...]On Behalf Of John
Hunter
Sent: Thursday, July 29, 2004 2:35 PM
To: Vineet Jain
Cc: matplotlib-users
Subject: Re: [Matplotlib-users] Settling y-axis scaling


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

    Vineet> ok I think I've found the problem and a possible solution:

The order of the plots should not make a difference.  Clearly it does
so this is a bug.  Could you try editing matplotlib.axes.Axes.has_data
(on or around line 323 of axes.py) and replace it with

    def has_data(self):
        return (
            len(self._collections) +            
            len(self._images) +
            len(self._lines) +
            len(self._patches))>0

and see if this fixes the problem.  Ie, with this change, order of
plot commands should not affect the final ylim.

Thanks,
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

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

    Vineet> ok I think I've found the problem and a possible solution:

The order of the plots should not make a difference.  Clearly it does
so this is a bug.  Could you try editing matplotlib.axes.Axes.has_data
(on or around line 323 of axes.py) and replace it with

    def has_data(self):
        return (
            len(self._collections) +            
            len(self._images) +
            len(self._lines) +
            len(self._patches))>0

and see if this fixes the problem.  Ie, with this change, order of
plot commands should not affect the final ylim.

Thanks,
JDH

ok I think I've found the problem and a possible solution:

left, width       = 0.1, 0.8
x       = range(100)
closes1 = range(100, 200)
closes2 = range(200, 300)
closes3 = range(300, 400)
f = figure(1, facecolor='w', figsize=(10, 7), dpi=96)
rect2   = [left, 0.1, width, 0.8]
axMiddle = axes(rect2, axisbg='#f6f6f6')
axMiddle.yaxis.tick_left()
plot_day_summary2(axMiddle, closes3, closes3, closes3, closes3)
print axMiddle.get_ylim()
axMiddle.plot(x, closes1, color='r', linewidth=1)
print axMiddle.get_ylim()
axMiddle.plot(x, closes2, color='r', linewidth=1)
print axMiddle.get_ylim()

This code prints which is wrong:

(300.0, 400.0)
(100.0, 200.0)
(100.0, 300.0)

However when I move the plot_day_summary2 to the end like:

left, width       = 0.1, 0.8
x       = range(100)
closes1 = range(100, 200)
closes2 = range(200, 300)
closes3 = range(300, 400)
f = figure(1, facecolor='w', figsize=(10, 7), dpi=96)
rect2   = [left, 0.1, width, 0.8]
axMiddle = axes(rect2, axisbg='#f6f6f6')
axMiddle.yaxis.tick_left()
axMiddle.plot(x, closes1, color='r', linewidth=1)
print axMiddle.get_ylim()
axMiddle.plot(x, closes2, color='r', linewidth=1)
print axMiddle.get_ylim()
plot_day_summary2(axMiddle, closes3, closes3, closes3, closes3)
print axMiddle.get_ylim()

I get the correct value:

(100.0, 200.0)
(100.0, 300.0)
(100.0, 400.0)



-----Original Message-----
From: John Hunter [mailto:jdh...@ac...]
Sent: Thursday, July 29, 2004 11:17 AM
To: Vineet Jain
Subject: Re: [Matplotlib-users] Settling y-axis scaling


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

    Vineet> That does not seem to work (or I'm doing something
    Vineet> wrong). The last call to the function just returns the min
    Vineet> max from the last plot.

Are you trying to get the min and max across several axes?
ax.get_ylim should return the limits for a single axes which
incorporates the data from several 'plot' commands on that axes.  If
you are trying to aggregate across axes, you'll need a different
approach.

If you could post some example code, it would probably help clarify.

JDH

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

    Vineet> Ok Figured out the solution but still have a problem.
    Vineet> There is a function get_ylim which gets you the ymin and
    Vineet> ymax values. I'm plotting multiple lines on the same axes
    Vineet> object. However the get_ylim returns different values
    Vineet> after each plot. I'm currently having to do it a numbe rof
    Vineet> times and reset my min and max values. Is there a way to
    Vineet> just do it once where it accounts for all lines plotted on
    Vineet> the axis?

How about calling the function only once after you have added all the
lines to your plot?  Will this work for you?

JDH

Ok Figured out the solution but still have a problem.

There is a function get_ylim which gets you the ymin and ymax values. I'm
plotting multiple lines on the same axes object. However the get_ylim
returns different values after each plot. I'm currently having to do it a
numbe rof times and reset my min and max values. Is there a way to just do
it once where it accounts for all lines plotted on the axis?

Thanks,


-----Original Message-----
From: mat...@li...
[mailto:mat...@li...]On Behalf Of Vineet
Jain
Sent: Thursday, July 29, 2004 8:48 AM
To: matplotlib-users
Subject: [Matplotlib-users] Settling y-axis scaling


couple of questions on:
1. Is there any way to increase the y axis min by i% and y axis max by j%
where y axis min and y axis max are automatically calculated by matplotlib.
I have to plot many charts and if I calculate the min and max myself and
then use self.axMiddle.set_ylim() to set the values it takes twice as much
time to generate the chart.

2. Alternatively, is there a way to get what the current ymin and ymax
values are then I can use set_ylim to updated those







-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

couple of questions on:
1. Is there any way to increase the y axis min by i% and y axis max by j%
where y axis min and y axis max are automatically calculated by matplotlib.
I have to plot many charts and if I calculate the min and max myself and
then use self.axMiddle.set_ylim() to set the values it takes twice as much
time to generate the chart.

2. Alternatively, is there a way to get what the current ymin and ymax
values are then I can use set_ylim to updated those