numpy-discussion — Discussion list for all users of Numerical Python

[Numpy-discussion] Matlab to Numpy

[Nils W. <nw...@me...>]

Hi all,

Who can send me a program written in Numpy (+Vpython for graphics), 
that reproduces the results of the following Matlab code

x=linspace(0,1,25);
t=linspace(0,2,50);
[X,T] = meshgrid(x,t);
z=exp(-abs((X-.5)*(T-1)))+sin(X.*T);
subplot(3,2,1)
surf(X,T,z)
axis([0,1,0,2,0.4,2.1])
xlabel('x'),ylabel('t'),zlabel('z'),title('Actual surface')
[u,s,v] = svd(z);

for k =1:3
          zz=u(:,1:k)*s(1:k,1:k)*v(:,1:k)';
          subplot(3,2,k+1)
          surf(X,T,zz),axis([0,1,0,2,0.4,2.1])
          xlabel('x'),ylabel('t'),zlabel('z')
          title(['Rank',num2str(k),' approximation'])


              
Thanks in advance 

                  Nils

Re: [Numpy-discussion] amap: new function / ufunc method?

[Travis O. <oli...@ie...>]

> In the process of 'porting' Konrad Hinsen's Histogram class (from the
> Scientific package) to N dimensions, I ran across the problem of how to
> apply a function to an array for a specified set of indices. 

If I understand what you are trying to do, there is a function called 
arraymap in the SciPy package (special module) (it was in the Numeric source 
for a short time but I think we decided to take it out --- I can't remember 
why).

I think that using this function and a combination of take and put can do 
what you describe.

It is available as scipy.special.arraymap

Best regards,

Travis Oliphant

[Numpy-discussion] Character typecode

[Jochen <jo...@un...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to the manual there is a typecode 'Character'. But the
following program gives an error:
,----
| import Numeric as num
| data = num.array([1,2,3], num.Character)
`----
,----
| Traceback (most recent call last):
|   File "<stdin>", line 2, in ?
| AttributeError: 'module' object has no attribute 'Character'
`----

This is python-2.2, latest NumPy cvs. The following line fixes
that. Any reason that isn't in there?

Index: Lib/Precision.py
===================================================================
RCS file: /cvsroot/numpy/Numerical/Lib/Precision.py,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Precision.py
- --- Lib/Precision.py    2000/01/13 21:23:06     1.1.1.1
+++ Lib/Precision.py    2002/01/27 15:30:50
@@ -33,6 +33,7 @@
             return typecode
     raise PrecisionError, key+" of "+str(required_bits)+" bits not available on this system"
 
+Character = 'c'
 UnsignedInt8 = 'b'
 
 try: Int0 = _lookup(_code_table, 'Integer', 0)


Greetings,
Jochen

PS: The manual page http://pfdubois.com/numpy/html2/numpy-6.html is
    really messed up right at the spot where typecodes are
    explained. That is with Netscape-4.7 and Mozilla-0.9.7 on Linux
    and Win2000.

PPS: What format is the manual master deocument in? Would it be
     feasible to generate info pages from that?
- -- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6-cygwin-fcn-1 (Cygwin)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>

iD8DBQE8VB5XiJ/aUUS8zY4RAhIxAJ43vXeTvN0hlbVmCsSCGCGYrt2m/wCeOvH8
lodh8d0YmJy0eCqMyglNdj0=
=z/Wo
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] kdf file format I/O routine

[Magnus L. H. <ma...@he...>]

ca...@ki... <ca...@ki...>:
...
> The license should be BSD? GPL? LGPL? any comment is welcome, because i
> never understood these problem (it is my first project, didn't i tell
> you?).

If you don't specifically want to follow the philosophy of the GPL,
I'd suggest that you go with some BSD variant (e.g. MIT, which is even
simpler). That way, you place less restrictions on its
use/distributions, and more people can/will use it.

(YMMV, of course.)

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

[Numpy-discussion] kdf file format I/O routine

[<ca...@ki...>]

