matplotlib-users Mailing List for matplotlib (Page 1442)

Hello again,

I am trying to output a large number of pictures to files. I don't know
the correct usage of figure() in this case, so my program end up
devouring memory continuously. I tried to use the clear() method or del,
but neither works. Or I didn't use right. 

Willing to learn from any of you.

Eric

Hi Gerry,

I just noticed a similar "failure" when I try to run matplotlib from the
root of the source tree, i.e. the directory matplotlib-0.53.  I think
doing that (running from the root) causes Python to interpret the
matplotlib subdirectory (matplotlib-0.53/matplotlib) as a package and to
look for ft2font.so there rather than in site-packages/matplotlib.  Try
cd'ing to some other directory.

HTH,
Todd


On Wed, 2004-04-21 at 15:47, Gerry Wiener wrote:
> I'm trying to run the first example in the tutorial but am running into 
> an import problem:
> 
> ActivePython 2.3.2 Build 231 (ActiveState Corp.) based on
> Python 2.3.2 (#1, Nov  6 2003, 09:47:20)
> [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> from matplotlib.matlab import *
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "matplotlib/matlab.py", line 128, in ?
>     from axes import Axes
>   File "matplotlib/axes.py", line 10, in ?
>     from axis import XTick, YTick, XAxis, YAxis
>   File "matplotlib/axis.py", line 22, in ?
>     from font_manager import FontProperties
>   File "matplotlib/font_manager.py", line 38, in ?
>     from matplotlib import ft2font
> ImportError: cannot import name ft2font
> 
> I've built and installed the freetype2 library and the matplotlib 
> installation cites:
> 
> running install_lib
> copying build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so -> 
> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends
> copying build/lib.linux-i686-2.3/matplotlib/backends/_backend_agg.so -> 
> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends
> copying build/lib.linux-i686-2.3/matplotlib/ft2font.so -> 
> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib
> copying build/lib.linux-i686-2.3/matplotlib/_image.so -> 
> /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib
> 
> Not sure what's going wrong. Please respond to my email as well since 
> I'm not a subscriber to the email list.
> 
> Thanks,
> 
> Gerry Wiener
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Todd Miller <jm...@st...>

>>>>> "Gerry" == Gerry Wiener <ge...@uc...> writes:

    Gerry> I'm trying to run the first example in the tutorial but am
    Gerry> running into an import problem:

    Gerry> cannot import name ft2font

I haven't seen this one before.  Are you using matplotlib-0.53
(released today?)

My first guess is you have two python's installed and are installing
to one and running the other.  I installed and tested the lastest
matplotlib on a redhat 7.1 machine so I don't see any problems with
your OS.

After upgrading to 0.53, you can make sure you are actually using it
by

    mother:~/tmp/matplotlib-0.53/examples> python
    Python 2.3 (#1, Aug 29 2003, 12:14:15)
    [GCC 3.2.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    Welcome to rlcompleter2 0.95
    for nice experiences hit <tab> multiple times
    >>> import matplotlib
    >>> matplotlib.version
    '0.53'

If this doesn't help, let me know what

  > ldd /d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/ft2font.so 

reveals.

John Hunter

I'm trying to run the first example in the tutorial but am running into 
an import problem:

ActivePython 2.3.2 Build 231 (ActiveState Corp.) based on
Python 2.3.2 (#1, Nov  6 2003, 09:47:20)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from matplotlib.matlab import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "matplotlib/matlab.py", line 128, in ?
    from axes import Axes
  File "matplotlib/axes.py", line 10, in ?
    from axis import XTick, YTick, XAxis, YAxis
  File "matplotlib/axis.py", line 22, in ?
    from font_manager import FontProperties
  File "matplotlib/font_manager.py", line 38, in ?
    from matplotlib import ft2font
ImportError: cannot import name ft2font

I've built and installed the freetype2 library and the matplotlib 
installation cites:

running install_lib
copying build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so -> 
/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends
copying build/lib.linux-i686-2.3/matplotlib/backends/_backend_agg.so -> 
/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib/backends
copying build/lib.linux-i686-2.3/matplotlib/ft2font.so -> 
/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib
copying build/lib.linux-i686-2.3/matplotlib/_image.so -> 
/d2/gerry/local/ActivePython-2.3/lib/python2.3/site-packages/matplotlib

Not sure what's going wrong. Please respond to my email as well since 
I'm not a subscriber to the email list.

Thanks,

Gerry Wiener

>>>>> "Eric" ==   <er...@jo...> writes:

    Eric> Dear ones, I discovered Matplotlit only yesterday, and it's
    Eric> great. But I've got one problem. Since I am using the GTK
    Eric> backend, I have to use the show() function. But I have
    Eric> hundreds of figures and each to be written into a file. If I
    Eric> put the show() at the end of my program, the machine just
    Eric> can't handle it. If I put the show() in a loop, then I have
    Eric> close the hundreds of picture windows by hand. Is there a
    Eric> solution to this problem?

Yes, you want to use the Agg backend for bulk pure image generation.
You don't need to use show and no GUI pops up.

You can specify Agg from the command line by doing

  > python myscript.py -dAgg

Or from within your script by doing

    import matplotlib
    matplotlib.use('Agg')
    from matplotlib.matlab import *

    plot([1,2,3])
    savefig('myfile')

Agg provides PNG output, which in my opinion is superior to jpeg for
line art.

These issues are covered in the FAQ, especially "Can I just generate
images without having a window popup?"

  http://matplotlib.sourceforge.net/faq.html

You should probably also check out

  http://matplotlib.sourceforge.net/tutorial.html

and

  http://matplotlib.sourceforge.net/backends.html

Good luck!   
JDH

Dear ones,

I discovered Matplotlit only yesterday, and it's great. But I've got one
problem. Since I am using the GTK backend, I have to use the show()
function. But I have hundreds of figures and each to be written into a
file. If I put the show() at the end of my program, the machine just
can't handle it. If I put the show() in a loop, then I have close the
hundreds of picture windows by hand. Is there a solution to this
problem?

Also the Matplotlib I downloaded doesn't have the file libjpeg.dll in
it. Wonder where can I get it.

Looking forward to hearing some advices from you. 

Enjoy the day.

Eric

What's new in matplotlib 0.53

Improved font manager and support

  Paul Barrett has thoroughly overhauled font support. FontTools and
  ttfquery are no longer required for font finding as matplotlib now
  has a completely freestanding freetype2 implementation and font
  finder. Among other things, this should enable you to specify fonts
  in your scripts and matplotlibrc file and generate consistent
  figures across backends and operating systems. The font finder
  algorithm and implementation are based on the W3C standard
  http://www.w3.org/TR/1999/REC-CSS1-19990111.

  See the font manager module documentation, the fonts documentation
  http://matplotlib.sf.net/fonts.html and the updated .matplotlibrc
  file for more details; please update your .matplotlibrc.  Thanks
  Paul!

Backend WXAgg

  Antigrain rendering to wxpython applications and figure windows. Now
  wx users have access to all the latest matplotlib functionality,
  including mathtext, antialised drawing, alpha blending and image
  support.

Major and minor ticks

  Full support for major and minor ticks with a bevy of more
  intelligent tick locators supplied in the ticker module. Fully
  customizable and user definable tick locators and formatters. See
  major_minor_demo1.py and major_minor_demo2.py. The default tick
  labeler is much more intelligent is choosing good tick locations.
  See http://matplotlib.sf.net/matplotlib.ticker.html


Date plots

  A new command a plot_date command for plotting date dependent data;
  see http://matplotlib.sf.net/screenshots.html#date_demo. Converters
  supplied in the dates module allow you to work with a variety of
  datetime instances. Custom date locators and formatters allow you to
  place major and minor ticks by minute, hour, weekday, month, year,
  etc, and use strftime format strings to format the ticks. See
  examples date_demo1.py and date_demo2.py. The dates documentation
  provides an overview and guide to with dates -
  see http://matplotlib.sf.net/matplotlib.dates.html.

Ported image support to numarray and postscript backend

  The image module now works with Numeric or numarray, and now works
  in the postscript backend as well as GTKAgg, TkAgg, WXAgg, Agg, and
  GTK.  Thanks to Todd Miller for the PS work!

Changes to matplotlibrc

  Many features added to the default config file for font support,
  tkagg windowing in win32, and more. Please use the new file at
  http://matplotlib.sf.net/.matplotlibrc. By default, the installer
  will overwrite the existing file in the install path, so if you want
  to preserve your's, please move it to your HOME dir and set the
  environment variable if necessary.

load and save commands

  Helper functions for loading and saving ASCII arrays. See load and
  save in the matlab interface.

Two scales on the same axes

  Added some features to the axis and ticks to allow two plots with
  different scales on the "same" axes with different scales, ticks and
  labels on the left and right side of the x axis. To see why same is
  quoted, see examples/two_scales.py.

finance module

  The finance module includes a function to fetch quotes from yahoo,
  to draw candlestick plots, and to draw vertical line plots for
  high-low range with open-close ticks to the left and right. I'm
  hoping that user contributions will make up the bulk of this module
  since I'm not a finance guy! See
  http://matplotlib.sf.net/screenshots.html#date_demo.


http://matplotlib.sourceforge.net

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
    Perry> While not common, it does happen. I'm reminded of a
    Perry> handbook that was produced here that generated an incorrect
    Perry> plot because of a clipping error. We didn't write that
    Perry> clipping software, but it was embarrasing nonetheless. It's
    Perry> worth some effort to get it right I think. Before wasting
    Perry> more discussion over it I guess I'd like to know which
    Perry> backends don't support generalized clipping for lines and
    Perry> polygons.

I'll delve deeper into agg and find out what exactly is going.

BTW, Maxim has revamped the antigrain site, added documentation, and
released some new code.  I'm obviously waiting until the dust settles
on the next matlotlib release before upgrading (and upgrading
matplotlib agg cvs will be a bit of a pain since many file names hanve
changed).

  http://antigrain.com

JDH

John Hunter writes:

> In Srinath's case, we've asked the backend to plot, for example, a
> line from (0,-50000), (0,100) and then clip to the (25,25) (75,75)
> rectangle.  I don't think the average backend (GTK, Agg) knows what to
> do with this line since they expect bitmap/display coords; there are
> no backend transformations - everything happens on the front end
> (clearly there are pros and cons of this approach, see below).
>
Hmmm, I've always figured that true clipping works with arbitrary
coordinates, that it does handle exactly the problem that
Srinath reports; when it doesn't then the clipping algorithm
is not really fully implemented. I'm almost certain that OpenGL
handles this correctly and would be surprised if postscript didn't
as well. Is it true that agg will only clip positive coordinates
correctly? If so I'm surprised. Some GUIs may not, but I would
have thought this is standard for any graphics system. On the
other hand, I admit to the possibility of being completely wrong
about this. I'll look up the postscript situation. You are much
more familiar with agg than I am, though (particularly since
agg documentation is not easily accessible).

> With data clipping turned, the line class throws out the (0,-50000)
> point as illegal.
>
> To fix this in the current framework, we have to identify line
> segments in the x,y arrays which intersect the view port but with one
> or more end points outside the viewlim, and then draw the appropriate
> line through view port.  This issue primarily arises for connected

Tell me about it :-). I wrote a Python program to do just this for a
Chaco/kiva/Tk backend. Messy but doable. Clipping polygons is way
messier (many complex algorithms developed for that in the literature).
Performance was ok so long as the original curve didn't
get fragmented into too many segments. (Worst case: 100,000 points;
alternating one point out of range positive and the next out of
range negative).

> points (line styles '-', '--', and '-.' ).  For symbol lines, data
> clipping already does the right thing, which is to throw the point
> away.  However, there are hypothetical wacky cases you can imagine
> when you feel like being mean to matplotlib, like a 'o' circle marker
> 5 million miles from the view limits with a 5 million and one mile
> radius.....  For connected lines, this could be very costly to
> implement since we have to loop over potentially very long arrays; for
> markers it would be worse.
>
This is a bad case. This is where you do need the polygon clipping
algorithm.

> Refactoring transforms to the backend would probably fix this
> entirely.  While non-trivial, this may be the best long term solution,
> especially when we want to do things like line and patch collections
> for efficient drawing of large numbers of objects.  The two major
> benefits of the current transform architecture are 1) it lets you
> specify locations like 5 points to the left of the right y axes, and
> have the transform automatically update in the presence of window
> resizes, dpi changes, etc...  Very nice when drawing ticks.... and 2)
> backends only have to think about one coord system, display, which
> makes it easier to implement a backend.
>
I'm not sure this is needed if all the important backends (i.e.,
Agg-based, postscript, svg, ...) support this capability. Users
are warned that clipping doesn't work well for the other backends
or the backend calls call clipping functions on their data points
before calling the graphics primitives.

> I'm not convinced that it is a terrible thing to have a policy that
> matplotlib only plots line segments and markers whose vertices are in
> the axes limits, but I'm open to being convinced.
>
While not common, it does happen. I'm reminded of a handbook that
was produced here that generated an incorrect plot because of
a clipping error. We didn't write that clipping software, but it
was embarrasing nonetheless. It's worth some effort to get it
right I think. Before wasting more discussion over it I guess
I'd like to know which backends don't support generalized clipping
for lines and polygons.

Perry

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
    Perry> Is the essence of the issue here whether clipping is
    Perry> working properly, in particular, the backend clipping? I
    Perry> would have thought that backend clipping should handle this
    Perry> properly.  For which backends does it not? If it doesn't
    Perry> for some, perhaps the issue is to supply our own software
    Perry> clipping; algorithm (possibly much slower though) as an
    Perry> option.

Backend clipping works when the points are on the canvas (the canvas
is the entire figure, not just the axes).  Eg, on a 100x100 canvas,
with a line from (0,0) to (100,100) you can clip to the (25,25)
(75,75) rectangle.  No problems there.

In Srinath's case, we've asked the backend to plot, for example, a
line from (0,-50000), (0,100) and then clip to the (25,25) (75,75)
rectangle.  I don't think the average backend (GTK, Agg) knows what to
do with this line since they expect bitmap/display coords; there are
no backend transformations - everything happens on the front end
(clearly there are pros and cons of this approach, see below).

With data clipping turned, the line class throws out the (0,-50000)
point as illegal.

To fix this in the current framework, we have to identify line
segments in the x,y arrays which intersect the view port but with one
or more end points outside the viewlim, and then draw the appropriate
line through view port.  This issue primarily arises for connected
points (line styles '-', '--', and '-.' ).  For symbol lines, data
clipping already does the right thing, which is to throw the point
away.  However, there are hypothetical wacky cases you can imagine
when you feel like being mean to matplotlib, like a 'o' circle marker
5 million miles from the view limits with a 5 million and one mile
radius.....  For connected lines, this could be very costly to
implement since we have to loop over potentially very long arrays; for
markers it would be worse.

Refactoring transforms to the backend would probably fix this
entirely.  While non-trivial, this may be the best long term solution,
especially when we want to do things like line and patch collections
for efficient drawing of large numbers of objects.  The two major
benefits of the current transform architecture are 1) it lets you
specify locations like 5 points to the left of the right y axes, and
have the transform automatically update in the presence of window
resizes, dpi changes, etc...  Very nice when drawing ticks.... and 2)
backends only have to think about one coord system, display, which
makes it easier to implement a backend.

