Mailman 3 January 2002 - NumPy-Discussion

viewing Gridded or Polar data?
by Joe Van Andel 17 Jan '02

17 Jan '02

Can anyone recommend a visualization package that would display arrays of numbers by mapping values to a set of colors? That is, we define 32 colors, where the first color represents values 0-10, the second color represents 10-20, etc, and then each input value gets displayed as its corresponding color. I'd like to read netCDF files, if possible. Thanks much! -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel(a)ucar.edu

7 6

RE: Re: [Numpy-discussion] taking on new EM simulator project- ASAP
by rob＠pythonemproject.com 10 Jan '02

10 Jan '02

Then it wouldn't be an educational tool, for me or anyone else. It would just look like gibberish/Fortran. Rob. >----- Original Message ----- >From: Pearu Peterson <pearu(a)cens.ioc.ee> >To: Rob <rob(a)pythonemproject.com> >Sent: Thu, 10 Jan 2002 +0200 (EET) 17:07:48 > > >On Thu, 10 Jan 2002, Rob wrote: > >> This one will be interesting. I'm going to >convert the Fortran ASAP MoM >> simulator to Numpy. I've already started and its >bringing back bad >> memories of punch cards, etc. ASAP is a viable >alternative to NEC2 for >> wire antennas, as it uses the Sommerfield >conditions for imperfect >> ground. And its not too long of a program to >port. The heavy stuff >> will be I/O. Fortunately, I can use f2c to >decode the format statements >> :) > >But why don't you use Fortran/Python binding tools >like pyfort or f2py? > >Pearu

1 0

taking on new EM simulator project- ASAP
by Rob 10 Jan '02

10 Jan '02

This one will be interesting. I'm going to convert the Fortran ASAP MoM simulator to Numpy. I've already started and its bringing back bad memories of punch cards, etc. ASAP is a viable alternative to NEC2 for wire antennas, as it uses the Sommerfield conditions for imperfect ground. And its not too long of a program to port. The heavy stuff will be I/O. Fortunately, I can use f2c to decode the format statements :) Rob. -- The Numeric Python EM Project www.pythonemproject.com

2 1

Sparse matricies
by Andrew P. Lentvorski 08 Jan '02

08 Jan '02

I just looked through the archives and the web searches and didn't really find anything current on sparse matricies. Is there anything current for Python which handles sparse matrix codes? If someone is looking for a C implementation of sparse matrix handlers, I would refer to the sparse matrix package developed at Berekeley which is part of the Spice 3f4 circuit simulator (released under a modified old-style BSD license). I can provide pointers if they are desired. My goal is to actually create a useful circuit simulator wholly in Python so that it would be useful for both teaching and modification in special cases. Andy L.

2 4

Re: [Numpy-discussion] RPMs out of date, have problems
by gvermeul＠labs.polycnrs-gre.fr 07 Jan '02

07 Jan '02

> > > python setup.py bdist_rpm needs only write access to the user's home > > directory. > > Everywhere? It didn't when I first tried (that was an early distutils > release under RedHat 6.2). > Can you check which version of Python/distutils. If it is a version python that does not come with distutils, we can count it out. > > > Of course, adding a generic spec file is the easy 2 minutes solution, > > but I have choosen not to do that because it will invite bad policy > > (providing binary RPMs is asking for trouble). > > And yet many people will not accept anything but binary RPMs, out of > ignorance or fear. We won't make everyone happy... > Yes, and they will complain to JH if they are failing to install JH's binary RPMs. The best we can do is explain the motivation of NOT providing binary RPMs. If that is not sufficient for some, we can only advise that they switch to Windows or pester their distro providers for RPMs of the latest NumPy. > > I admit that I never looked into fully automatic RPM generation by > distutils as I usually need to add some manual steps to the > build/install process. For example, distutils doesn't let me specify > compiler options, but I want time-critical code to be compiled with > the highest optimization level. Hopefully this will be addressed in > distutils one day. > There are two ways to do this: (1) Extension( ..., extra_compile_args = [ "-O17" ], ...) This will append the optimization level 17 to the compiler flag (the last -O option counts). (2) export CFLAGS=-O3; python setup.py build This will append -O3 The result of (1) and (2) is gcc .... -017 -03 Gerard PS: distutils may look intimidating at first, but it is really simple compared to automake/autoconf. The disadvantage is that it is not very well tested. --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/