Hy,
this is my first attempt to give some back to the python/numerical-python
community.
Here (http://kdfio.sourceforge.net) you can find an early release of my
I/O routine for reading and writing kdf file as in khoros environment.
Khoros (from http://www.khoral.com) is an interactive program for digital
image processing, we are using in our lab (university of heidelberg).
All the time i've found hard to use such environment because it
lacks some flexibility i need.
Now i've been using numerical python for some time and i would other will
use it as standard base for numerical computation, but for my purpose it
was lacking I/O with such an environment (khoros).
Khoros is not free, but anyway if you are using it i hope you will like
these routines to read and write their files.
These  are in an early stage, so expect a lot of bugs, missing feature and
so on: it's only my first project so feedbacks, suggestions and complains
are welcome.
Ops, i've forgotten: i'm personally using this rotines for my PHD, so they
should be reasonably stable.
The license should be BSD? GPL? LGPL? any comment is welcome, because i
never understood these problem (it is my first project, didn't i tell
you?).

best regards to all GREAT folks in this group,
antonio cavallo


ps. you can download khoros if you are a student from:
http://www.khoral.com/khoros/kp2001_student

[Numpy-discussion] Column in IEEE trans Antennas and Propagation

[Rob <ro...@py...>]

I've been asked to write a short column about Numpy and my web site in
IEEE AP, for the Educational Corner.  I still consider myself a Numpy
neophyte, but perhaps thats the beauty of Python, being able to do neat
things without being an expert.  I am pondering what to write about on
the Numpy side.  I am soliciting any genious ideas for topics :)  The
first thing I thought of is that I just plain enjoy being able to tweek
code without worrying about compilers.  Second, the code ends up so much
more readable than Fortran or C.  Thirdly, vectorizing the ported code
makes it look much more like the mathematical basis of the program.
Lastly, I think its the perfect language for students learning
algorithms.  I'm open to any ideas.  Thanks,  Rob.  
-- 
The Numeric Python EM Project

www.pythonemproject.com

[Numpy-discussion] amap: new function / ufunc method?

[John J. L. <jj...@po...>]

Having written all this down, I'm half-expecting somebody is going to
point out some simple way of doing this with existing builtin functions,
but here goes...

In the process of 'porting' Konrad Hinsen's Histogram class (from the
Scientific package) to N dimensions, I ran across the problem of how to
apply a function to an array for a specified set of indices.  In this
case, the problem is to increment an N-dimensional array for each of a set
of indices.  In general, it occurred to me that it would be useful to have
a function (named 'amap' here) to loop over a specified set of indices,
applying a function to a set of arguments taken from a set of argument
arrays (similar to the map buitin function in this respect), and filling
in the corresponding elements in a target array with the results.  For
example, here is a bit of the histogram problem:

[The original 1D Histogram class uses a clever array-broadcasting trick
which creates intermediate rank-2 arrays, feeding in the data in chunks to
avoid quadratic behaviour.  This is fine with 1D arrays, but in poor taste
for the N dimensional case, if it works at all.]


#!/usr/bin/env python
import Numeric as N

def flatten_indices(shape, indices):
    dims = indices.shape[0]
    facs = pow(shape, N.arange(dims))[::-1,N.NewAxis]
    return N.add.reduce(facs*indices)

def amap(target, function, indices, *arg_arrays):
    indices = N.asarray(indices)
    arg_arrays = map(N.asarray, arg_arrays)
    if not isinstance(target, N.ArrayType):
        raise TypeError, "target must be an array"
    if not target.iscontiguous():
        raise ValueError, "target must be contiguous"
    if not N.alltrue([aa.iscontiguous() for aa in arg_arrays]):
        raise ValueError, "all arg_arrays must be contiguous"
    if not len(indices.shape) == 1:
        raise ValueError, "indices must be rank-1"
    tf = target.flat
    for index in indices:
        args = [arg_array.flat[index] for arg_array in arg_arrays]
        tf[index] = function(*args)