I'm not convinced that it is a terrible thing to have a policy that
matplotlib only plots line segments and markers whose vertices are in
the axes limits, but I'm open to being convinced.

JDH

John Hunter writes:
> >>>>> "Srinath" == Srinath Avadhanula <sr...@fa...> writes:
> 
>     Srinath> Besides whether or not its a common enough situation is
>     Srinath> very application specific. I was planning to use
>     Srinath> matplotlib to display a complex layout.  At the original
>     Srinath> scale, not much can be seen. There necessarily has to be
>     Srinath> a lot of scaling to see the details.
> 
> Well, it's not complex scaling that causes troubles.  The case where
> you see this failure is when you are drawing a connected line between
> two points where one or both of the points is far outside the view
> limits.
> 
Is the essence of the issue here whether clipping is working
properly, in particular, the backend clipping? I would have
thought that backend clipping should handle this properly.
For which backends does it not? If it doesn't for some,
perhaps the issue is to supply our own software clipping;
algorithm (possibly much slower though) as an option.

Perry

>>>>> "Srinath" == Srinath Avadhanula <sr...@fa...> writes:

    Srinath> Besides whether or not its a common enough situation is
    Srinath> very application specific. I was planning to use
    Srinath> matplotlib to display a complex layout.  At the original
    Srinath> scale, not much can be seen. There necessarily has to be
    Srinath> a lot of scaling to see the details.

