matplotlib-devel Mailing List for matplotlib

http://code.google.com/apis/chart/
Cheers :)
f

On Thursday 06 December 2007 10:40:16 am John Hunter wrote:
> I'd like to shoot for another point release next week 0.91.2 to get
> something out that is stable and free of most of the known bugs. Lets
> hold off contributing anything significant in terms of new features
> (minor features easy to test and unlikely to break code are OK), and
> concentrate of clearing up the bugs on the tracker that have been
> posted in response to the 0.91 releases.
I had a go at the bug reports today. A lot of them were old and out of date, 
many had already been fixed. I also closed several that were probably invalid 
and a few that didnt include enough information to be addressed. I think 
there is still plenty of low-hanging fruit, for the majority of you who are a 
little taller than I am.
Darren

 I have a question regarding the plots that are generated in Matplotlib
I was wondering if Matplotlib does autoscaling as well as makes sure
that the number of samples of data to pixels ratio is always an
integer. This is important when you zoom into the plot or readjust
the plot because then it readjusts the axis to fit the plot. This
ensures that data is accurate on the plot and data is not lost. It
also is an important feature when doing Signals processing and looking
at FFT's and Spectrograms.
I was also wondering if Matplotlib decimates the data
Thanks

Darren Dale wrote:
> I just committed changes to the py2exe functions in __init__.py, which had 
> references to the old matplotlibdata directory instead of the newer 
> mpl-data.\
Thanks!
py2app is broken too. I haven't looked into it yet, but I think it uses 
a "recipe" instead of the py2exe functions, so that will need to be fixed.
Is anyone familiar with that that can look at it?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

John Hunter wrote:
> On Dec 6, 2007 12:14 PM, Michael Droettboom <md...@st...> wrote:
>> It seems to me that most of the machinery about selecting which
>> numerical package to import can be removed, correct? This is mainly in
>> numerix/__init__.py. The rcParam can be kept around, but maybe we
>> should warn if it's not set to numpy since it ain't gonna do what you
>> asked...
> 
> I'm not 100% sure what you are referring to....
> 
> We decided to leave numerix as is for users who wrote scripts around it, eg
> 
> import matplotlib.numerix as nx
> x = nx.arange(10).
> plot(x)
> 
> Of cource, mpl will use numpy under the hood, and should not import
> numerix itself anywhere in mpl, but we did not want to break the code
> of users who depended on it. If they set numerix to numarray, numerix
> will give them numarray, but mpl will convert it to numpy in the
> asarray calls. As long as the Numeric, numarray or numpy they are
> using supports the array protocol we should have no troubles.
> 
> Or are you talking about something completely different?
I think we're talking about the same thing, but I'm glad I asked.
The problem the user ran into was that they had "numerix: numarray" in 
matplotlibrc, but numarray wasn't installed. So importing matplotlib 
threw an ImportError attempting to import numarray. (pylab.py imports 
numerix.npyma, which imports numerix/__init__.py, which imports 
numarray). Not really a bug with matplotlib as such -- it's user error 
for setting numerix to numarray.
I had thought that since core matplotlib is "numpy" pure, the potential 
for others making this mistake could be removed by simply not having any 
code that imports numarray. However, as you seem to suggest, as long as 
there are reasons that someone would want numerix to wrap numarray, 
while matplotlib uses numpy, then I agree it should be left as is.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I just committed changes to the py2exe functions in __init__.py, which had 
references to the old matplotlibdata directory instead of the newer 
mpl-data. This should address bug 1827685, but I don't use py2exe (or 
windows) and need someone to test the changes and suggest further 
improvements if it is still broken.
Thanks,
Darren

And, another goal for layout (if it has not already been achieved) might 
be to make it easy to end up with a tight bounding box. That is, to end 
up with the plot nicely filling the allotted space, to the extent that 
it can given specified aspect ratio. One of the repeated complaints 
about mpl is that one can easily end up with quite a bit of unneeded 
whitespace on the periphery.
Another goal might be to make it easy to specify axes dimensions in 
physical units, or to specify data-to-physical-units conversion factors. 
 For example, sometimes one wants to make many plots with 100 m 