# construct a 2 dimensional histogram given indices, ind, of data points
nbins = (5, 4)  # 5 bins along one axis, 4 along the other
histo = N.zeros(nbins)  # empty histogram
# these are the indices into the histogram at which data points lie:
# histo[1,0] should be incremented twice, histo[2,2] should be incremented
# once, etc.
ind = N.array([[1, 1, 2, 4],
               [0, 0, 2, 3]])
flat_ind = flatten_indices(histo.shape, ind)
assert flat_ind == N.array([4, 4, 10, 19])
# Now we want to increment histo for each index pair ind[:,n] (in this
# 2D case)
def increment(x): return x+1
amap(histo, increment, flat_ind, histo)
print histo


Actually, I just realised that calling it something related to 'map' is
rather misleading, because the builtin Python map generates a list of the
same length as the sequence passed in; this function doesn't: it
'generates' (fills in, in fact) an array of the same size as the target
passed in.  Can't think of a better name, though.

So: is there a way of doing this (implementing amap) efficiently already?
I don't think there is, but I'd be interested to be proved wrong.

I admit I don't like the relatively large number of arguments, but I still
think it is worthwhile.  You could make the *arg_arrays a single argument,
and make target an optional argument, at the end of the arguments:

def amap(function, indices, arg_arrays, target=None):


so that by default, the target array is first created as zeros, then
filled in and returned, or perhaps even better:

def amap(function, arg_arrays, indices=None, target=None):


though the special case where you don't give the indices argument is
already achievable without this function, so it could be argued that
hiding away the indices argument as a mere optional argument obscures the
real point of the function.  The last form also has the (debatable)
benefit of being similar to the built-in Python map:

def map(function, *args):


The example call above then looks like this:

histo = amap(increment, [histo], indices=flat_ind)


Another couple of tweaks might be to allow scalar values to replace the
arg_arrays argument, and to allow normal indices rather than flattened
ones (the only reason I started out with flat indices was that put() did
the same):

def amap(function, args, indices=None, target=None):


So that the example call looks like:

histo = amap(increment, [histo], indices=ind)


or

histo = amap(Numeric.add, [histo, 1], ind)


I like those last two.  Even if there is already an efficient way of doing
this with existing Numeric functions, I think this is a natural way of
thinking about some operations on arrays -- this one, at least -- and
would be useful to have in Numeric.

For real efficiency, I suppose the right thing to do would be to have a
map method on ufuncs, as is the case for reduce:

histo = Numeric.add.map([histo, 1], ind)


but it would be more work to implement than just a standard function, and
less general.


I've made a first attempt at the function, in C (will upload diff against
20.2.0 if anyone so requests).  It only accepts one arg array, probably
doesn't really do exactly the same as the Python function above (for
better or worse), and it's a mess of a function, since I rarely write
anything in C.  It is also incorrect in at least some ways (most
obviously, it only deals with Python floats / C doubles / Numpy
PyArray_DOUBLEs), though there are some tests (which pass).

I'm wasn't sure how fast it would be, since after all it's only using
ordinary Python functions, not ufuncs, but my crude tests appeared to show
an improvement of about a factor of two over an optimised version of the
Python function above.  The slow bit seems to be constructing the argument
list / passing arg list to function, so I removed that to make the
comparison, along with an unecessary attribute access in the loop.
Presumably the general (> 1 arg_array) version would show a bigger
improvement over the corresponding Python version.

By the way, does anyone understand what the reduceat ufunc method is
supposed to do?  Seems to be the Beale cipher of Numeric -- having studied
its output to see if it was the function I was looking for, I can find no
sense in it and kind of suspect that it was constructed only to keep us
puzzling. ;) Is Jim Hugunin not available for comment on the matter, or is
this somebody else's dirty work?


John

Re: [Numpy-discussion] memory-mapped Numeric arrays: arrayfrombuffer version 2

[Konrad H. <hi...@cn...>]

Kragen Sitaker <kr...@po...> writes:

> There is one thing in arrayfrombuffer.c I'm not sure about, and
> I could use some help here.  arrayobj is the return value from
> PyArray_FromDimsAndData:
>   /* do I need to incref arrayobj?! fromstring does... */
>   return (PyObject*)arrayobj;
> }
> 
> So, do I?  Or not?  It seems to work as it is.