Well, it's not complex scaling that causes troubles.  The case where
you see this failure is when you are drawing a connected line between
two points where one or both of the points is far outside the view
limits.

    Srinath> Could you let me know which files in matplotlib have the
    Srinath> code in question? I'll take a look then.

The two relevant methods are matplotlib.transforms.Transform.positions
and matplotlib.lines.Line2D._draw.  I think the best place to start
would be in the latter function.  Let the transform do it's thing and
then look for negative points.

Note there are two kinds of clipping in matplotlib: data clipping and
view clipping.  data clipping removes data outside the view limits
before transpose and plotting.  view clipping is a renderer operation
that prevents lines from being drawn outside the axes box.  data
clipping would remove a point from a connected line outside the
viewport and prevent any part of that line from being drawn, even the
part in the view port.  view clipping would only clip the part that
extends outside the viewport.

The decision to use one or the other is often motivated by
performance.  Eg, if you want to plot a very large data set with only
a small fraction in the viewport (which I often do), you often want to
use data clipping to reduce the data set before transform and
rendering.  If you normally plot data with limits near the viewport
limits you probably do not want the extra performance overhead and are
happy with just view clipping which gives the "usual" result.  That is
why it's a configurable parameter.

In earlier versions of matplotlib data clipping was on by default so
data outside the view ports was removed.  That is probably why we
didn't see this negative transform error earlier.  But experiments
revealed that in the most common cases, data clipping did not provide
an extra performance benefit, and occasionally surprised users in
cases very similar to yours where one point of a connected line was
outside the viewport and the entire line was removed.