vertical data units to 1 inch on the page, and 1 degree latitude to 1/2 
inch on the page.
(Quick thoughts, file or discard as needed--sorry I can't do more at the 
moment.)
Eric
John Hunter wrote:
> On Dec 6, 2007 8:03 AM, Michael Droettboom <md...@st...> wrote:
> 
>> It's an open question whether autolayout may start ignoring the adjust
>> requests or not as a backward compatibility measure. I still consider
>> this stuff a long way off until it's usable in general.
> 
> My feeling is that it is not a good idea to try and support the manual
> layout and the autolayout with the same set of parameters, but how to
> get this segregation right may be difficult in practice. Eg, it is
> probably better to have something like a vbox and hbox pad that the
> user can configure for the autolayout if they want to increase the
> whitespace between the axes using autolayout, rather than trying to
> support the subplots adjust parameters. Depending on the
> figure.autolayout setting, one might launch a different GUI widget
> panel (eg the subplots_adjust widgets if autolayout is False, and a
> different widget with different params if it is True).
> 
> JDH
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Dec 6, 2007 12:14 PM, Michael Droettboom <md...@st...> wrote:
> It seems to me that most of the machinery about selecting which
> numerical package to import can be removed, correct? This is mainly in
> numerix/__init__.py. The rcParam can be kept around, but maybe we
> should warn if it's not set to numpy since it ain't gonna do what you
> asked...
I'm not 100% sure what you are referring to....
We decided to leave numerix as is for users who wrote scripts around it, eg
 import matplotlib.numerix as nx
 x = nx.arange(10).
 plot(x)
Of cource, mpl will use numpy under the hood, and should not import
numerix itself anywhere in mpl, but we did not want to break the code
of users who depended on it. If they set numerix to numarray, numerix
will give them numarray, but mpl will convert it to numpy in the
asarray calls. As long as the Numeric, numarray or numpy they are
using supports the array protocol we should have no troubles.
Or are you talking about something completely different?
JDH

It seems to me that most of the machinery about selecting which 
numerical package to import can be removed, correct? This is mainly in 
numerix/__init__.py. The rcParam can be kept around, but maybe we 
should warn if it's not set to numpy since it ain't gonna do what you 
asked...
It's not just "dead code" -- Leaving it in means that mpl will attempt 
to import numarray in the event that a stale .matplotlibrc file asks for 
it... It was the source of a real head-scratcher in a recent internal 
support request I got.
Thought I'd check on the list before I started, because I know the 
"numpification" process has some complexities I'm not too familiar with.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Dec 6, 2007 8:03 AM, Michael Droettboom <md...@st...> wrote:
> It's an open question whether autolayout may start ignoring the adjust
> requests or not as a backward compatibility measure. I still consider
> this stuff a long way off until it's usable in general.
My feeling is that it is not a good idea to try and support the manual
layout and the autolayout with the same set of parameters, but how to
get this segregation right may be difficult in practice. Eg, it is
probably better to have something like a vbox and hbox pad that the
user can configure for the autolayout if they want to increase the
whitespace between the axes using autolayout, rather than trying to
support the subplots adjust parameters. Depending on the
figure.autolayout setting, one might launch a different GUI widget
panel (eg the subplots_adjust widgets if autolayout is False, and a
different widget with different params if it is True).
JDH

I'd like to shoot for another point release next week 0.91.2 to get
something out that is stable and free of most of the known bugs. Lets
hold off contributing anything significant in terms of new features
(minor features easy to test and unlikely to break code are OK), and
concentrate of clearing up the bugs on the tracker that have been
posted in response to the 0.91 releases.
Thanks,
JDH

That should continue to work. It will create more space than you 
probably want, though, since it will add the manually-added space and 
the automatically-added space together.
It's an open question whether autolayout may start ignoring the adjust 
requests or not as a backward compatibility measure. I still consider 
this stuff a long way off until it's usable in general.
Cheers,
Mike
Tom Holroyd wrote:
> re autolayout; how does this affect gcf().subplots_adjust(hspace=1.),
> which is how I would make room (where hspace can be adjusted)?
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