And it is correct, in my opinion. Your routine is the owner of the
array (and no one else keeps a reference), so you just pass on
ownership. Doing an INCREF here would mean that the array is never
freed. (Keep in mind that the data area is never freed anyway!)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] RE: memory-mapped Numeric arrays: arrayfrombuffer version 2

[Eric N. <no...@ph...>]

Since I have a 2.4GB data file handy, I thought I'd try this package
with it.  (Normally I process this data file by reading it in a chunk
at a time, which is perfectly adequate.)  Not surprisinly, it chokes:


  File "/home/eric/lib/python2.2/site-packages/maparray.py", line 15,
  in maparray
    m = mmap.mmap(fn, os.fstat(fn)[stat.ST_SIZE])
OverflowError: memory mapped size is too large (limited by C int)


(details: Python 2.2, numpy 20.3, Pentium III, Debian Woody, Linux
kernel 2.4.13, gcc 2.95.4)

I'm not a big C programmer, but I wonder if there is some way for this
package to overcome the 2GB limit on 32-bit systems.  That could be
useful in some situations.

Eric



On Fri, Jan 25, 2002 at 09:40:21AM -0800, Paul F. Dubois wrote:
> 
> I have verified that this package seems to work on Windows. I says seems
> only because I didn't try enough to uncover anything subtle.
> 
> Unless or until we are convinced as a community that this is (a) the
> right way to do this and (b) that the package is portable, it would not
> be wise to put it in the main distribution. 
> 
> I would like to hear from the community about this so that I will know
> whether or not to add this package as a separate SourceForge 'package'
> within the Numerical Python area. Meantime I will add a link to the web
> page.
> 
> From: pyt...@py...
> [mailto:pyt...@py...] On Behalf Of Kragen
> Sitaker
> Sent: Wednesday, January 23, 2002 9:40 PM
> To: pyt...@py...
> Subject: memory-mapped Numeric arrays: arrayfrombuffer version 2
> 
> 
> The 'arrayfrombuffer' package features support for Numerical Python
> arrays whose contents are stored in buffer objects, including
> memory-mapped files.  This has the following advantages:
> 
> - loading your array from a file is easy --- a module import and a
>   single function call --- and doesn't use excessive amounts of
>   memory.
> - loading your array is quick; it doesn't need to be copied from one
>   part of memory to another in order to be loaded.
> - your array gets demand-loaded; parts you aren't using don't need to
>   be in memory or in swap.
> - under memory-pressure conditions, your array doesn't use up swap,
>   and parts of it you haven't modified can be evicted from RAM without
>   the need for a disk write
> - your arrays can be bigger than your physical memory
> - when you modify your array, only the parts you modify get written
>   back out to disk
> 
> This is something that's been requested on the Numpy list a few times a
> year since 1999.
> 
> arrayfrombuffer lives at http://pobox.com/~kragen/sw/arrayfrombuffer/
> The current version is version 2; it is released under the X11 license
> (the BSD license without the advertising clause).
> 
> <kr...@po...>
> 
> <P><A
> HREF="http://pobox.com/~kragen/sw/arrayfrombuffer/">arrayfrombuffer
> 2</A> - creates Numeric arrays from memory-mapped files.  (23-Jan-02)
> 

-- 
********************************
Eric Nodwell
Ph.D. candidate
Department of Physics
University of British Columbia

tel: 604-822-5425
fax: 604-822-4750
no...@ph...

[Numpy-discussion] RE: memory-mapped Numeric arrays: arrayfrombuffer version 2

[Paul F. D. <du...@ll...>]

I have verified that this package seems to work on Windows. I says seems
only because I didn't try enough to uncover anything subtle.

Unless or until we are convinced as a community that this is (a) the
right way to do this and (b) that the package is portable, it would not
be wise to put it in the main distribution. 

I would like to hear from the community about this so that I will know
whether or not to add this package as a separate SourceForge 'package'
within the Numerical Python area. Meantime I will add a link to the web
page.