Given that negative display coords are essentially undefined (and
backend dependent) at this point, I'm going to re-enable data clipping
in the default matplotlibrc file, and I suggest most users do the
same.  There may be modulo operations on data points very far outside
the data set that generate negative display values, or display values
far larger than the display limits, each of which could cause artifact
points.

The ideal solution is yet to be found, but I'm open to suggestions and
improvements.

JDH

>>>>> "Peter" == Peter Juvan <pet...@fr...> writes:

    Peter> I prefer pcolor over imshow - I need to represent values
    Peter> from a 12x12 matrix as colors. Please modify pcolor
    Peter> arguments to use a custom colormap. Where / when will I be
    Peter> able to obtain the modified version? -Peter

For 12x12 pcolor should work great.  I included the pcolor cmap kwarg
for the next release, which is starting to look like tomorrow rather
than today .....

JDH

> From: John Hunter [mailto:jdh...@ac...] 
>
> Note, if you really need the
> functionality of pcolor over imshow (eg you want to set some
> properties on the rectangle patches), I can modify the pcolor argument
> list to use your custom colormap.


I prefer pcolor over imshow - I need to represent values from a 12x12 matrix
as colors. Please modify pcolor arguments to use a custom colormap. Where /
when will I be able to obtain the modified version? -Peter

