matplotlib-users Mailing List for matplotlib

Eric Firing wrote:
> Thanks. There were in fact several points of incompatibility with 
> Numeric and numarray. (Normally I would have checked this, but I 
> slipped up.) I have changed quiver.py and numerix to solve the 
> immediate problem, and to slightly reduce the incidence of such 
> problems in the future. The real solution, of course, will be a 
> complete transition to numpy.
>
> Regarding griddata: I downloaded it a few minutes ago, built it, and 
> tested it with numpy, and it worked fine, at least with the test.py 
> that comes with the package. Looking very quickly at the code, I 
> don't see anything specific to any numeric package; it is using the 
> buffer interface at the C level and matplotlib.numerix at the python 
> level. Perhaps the author, Jeff Whitaker, can shed more light on this 
> question.
>
> Eric
Eric is correct - griddata should work with either Numeric/numarray/numpy. 
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

>>>>> "humufr" == humufr <hu...@ya...> writes:
 humufr> "should" but sometimes perhaps it's too hard to do
 humufr> this. One solution, if the function won't work with
 humufr> anything else than numpy, is to print a warning/error
 humufr> message for this specific function. That will push people
 humufr> towards numpy?
The matplotlib.numerix layer is fairly robust, and there is no reason
to drop support for Numeric of numarray in the near term or develop
bits of matplotlib that are numpy only. While I heartily encourage
people transition to numpy ASAP, I would like to continue full support
for both Numeric and numarray until people who have a large commitment
to one package or another have had time to convert; large institutions
with large code bases, limited man-power and higher priorities will
take their time converting. Note that the Space Telescope Science
Institute, who developed numarray and is still in the process of
porting to numpy, makes heavy use of matplotlib and developed
significant components of it, including the tkagg backend, the font
manager, contouring and the numerix layer itself. 
Usually, if something doesn't work with all three packages, it's
because a developer forgot to test and can be fixed in a few minutes
of work.
JDH

>>>>> "Tom" == Tom Denniston <tom...@al...> writes:
 Tom> FigureCanvasAgg seems to make fonts appear much larger that
 Tom> FigureCanvasWxAgg. I am trying to get plots generated
 Tom> interactively in a wx window to appear the same as those that
 Tom> I generate in a no display batch script that outputs .png
 Tom> files. I use FigureCanvasWxAgg for the former and
 Tom> FigureCanvasAgg for the latter. Is there a reason why the
 Tom> same font size would appear much larger in FigureCanvasAgg
 Tom> than FigureCanvasWxAgg. Is there another, better, way to
 Tom> achieve uniformity accross png outputs and wx on screen
 Tom> display?
 Tom> It doesn't look like one can use the FigureCanvasAgg for wx
 Tom> embedding or the FigureCanvasWxAgg for png generation because
 Tom> the former will not accept a parent window and the latter
 Tom> requires one.
 Tom> If anyone has any ideas I would greatly appreciate
 Tom> suggestions.
backend_agg and backend_wxagg both use the same underlying pixel
buffer, so you should be able to get uniformity between them. Note,
matplotlib has a different default dpi setting for figures for display
and saving, and you might want to try forcing them to be the same with
dpi = 72
fig = figure(dpi=dpi)
plot something
fig.savefig(somefile, dpi=dpi)
If that doesn't help, the only other possibility is that the
PIXELS_PER_INCH defaults are getting you screwed up. This was
included for display devices which have a different number of pixels
per inch; see
http://groups.google.com/groups?q=screen+dpi+x11&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=7077.26e81ad5%40swift.cs.tcd.ie&rnum=5
for some info about screen dpi. I vaguely recall that there was some
good reason for including the pixels_per_inch constant *and* dpi,, but
now I suspect the system may be overdetermined and we should drop this
and just use the dpi setting. In any case, each backend defines their
own (see src/_backend_wxagg.cpp and backends/backend_wx.py) and the
defaults are different in backend_agg and backend_wx). 
If the dpi suggestion above doesn't work, try setting PIXELS_PER_INCH
in backend_wx.py to 72.
JDH

Le vendredi 9 juin 2006 18:30, Christopher Barker a =E9crit=A0:
> hu...@ya... wrote:
>
> well, anyone using Numeric (or numarray), can just keep on using it for
> a god while. So something that works now should work for a while into
> the future.
"should" but sometimes perhaps it's too hard to do this. One solution, if t=
he=20
function won't work with anything else than numpy, is to print a=20
warning/error message for this specific function. That will push people=20
towards numpy?
N.

On 6/9/06, John Hunter <jdh...@ac...> wrote:
> the other is that mathtext doesn't recognize \sin, \cos, \exp etc.
> (Edin are you out there? If so, this would be something useful to
> work on).
Yes, I'm alive and well, thank you :).
It's on my radar now.

Thanks. There were in fact several points of incompatibility with 
Numeric and numarray. (Normally I would have checked this, but I slipped 
up.) I have changed quiver.py and numerix to solve the immediate 
problem, and to slightly reduce the incidence of such problems in the 
future. The real solution, of course, will be a complete transition to 
numpy.
Regarding griddata: I downloaded it a few minutes ago, built it, and 
tested it with numpy, and it worked fine, at least with the test.py that 
comes with the package. Looking very quickly at the code, I don't see 
anything specific to any numeric package; it is using the buffer 
interface at the C level and matplotlib.numerix at the python level. 
Perhaps the author, Jeff Whitaker, can shed more light on this question.
Eric
hu...@ya... wrote:
> 		Hi,
> 
> just to tell that the new quiver2 sample are not working with numarray. 
> 
> /usr/lib/python2.4/site-packages/matplotlib/quiver.py", line 237, in 
> _make_verts
> scale = nx.amax(a) * math.sqrt(len(a)) # crude auto-scaling
> AttributeError: 'module' object has no attribute 'amax'
> 
> 
> I think that we will have soon a big problem with the scientific soft in 
> python. Some of them will use numpy, Numeric or numarray and they will be 
> totally incompatible. Theorically numpy was to do the reunification but a 
> transition period must exist. The module Numerix was doing it for matplotlib 
> but it's beginning to have more and more incompatibility. 
> The quiver problem is not the only one. I used a lot the griddata module to 
> interpolate some irregulary spaced data, it was working very fine but it's 
> not working with numpy and I don't have the skill to change it unfortunatly.
> 
> I want to thank you for all the work done for matplotlib, the critics are only 
> to avoid people to be distressed because one day all their softs won't work 
> due to numpy/numarray/Numeric incompatibility and stop to use python.
> 
> Regards,
> 
> N.
> 
> 
> 
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users