re autolayout; how does this affect gcf().subplots_adjust(hspace=1.),
which is how I would make room (where hspace can be adjusted)?

Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> It may be now be tricky to call apply_aspect correctly. With the 
>> recent auto-layout changes, it's required to be called after the text 
>> layout has been done, but before it has been drawn. What is your use 
>> case for calling it outside of that? Do you need to set and then use 
>> the aspect-adjusted axes position? Since apply_aspect is always 
>> called from within draw() anyway, for most uses, calling outside of 
>> that would be redundant, and I was considering making it a private 
>> method. If you don't call it from your code, is anything different?
>>
>> Cheers,
>> Mi
> 
> Mike: The only side effect of not calling apply_aspect that I can see 
> involves the use of ax.get_position(). The axes position that you get 
> is not what will ultimately be drawn on the figure unless you call 
> apply_aspect before get_position. This comes into play when setting the 
> position of colorbar axes, since you want them to line up with the axes 
> of the image.
That makes sense. I'll do what you suggest for now -- but 
unfortunately, apply_aspect is no longer "good enough" to determine the 
ultimate position of the axes, since they can also be adjusted based on 
the surrounding text now.
Alas, this auto-layout thing gets more complicated. I'll have to figure 
out something more robust (possibly combining the 
text-overlapping-prevention and the aspect ratio into a single call 
somehow).
Cheers,
Mike
>> Jeff Whitaker wrote:
>>>
>>> Mike: I see that ax.apply_aspect now has a 'position' argument. To 
>>> maintain backward compatibility, may I suggest that you make it a 
>>> kwarg, with default value None, and then add
>>>
>>> if position is None:
>>> position = self._originalPosition
>>>
>>> at the top of apply_aspect?
>>>
>>> -Jeff
>>>
>>
> 
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> It may be now be tricky to call apply_aspect correctly. With the 
> recent auto-layout changes, it's required to be called after the text 
> layout has been done, but before it has been drawn. What is your use 
> case for calling it outside of that? Do you need to set and then use 
> the aspect-adjusted axes position? Since apply_aspect is always 
> called from within draw() anyway, for most uses, calling outside of 
> that would be redundant, and I was considering making it a private 
> method. If you don't call it from your code, is anything different?
>
> Cheers,
> Mi
Mike: The only side effect of not calling apply_aspect that I can see 
involves the use of ax.get_position(). The axes position that you get 
is not what will ultimately be drawn on the figure unless you call 
apply_aspect before get_position. This comes into play when setting the 
position of colorbar axes, since you want them to line up with the axes 
of the image.
-Jeff
>
> Jeff Whitaker wrote:
>>
>> Mike: I see that ax.apply_aspect now has a 'position' argument. To 
>> maintain backward compatibility, may I suggest that you make it a 
>> kwarg, with default value None, and then add
>>
>> if position is None:
>> position = self._originalPosition
>>
>> at the top of apply_aspect?
>>
>> -Jeff
>>
>
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Michael Droettboom wrote:
> It may be now be tricky to call apply_aspect correctly. With the 
> recent auto-layout changes, it's required to be called after the text 
> layout has been done, but before it has been drawn. What is your use 
> case for calling it outside of that? Do you need to set and then use 
> the aspect-adjusted axes position? Since apply_aspect is always 
> called from within draw() anyway, for most uses, calling outside of 
> that would be redundant, and I was considering making it a private 
> method. If you don't call it from your code, is anything different?
>
> Cheers,
> Mike
Mike: Perhaps I am just misusing it - I thought you had to call it for 
the set_aspect to take effect. I didn't realize it was called from 
draw(). I'll try removing it and re-run all the basemap examples to see 
if there are any side effects.
-Jeff
>
> Jeff Whitaker wrote:
>>
>> Mike: I see that ax.apply_aspect now has a 'position' argument. To 
>> maintain backward compatibility, may I suggest that you make it a 
>> kwarg, with default value None, and then add
>>
>> if position is None:
>> position = self._originalPosition
>>
>> at the top of apply_aspect?
>>
>> -Jeff
>>
>
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

It may be now be tricky to call apply_aspect correctly. With the recent 
auto-layout changes, it's required to be called after the text layout 
has been done, but before it has been drawn. What is your use case for 
calling it outside of that? Do you need to set and then use the 
aspect-adjusted axes position? Since apply_aspect is always called from 
within draw() anyway, for most uses, calling outside of that would be 
redundant, and I was considering making it a private method. If you 
don't call it from your code, is anything different?
Cheers,
Mike
Jeff Whitaker wrote:
> 
> Mike: I see that ax.apply_aspect now has a 'position' argument. To 
> maintain backward compatibility, may I suggest that you make it a kwarg, 
> with default value None, and then add
> 
> if position is None:
> position = self._originalPosition
> 
> at the top of apply_aspect?
> 
> -Jeff
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Mike: I see that ax.apply_aspect now has a 'position' argument. To 
maintain backward compatibility, may I suggest that you make it a kwarg, 
with default value None, and then add
if position is None:
 position = self._originalPosition
at the top of apply_aspect?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

On Dec 5, 2007 6:14 PM, James Evans <jre...@ea...> wrote:
> I have just submitted a patch to the Annotation class that allows
> specification of a 'data offset' frame for the text coordinate. This allows
> you to specify a data point to annotate and an offset that will stay the
> same regardless of scale. Please let me know if this should be given a
> different name (like 'offset' or 'point offset', etc).
Hey James,
thanks a lot for this patch. As you know, it has been on my TODO list :-)
I made one minor change, which is to rename 'data offset' to 'offset
points' since 'data' in the annotation coords refers to the native
coordinate system. Since we have 'axes points' and the like, I
thought 'offset points' would be most consistent.
Anyhow, very useful!
JDH

All,
 
I have just submitted a patch to the Annotation class that allows specification of a 'data offset' frame for the text coordinate.
This allows you to specify a data point to annotate and an offset that will stay the same regardless of scale. Please let me know
if this should be given a different name (like 'offset' or 'point offset', etc).
 
--James Evans