>>>>> "Peter" == Peter Juvan <pet...@fr...> writes:

    Peter> Q: Is it possible to change the default color scale of the
    Peter> matplotlib.matlab.pcolor plot? How? -Peter

You can define your own colormap by subclassing
matplotlib.colors.Colormap and then passing this to imshow in the cmap
argument.  Note that for the most part pcolor and imshow have the same
functionality, but imshow is 1000 times faster for large grids.
Compare pcolor_demo.py and pcolor_demo2.py in the examples dir which
use pcolor and imshow respectively.  Note, if you really need the
functionality of pcolor over imshow (eg you want to set some
properties on the rectangle patches), I can modify the pcolor argument
list to use your custom colormap.

If you define a new colormap (currently we have only jet and
grayscale), please send it back to the list so I can include it.

JDH

>>>>> "Jaanus" == Jaanus Karo <jaa...@ph...> writes:

    Jaanus> Can I create graphs with two different y-axes?

Look for the 0.53 release later this afternoon.  Download the src
distribution and see examples/two_scales.py.

JDH

>>>>> "Kenneth" == Kenneth McDonald <kmm...@wi...> writes:

    Kenneth> Couldn't see the answers to these questions when looking
    Kenneth> through the class reference docs, but they seem like
    Kenneth> common tasks, so I suspect there are standard idiomatic
    Kenneth> way of doing these. Could anyone refer me to examples
    Kenneth> showing