-----Original Message-----
From: pyt...@py...
[mailto:pyt...@py...] On Behalf Of Kragen
Sitaker
Sent: Wednesday, January 23, 2002 9:40 PM
To: pyt...@py...
Subject: memory-mapped Numeric arrays: arrayfrombuffer version 2


The 'arrayfrombuffer' package features support for Numerical Python
arrays whose contents are stored in buffer objects, including
memory-mapped files.  This has the following advantages:

- loading your array from a file is easy --- a module import and a
  single function call --- and doesn't use excessive amounts of
  memory.
- loading your array is quick; it doesn't need to be copied from one
  part of memory to another in order to be loaded.
- your array gets demand-loaded; parts you aren't using don't need to
  be in memory or in swap.
- under memory-pressure conditions, your array doesn't use up swap,
  and parts of it you haven't modified can be evicted from RAM without
  the need for a disk write
- your arrays can be bigger than your physical memory
- when you modify your array, only the parts you modify get written
  back out to disk

This is something that's been requested on the Numpy list a few times a
year since 1999.

arrayfrombuffer lives at http://pobox.com/~kragen/sw/arrayfrombuffer/
The current version is version 2; it is released under the X11 license
(the BSD license without the advertising clause).

<kr...@po...>

<P><A
HREF="http://pobox.com/~kragen/sw/arrayfrombuffer/">arrayfrombuffer
2</A> - creates Numeric arrays from memory-mapped files.  (23-Jan-02)

-- 
http://mail.python.org/mailman/listinfo/python-announce-list

[Numpy-discussion] memory-mapped Numeric arrays: arrayfrombuffer version 2

[Kragen S. <kr...@po...>]

I would be very happy if this got included in the
Numpy distribution, so that people don't have to do an extra
download to get this facility.  I just submitted it as a patch
on SourceForge, but my browser failed to upload the file.
http://sourceforge.net/tracker/index.php?func=detail&aid=507847&group_id=1369&atid=301369

There is one thing in arrayfrombuffer.c I'm not sure about, and
I could use some help here.  arrayobj is the return value from
PyArray_FromDimsAndData:
  /* do I need to incref arrayobj?! fromstring does... */
  return (PyObject*)arrayobj;
}

So, do I?  Or not?  It seems to work as it is.

Following is the announcement I posted to comp.lang.python and (hopefully)
comp.lang.python.announce.

The 'arrayfrombuffer' package features support for Numerical Python
arrays whose contents are stored in buffer objects, including
memory-mapped files.  This has the following advantages:

- loading your array from a file is easy --- a module import and a
  single function call --- and doesn't use excessive amounts of
  memory.
- loading your array is quick; it doesn't need to be copied from one
  part of memory to another in order to be loaded.
- your array gets demand-loaded; parts you aren't using don't need to
  be in memory or in swap.
- under memory-pressure conditions, your array doesn't use up swap,
  and parts of it you haven't modified can be evicted from RAM without
  the need for a disk write
- your arrays can be bigger than your physical memory
- when you modify your array, only the parts you modify get written
  back out to disk

This is something that's been requested on the Numpy list a few times
a year since 1999.

arrayfrombuffer lives at
http://pobox.com/~kragen/sw/arrayfrombuffer/
The current version is version 2; it is released under the X11 license
(the BSD license without the advertising clause).

[Numpy-discussion] yacvsu

[Paul D. <pa...@pf...>]

yet-another-cvs-update

Disregarding advice from wiser heads, I made setup.py generate
rpm_install.sh so that it would execute setup.py with the "right" python.
Works for me (TM) in the sense that the rpm builds. I'm afraid to test it
because I don't want my system ruined. We need some words someplace about
how one uses these rpms. I suppose the web site is the right place.

Also new in this issue is an upgrade to MA.average to allow axial weights as
Numeric now does.

I replaced all memcpy's with memmove's due to a bug report. If someone
thinks this is a hideous decision just let me know why.

Re: [Numpy-discussion] cvs checkins for rpms

