Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: <humufr@ya...>  20060609 19:20:49

Hi, just to tell that the new quiver2 sample are not working with numarray. /usr/lib/python2.4/sitepackages/matplotlib/quiver.py", line 237, in _make_verts scale = nx.amax(a) * math.sqrt(len(a)) # crude autoscaling 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. 
From: Christopher Barker <Chris.B<arker@no...>  20060609 22:30:23

humufr@... wrote: > 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. I understand and to some extent share, your frustration, but the problem already existed with Numeric and numarray. Transitioning to numpy is the solution  not the problem. > Theorically numpy was to do the reunification but a > transition period must exist. Yes, it must, and that's where we are now. It is a bit tricky, but once numpy reached 1.0 (soon, I think and hope!), we can all start using it and these problems will fade away.... > 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. 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. Chris  Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: <humufr@ya...>  20060610 10:57:58

Le vendredi 9 juin 2006 18:30, Christopher Barker a =E9crit=A0: > humufr@... 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. 
From: John Hunter <jdhunter@ac...>  20060610 18:45:47

>>>>> "humufr" == humufr <humufr@...> 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 manpower 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 
From: Eric Firing <efiring@ha...>  20060610 07:01:46

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 humufr@... wrote: > Hi, > > just to tell that the new quiver2 sample are not working with numarray. > > /usr/lib/python2.4/sitepackages/matplotlib/quiver.py", line 237, in > _make_verts > scale = nx.amax(a) * math.sqrt(len(a)) # crude autoscaling > 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. > > > > > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers 
From: Jeff Whitaker <jswhit@fa...>  20060610 20:46:07

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)4976313 NOAA/OAR/CDC R/PSD1 FAX : (303)4976449 325 Broadway Boulder, CO, USA 803053328 
From: <humufr@ya...>  20060612 20:48:08

oki sorry for griddata it was my fault. After the mail on the list, I clean= ed=20 all precedent installation and now it's working fine with numpy... Thanks, N. Le samedi 10 juin 2006 13:45, Jeff Whitaker a =E9crit=A0: > 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 
Sign up for the SourceForge newsletter:
No, thanks