6 5

Re: [Numpy-discussion] RPMs out of date, have problems
by gvermeul＠labs.polycnrs-gre.fr 06 Jan '02

06 Jan '02

> gvermeul(a)labs.polycnrs-gre.fr writes: > > > Caveats: > > (1) renaming Numeric to python-numeric has as consequence that > > the header files go into .../include/python2.1/python-numeric > > instead of .../include/python2.1/Numeric. Personally I don't > > like it (being author of a package that builds on Numeric). > > Me neither. But the fix is simple: take the distutils-generated spec > file, edit the package name, and put it into the tar ball. The added > advantage is that the binary RPM can be generated by rpm --rebuild > numpy_xxx.tar.gz. > You mean rpm -ta numpy_xxx.tar.gz Disadvantage: by default, the package will go into a distro dependent place (Mandrake, Red Hat and Suse are all different) and the package builder has to have write access to that place (Suse-7.3 grants it, Mandrake not, Red Hat don't know). This invites to building packages as root (DON'T). Building packages as a normal user protects you from erratic writes in /usr, /, ... Remember, we want to satisfy the needs of astronomer newbies. Users like you will allways find a solution. python setup.py bdist_rpm needs only write access to the user's home directory. Of course, adding a generic spec file is the easy 2 minutes solution, but I have choosen not to do that because it will invite bad policy (providing binary RPMs is asking for trouble). IMHO, the current setup.py/setup_all.py are not permitting distutils's way of 'RPM building'. It is better to fix that. I will try to see renaming the package from Numeric to python-numeric allows to install the headers in ../python2.1/Numeric instead of ./python2.1/python-numeric by changing my setup.py file. Gerard --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/

2 1

Re: [Numpy-discussion] RPMs out of date, have problems
by gvermeul＠labs.polycnrs-gre.fr 05 Jan '02

05 Jan '02

> > > I continue to be less than impressed by RPMs. Every time I try one I get > > version conflicts with other software. > Agreed, I always use RPMs because they help me to keep my systems in a reversible state. BUT, I never install binary RPMs that are not taylored to the Distro-Version that I am running (Try to install RH-7.2 packages on a RH-7.0). I may take source RPMs from other distributions as a starting point for my own tweaks, but I NEVER install 'foreign' RPMs. Attached you'll find a replacement for the setup.py script allowing to build a single binary and source RPM for Numeric + subpackages. The README.RPM for a normal user would be something like: (1) unpack python-numeric-XXX.YY.Z.tar.gz (2) cd python-numeric-XXX.YY.Z (3) python setup.py bdist_rpm This will build a binary and source RPM adapted to YOUR system (even yours, Paul, with your non-standard Python location) in the subdirectory dist (to be created automatically) (4) install with rpm -Uvh python-numeric-XXX.YY.Z-1.i?86.rpm You can always uninstall with rpm -e python-numeric. IMHO, this is a better way than trying to distibute binary RPMs. It happens that my favorite distribution is not on JH's list :-( But also, http://www.mandrakesoft.com/products/81/gaming-edition , the favorite toy of 11 years old whizkids, doing pygame-NumPy programming and who are certainly future students of astronomy. If you want to test the script: (1) replace the old setup.py with mine (2) rename Lib/Numeric.py to Lib/__init__.py (Numeric will become a real Python package). (3) python setup.py bdist (4) and install the RPM Caveats: (1) renaming Numeric to python-numeric has as consequence that the header files go into .../include/python2.1/python-numeric instead of .../include/python2.1/Numeric. Personally I don't like it (being author of a package that builds on Numeric). (I think this can be fixed, if needed). (2) I tried to acknowledge Paul Dubois' contributions in a long_description (the subpackages do not build to separate packages anymore). (3) The setup.py script shows how to add documentation to an RPM (requires to work around a bug in distutils). Personnally, I think that HTML and PDF documentation should also be added. In the current state of distutils this requires inclusion of the documentation in the python-numeric-XXX.YY.Z.tar.gz. Gerard --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/

2 1

Re: [Numpy-discussion] Obscure setup question
by gvermeul＠labs.polycnrs-gre.fr 05 Jan '02

05 Jan '02

Hi, This is very strange. I am also making packages (RPMs in my case). I do this as a normal user without write access to /usr/..... If running setup.py would have as a consequence that /usr/lib/....../install_headers.pyc would get overwritten, then setup.py would die. Can you tell if your python-2.1 is really 2.1 or 2.1.1? It happens that I am tweaking the setup.py script of Numeric and testing with python-2.1.1 and I am sure that distutils works. I suggest the following test: login as a normal user, unpack Numeric, cd Numeric and do python2.1 setup.py install --root=~/tmp This will install Numeric in ~/tmp/usr/lib/python2.1 and you will see if setup.py still tries to overwrite install_headers.pyc If so, your python2.1 is broken for some reason, if not your build system and/or sandbox are broken. Gerard > Hi! > > I have noticed an interesting difference when installing Numeric-20.3 > against python-2.1 vs. python-2.2. > > When installing against python-2.1, setup trys to write to > /usr/lib/python2.1/distutils/command/install_headers.pyc > > But when installing against python-2.2, this doesn't happen. > > Note: this question came up because I am making an ebuild (basically a > compile and install script) for Gentoo linux, http://www.gentoo.org. > The attempted write to install_headers.pyc with python-2.1 violates > Gentoo's sandboxed build environment causing the merge to fail. If you > are interested see > > http://bugs.gentoo.org/show_bug.cgi?id=21 > > Just curious if there is a known explanation for this. The simple fix > on my end, is to set the dependency >=python-2.2. > > Thanks for the great program! > > tod > > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/

1 0

Obscure setup question
by Tod M. Neidt 05 Jan '02

05 Jan '02

Hi! I have noticed an interesting difference when installing Numeric-20.3 against python-2.1 vs. python-2.2. When installing against python-2.1, setup trys to write to /usr/lib/python2.1/distutils/command/install_headers.pyc But when installing against python-2.2, this doesn't happen. Note: this question came up because I am making an ebuild (basically a compile and install script) for Gentoo linux, http://www.gentoo.org. The attempted write to install_headers.pyc with python-2.1 violates Gentoo's sandboxed build environment causing the merge to fail. If you are interested see http://bugs.gentoo.org/show_bug.cgi?id=21 Just curious if there is a known explanation for this. The simple fix on my end, is to set the dependency >=python-2.2. Thanks for the great program! tod

1 0

RPMs out of date, have problems
by Joe Harrington 04 Jan '02

04 Jan '02

Hi folks, Problem: The latest Numeric release on the web site is 20.3. The latest with an RPM is 20.1, and that RPM has a problem: it creates a directory in the system root directory. Paul D. says he will implement a solution but doesn't have the experience with RPMs (or the time) to find the problem quickly. I haven't dealt with building Python packages or distutils (is distutils a separate thing or part of Python?) at all. Can someone with the relevant experience fix the current problem and help Paul implement the solution so he can post current RPMs that install right? Ditto anyone who knows how to make packages for Debian, Solaris, and other popular package managers. Rationale: As I've mentionned previously, I'm getting an increasing number of queries from astronomers who want to play with Numeric. At this stage many of the converts will be application code contributors who will help build a library of discipline-specific routines. In talking to these people, I am finding them less than patient with the good 'ol tarball (a position I take myself, following the experience of maintaining the Clue Files, see ftp://oobleck.astro.cornell.edu/pub/clues.tar.gz). To them, it's not serious software if it isn't prepared under their system's installation manager. We need these (very) early adopters, so I think that having a current Numeric RPM for i386 Linux (and the equivalent for i386 Debian GNU/Linux and Solaris Sparc architectures, if someone knows how to build them) would be a Good Thing. Trivial install -> more users, more users -> more volunteers and more contributed code. Also, it would be more consistent with the RPM naming scheme to call the RPM "python-Numeric" (or "python-numeric", or even "numpy") rather than just "Numeric". If that's hard or philosophically undesirable, don't bother, but the name has changed a few times, so I hope it isn't a big deal. Sysadmins have to deal with more than 1000 packages now, and knowing what a package is just by looking at the name is a big help. Also, you can do things like 'rpm -qa | grep python' and get a list of all the python-related packages on your system. "Numeric" is too general outside the context of Python. All of the above goes for Numarray, when its developers are ready for the community at large to start writing code that uses it. Thanks, --jh--

6 8