Actually, neither of these exist in matplotlib-0.52, but see below.

    Kenneth> 1) How to most easily label the x axis for data which is
    Kenneth> plotted by date? (More specifically; does matplotlib have
    Kenneth> any understanding of date values, and if so, how do I
    Kenneth> access and use it?) I'm hoping there's an easier way than
    Kenneth> explicitly labelling ticks on the x axis.

Full date support in matplotlib-0.53.  Release should be this
afternoon.  The new examples will be examples/date_demo*.py.

    Kenneth> 2) I'll be drawing logy graphs, and I want a certain
    Kenneth> slope to indicate a certain rate of growth, which means
    Kenneth> that, when using matplotlib via TkAgg, I want it to keep
    Kenneth> the ratio of the graph display height and display width
    Kenneth> constant as it resizes the graph to take into account
    Kenneth> changes in the size of the enclosing window. Is there a
    Kenneth> standard way to do this?

This is a good idea but it's not implemented and should be.  How do
you think the best way is to indicate a constrained resize?  With a
modifier key held down during the resize?

JDH

Q: Is it possible to change the default color scale of the
matplotlib.matlab.pcolor plot? How? -Peter

Hello!

Can I create graphs with two different y-axes?

Jaanus

Couldn't see the answers to these questions when looking through the
class reference docs, but they seem like common tasks, so I suspect
there are standard idiomatic way of doing these. Could anyone refer
me to examples showing

1) How to most easily label the x axis for data which is plotted
by date? (More specifically; does matplotlib have any understanding
of date values, and if so, how do I access and use it?) I'm hoping
there's an easier way than explicitly labelling ticks on the x axis.

2) I'll be drawing logy graphs, and I want a certain slope to indicate
a certain rate of growth, which means that, when using matplotlib
via TkAgg, I want it to keep the ratio of the graph display height
and display width constant as it resizes the graph to take into
account changes in the size of the enclosing window. Is there
a standard way to do this?