[Jochen <jo...@jo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22 Jan 2002 00:26:33 -0500 Jochen Küpper wrote:


Jochen> ,----[python setup.py bdist_rpm]
[...]
Jochen> | + setup.py install --root=/var/tmp/Numeric-buildroot
Jochen> | /var/tmp/rpm-tmp.35738: setup.py: command not found
Jochen> | error: Bad exit status from /var/tmp/rpm-tmp.35738 (%install)
Jochen> `----

Looking at my own message I realize that the following patch is all
that is needed. '.' shouldn't be in your path, it definitely won't be
in mine.

Index: rpm_install.sh
===================================================================
RCS file: /cvsroot/numpy/Numerical/rpm_install.sh,v
retrieving revision 1.1
diff -u -r1.1 rpm_install.sh
- --- rpm_install.sh      2002/01/22 04:39:53     1.1
+++ rpm_install.sh      2002/01/22 05:39:50
@@ -1,4 +1,4 @@
- -setup.py install --root=$RPM_BUILD_ROOT
+./setup.py install --root=$RPM_BUILD_ROOT
 
 cat >INSTALLED_FILES <<EOF
 %doc Demo

Greetings,
Jochen
- -- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: 44BCCD8E
        Sex, drugs and rock-n-roll
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>

iD8DBQE8TPuQiJ/aUUS8zY4RApgcAJ4mlgsdCbJoiXnF4s4IyENE1m+D2ACfXdGU
dtpO/3TQEiV+kjY79ZmDUPE=
=/wKD
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] cvs checkins for rpms

[Jochen <jo...@jo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 21 Jan 2002 20:39:47 -0800 Paul F Dubois wrote:

Paul> Includes new files setup.cfg and rpm_install.sh from Gerard
Paul> Vermeulen.

,----[python setup.py bdist_rpm]
| [...]
| building 'kinds._kinds' extension
| gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/local/include/python2.2 -c Packages/kinds/Src/_kindsmodule.c -o build/temp.linux-i686-2.2/_kindsmodule.o -O2 -march=i386 -mcpu=i686
| Packages/kinds/Src/_kindsmodule.c:15: warning: function declaration isn't a prototype
| gcc -shared build/temp.linux-i686-2.2/_kindsmodule.o -o build/lib.linux-i686-2.2/kinds/_kinds.so
| MA Version 11.1.0
| Properties Version 2.2
| kinds Version 1.1
| Numeric Version 21.0a2
| + exit 0
| Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.35738
| + umask 022
| + cd /home/software/programming/numeric/NumPy/build/bdist.linux-i686/rpm/BUILD
| + cd Numeric-21.0a2
| + setup.py install --root=/var/tmp/Numeric-buildroot
| /var/tmp/rpm-tmp.35738: setup.py: command not found
| error: Bad exit status from /var/tmp/rpm-tmp.35738 (%install)
`----

Greetings,
Jochen
- -- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: 44BCCD8E
        Sex, drugs and rock-n-roll
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>

iD8DBQE8TPgIiJ/aUUS8zY4RArEoAJ0SsWQT+F3DNfh+YTaqk8lXpXsbzgCfQe27
GjZ+/DrL9sYbjPj3Ma+VLV4=
=17Dr
-----END PGP SIGNATURE-----

[Numpy-discussion] cvs checkins for rpms

[Paul F. D. <pa...@pf...>]

Version 21.0a2 is now in cvs awaiting community testing. Especially to
be tested are rpm creation, Windows installer creation. Includes new
files setup.cfg and rpm_install.sh from Gerard Vermeulen.

Re: [Numpy-discussion] Please help me test a new setup.py

[Gerard V. <gve...@po...>]

If I do

setup.py bdist_rpm

then 'Numeric.pth' does not end up in the binary RPM with Python-2.1.1

The reason is that rpm does something like

setup.py install --root=~/tmp --record=record.txt

and apparently the distutils part that handles --record is broken as
shown by 'grep pth record.txt'.

Paul, do you want me to 'fix' distutils (meaning overriding the
install command, so that record.txt contains all files)? Or are you
willing to use the pth_install_data class that does not work on Windows?

Gerard

On Thursday 17 January 2002 23:05, Paul F. Dubois wrote:
> Working from something given to me by Gerard Vermeulen I have tried to
> improve Numeric's setup.py. This is now in CVS. I could use help testing
> it, particularly by the those whose brains are RPM-enabled. Those Numpy
> developers who have not done a damn thing lately are granted this chance
> for redemption. (:->
>
> There is no more setup_all.py; rather, setup.py builds everything. It
> has, however, a structure that enables easy commenting-out of any
> optional packages.
>
> I have made and tested the Windows packages and installer; and made and
> tested Linux packages and have made but not tested the Linux RPM. (sh
> makedist.sh).
>
> If trying this on a Python will Numeric already installed, remove first
> from site-packages:
> Numeric.pth, Numeric, FFT, RNG, MA, kinds, PropertiedClasses
>
> Under the new scheme, Numeric.pth points to Numeric and the directories
> for the others are INSIDE Numeric. Everything should be backward
> compatible. I like this; it reduces the visible pollution in
> site-packages.
>
> The RPM produced does not contain the documentation (that runs into a
> distutils bug in older Pythons). It does not have a name beginning with
> python- because that screwed up something else. In short, it is a
> compromise. Once we're all convinced that what I have works then we can
> worry about the finer stuff.
>
> A nice side benefit is that there is now only one Windows .exe
> installer, and only one thing to uninstall in add/remove programs.
>
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Re: viewing Gridded or Polar data?

[Rob H. <ro...@ho...>]

I wrote a program to display X-ray diffraction images. The display engine
is available as "dis.py" from http://starship.python.net/crew/hooft/

Regards,

Rob Hooft

-- 
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/

[Numpy-discussion] Please help me test a new setup.py

[Paul F. D. <pa...@pf...>]

Working from something given to me by Gerard Vermeulen I have tried to
improve Numeric's setup.py. This is now in CVS. I could use help testing
it, particularly by the those whose brains are RPM-enabled. Those Numpy
developers who have not done a damn thing lately are granted this chance
for redemption. (:->

There is no more setup_all.py; rather, setup.py builds everything. It
has, however, a structure that enables easy commenting-out of any
optional packages.

I have made and tested the Windows packages and installer; and made and
tested Linux packages and have made but not tested the Linux RPM. (sh
makedist.sh).

If trying this on a Python will Numeric already installed, remove first
from site-packages:
Numeric.pth, Numeric, FFT, RNG, MA, kinds, PropertiedClasses

Under the new scheme, Numeric.pth points to Numeric and the directories
for the others are INSIDE Numeric. Everything should be backward
compatible. I like this; it reduces the visible pollution in
site-packages. 

The RPM produced does not contain the documentation (that runs into a
distutils bug in older Pythons). It does not have a name beginning with
python- because that screwed up something else. In short, it is a
compromise. Once we're all convinced that what I have works then we can
worry about the finer stuff.

A nice side benefit is that there is now only one Windows .exe
installer, and only one thing to uninstall in add/remove programs.

Re: [Numpy-discussion] viewing Gridded or Polar data?

[Adrian F. <fe...@ma...>]

You can take a look at SciGraphica at http://scigraphica.sourceforge.net.
Although it is mainly GUI based, it has a python interface under
development. You can ask in the scigraphica mailing list for a plugin for
reading netcdf files, I remember someone posting it. Saludos,
<ADRIAN>

On Thu, 17 Jan 2002, Joe Van Andel wrote:

> 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: van...@uc...
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 

RE: [Numpy-discussion] viewing Gridded or Polar data?

[Paul F. D. <pa...@pf...>]

We will answer you again shortly and include an example of how to do
this in cdat (cdat.sf.net). You can do it using our GUI or from the
Python command line.

cdat includes a colormap editor for getting things just the way you
want, and a variety of graphics methods including box fill, isofill,
isoline, etc. It can open a wide variety of data files including netcdf.

Our name, Climate Data Analysis Tools, is a bit misleading. There are
special facilities for climate modelers, and a variety of statistics and
other algorithms that they need, but the package is a general-purpose
one.

-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of Joe
Van Andel
Sent: Thursday, January 17, 2002 6:47 AM
To: numpy-discussion
Subject: [Numpy-discussion] viewing Gridded or Polar data?


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: van...@uc...

_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] viewing Gridded or Polar data?

[Eric N. <no...@ph...>]

You might want to have a look at Gri (http://gri.sourceforge.net/).
Gri can read netCDF files.

Here's the little blurb from their site:

"Gri is a language for scientific graphics programming. The word
"language" is important: Gri is command-driven, not point/click. Some
users consider Gri similar to LaTeX, since both provide extensive
power as a reward for tolerating a learning curve.  Gri can make x-y
graphs, contour graphs, and image graphs. The output is in
PostScript..."

Since gri is command-driven, it's easy to call it from within python.

Gri won't display the data for you - it will only generate the
PostScript file, which you can then display with any number of tools.

Eric



On Thu, Jan 17, 2002 at 07:46:52AM -0700, Joe Van Andel wrote:
> 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!
> 

Re: [Numpy-discussion] viewing Gridded or Polar data?

[Scott R. <ra...@sp...>]

Hi Joe,

There are C and Python wrappers around the very nice PGPLOT library that do
exactly what you want (and a whole lot more).  You can find them here:

ftp://cfa-ftp.harvard.edu/pub/ransom

The files you need are:

ppgplot-0.11.tar.gz (the C wrappers)
Pgplot.py           (the Python wrappers around the C wrappers)

Lots of additional information about the capabilities of PGPLOT can be found
at its web page:  http://www.astro.caltech.edu/~tjp/pgplot/

With my current setup, you can do a lot of plotting (except 3D stuff) in a
manner that is very much like IDL (a single function call with lots of
optional keyword arguments).

I haven't modified it in quite awhile, but still use it in my own work
almost every day.

As for reading netCDF, I would recommend Konrad Hinsen's Scientific Python:

http://starship.python.net/crew/hinsen/scientific.html

Good luck,

Scott

On Thu, Jan 17, 2002 at 07:46:52AM -0700, Joe Van Andel wrote:
> 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: van...@uc...
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
-- 
Scott M. Ransom              Address:  McGill Univ. Physics Dept.
Phone:  (514) 398-6492                 3600 University St., Rm 338
email:  ra...@ph...       Montreal, QC  Canada H3A 2T8 
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

Re: [Numpy-discussion] viewing Gridded or Polar data?

[Jon S. <js...@wm...>]

I have never tried exactly this type of plot, but I guess that a
combination of GrADS commands like the following ones in a script:

grads -l << EOF
sdfopen yourfile.nc (for COARDS-compliant netCDF files)
set gxout grfill (to get a colour-filled grid)
set clevs 10 20 30 40 50 (and so on to define your intervals...)
d variable_name (of the netCDF file)
enable print your_plot_name.gm
print
disable print
quit
EOF
gxeps -c your_plot_name

should do the work and prepare an EPS file.

GrADS handles netCDF files, in case they conform to the COARDS standard.
Otherwise, you can define the data in the file and use the xdfopen
command, but this is more complex than above.

http://grads.iges.org is their homepage.

Hope this helps.

Jon Saenz.				| Tfno: +34 946012445
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

On Thu, 17 Jan 2002, Joe Van Andel wrote:

> 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: van...@uc...
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 

Re: [Numpy-discussion] viewing Gridded or Polar data?

[Rob <ro...@py...>]

Animabob does that but I don't think it specificially handles NetCDF
files.  You can define your own color mapping file with Animabob. 
OpenDX has that capasbility.  I've tried OpenDX, but all versions
FreeBSD, and Cygwin that I tried dumped core upon trying to plot. 
Perhaps they've fixed that- it was fixed in CVS but not in the dist
files.

Rob.


Joe Van Andel wrote:
> 
> 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: van...@uc...
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
The Numeric Python EM Project

www.pythonemproject.com

[Numpy-discussion] viewing Gridded or Polar data?

[Joe V. A. <van...@at...>]

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: van...@uc...