Thanks,
Ken McDonald

Well, I finally have matplotlib up and running under OS X, and
am amazed at the quality of the graphs. I'm writing up a
summary of what I learned about Python/Tk/OS X, and will
post it to this and other lists in the next day or two.

Now, a real quick question; are there any tutorials or examples
which show the "correct" way of using matplotlibs pythonic (as
opposed to Matlabic) API? I don't know and don't want to learn
Matlab, so figure I might as well start by using the "pure"
python API. However, all of the examples I've looked at use
the Matlab style interface, and the reference docs don't
really give a good idea of _how_ the various Python
classes are intended to be used together.

Thanks,
Ken

On Mon, 19 Apr 2004, John Hunter wrote:

> >>>>> "Srinath" == Srinath Avadhanula <sr...@fa...> writes:
>
>     Srinath> Hello, I seem to have uncovered a bug in setting/updating
>     Srinath> the axis limits.
>
> limits, you get negative display coords which are undefined.  I am not
> sure this case is common enough to warrant the performance hit of
> detecting it and doing the linear interpolation necessary to add

I have no time right now to go into a technical discussion, but IMHO
this is a serious enough bug that it needs to be fixed. One can only
worry about performance after doing the right thing. It doesn't make
sense to give the completely wrong answer in a shorter time.
[Sorry, I do not mean to sound curt or rude. Excuse me if it sounds that
way.]

Besides whether or not its a common enough situation is very application
specific. I was planning to use matplotlib to display a complex layout.
At the original scale, not much can be seen. There necessarily has to be
a lot of scaling to see the details.

> If you have some ideas on what is the best way to handle this case,
> let me know.

Could you let me know which files in matplotlib have the code in
question? I'll take a look then.

Srinath

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> John, When panning the viewport through a plot shouldn't
    Steve> the panning stop and ignore your request when you reach the
    Steve> start or end of the plot.  Is there a benefit to being able
    Steve> to pan off the edge of a plot?

I like to see the data scroll past the end so I know I am truly at the
end.  If nothing happens, I might think the mouse click didn't work,
the program froze, or something like that.  Putting the question back
on you, is there a significant cost to doing it the way it is?  Most
users don't continue panning where there is no data, I assume.  It's
kind of in line with the python philosophy: we're all adults here; if
you want to pan through empty space that's your decision.

JDH

>>>>> "Srinath" == Srinath Avadhanula <sr...@fa...> writes:

    Srinath> Hello, I seem to have uncovered a bug in setting/updating
    Srinath> the axis limits.

Hi, I have looked into this and it is indeed a bug.  Here is what is
going on:  The transforms for x and y take your view limits and map
them to display coords, where negative numbers don't make sense.  It
is a standard linear transformation

        scale = displayInterval/viewInterval
        return  scale*(y-viewMin) + displayMin

In your example, if the y axis view limits are [0.516, 0.52] and the
display interval is [44.0, 360.0], then transformation of the y vector
[0, 1].

  scale = (360-44)/0.004
  ytransformed = scale*(y-.516) + 44

which is  [-40720., 38280.]

Ie, when your nearest data point is much smaller than your view
limits, you get negative display coords which are undefined.  I am not
sure this case is common enough to warrant the performance hit of
detecting it and doing the linear interpolation necessary to add
pseudo data points to make your plot well defined.  Simply replacing
the negative data with 0 is incorrect because you have to do linear
interpolation to get the right location in display coords.  Perhaps a
warning if min(xtransformed)<0 or min(ytransformed)<0 would be
appropriate and worth the performance hit.

If you have some ideas on what is the best way to handle this case,
let me know.

JDH

John,
When panning the viewport through a plot shouldn't the panning stop and
ignore your request when you reach the start or end of the plot.
Is there a benefit to being able to pan off the edge of a plot?

Regards,
Steve