From diab@camelot-it.com  Sat Jul  3 13:55:14 1999
From: diab@camelot-it.com (diab)
Date: Sat, 03 Jul 1999 14:55:14 +0200
Subject: [Matrix-SIG] sparse Matrix.
Message-ID: <377E0832.5A9DCBA7@camelot-it.com>

Hi,

I just started working with Python (with the numeric extension).
The matrices I use are sparse and most of the operations
are : addition,multiplication  and transpose. Since I intend to use
matrices with a large size (1000X1000000), I would like to know if
there is extension that implement sparse matrices.

Your help is very appreciated.

Thanks,
Diab.



From HYoon@exchange.ml.com  Wed Jul  7 21:03:56 1999
From: HYoon@exchange.ml.com (Yoon, Hoon (CICG - NY Program Trading))
Date: Wed, 7 Jul 1999 16:03:56 -0400
Subject: [Matrix-SIG] Strange equal behavior
Message-ID: <A1AFC4253BA3D111BFF70001FA7E9AACD62186@ewfd19.exchange.ml.com>

Hi,

  I think I pose this type of Q's little too often, but everytime I thought
I had good handle on this subject, I get this kinda screwy results. Has
anyone have fix for this? I am using LLNL distribution 11 on NT svc pack 3.
Before this I thought I had missings nearly tackled. :(
  Thanks in adv,

1.#QNAN is generated by C++ code:
#define ISMISSINGVAL(A)   ( (*((unsigned short *)(A)+3) & (unsigned
short)0x7FFF) > (unsigned short)0x7FF0 )
#define MKMISSINGVAL(A)   ( *((unsigned int *)(A)+1) = 0x7fffffff,
*((unsigned int *)(A)) = (unsigned int)0 )

C:\Python\AddPy>python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from NumpyA import *
>>> NA
1.#QNAN
>>> equal(0,NA)
1
>>> z = 1e1000/1e1000
>>> z
-1.#IND
>>> equal(0,z)
1

**************************************************************
S. Hoon Yoon                   (Quant)                    Merrill Lynch
Equity Trading 
yelled@yahoo.com hoon@bigfoot.com(w)
"Miracle is always only few standard deviations away, but so is
catastrophe."
* Expressed opinions are often my own, but NOT my employer's.
"I feel like a fugitive from the law of averages."    Mauldin
**************************************************************



From collins@seal.aero.org  Fri Jul  9 23:38:50 1999
From: collins@seal.aero.org (Jeff Collins)
Date: Fri, 9 Jul 1999 15:38:50 -0700
Subject: [Matrix-SIG] Compile problem
Message-ID: <199907092238.PAA26391@malibu.sipnet>


I'm trying to run the function "test" in the following shared extension
module.  Under irix6.5 (compiled with g++ in egcs-1.1.2), a
segmentation fault occurs as it executes the cout statement.  It works
fine with the same compiler on Solaris-5.6.  Any ideas what might be
going wrong?  In both cases, Python-1.5.2 was compiled with gcc
(egcs-1.1.2) and g++ was used for the shared object linking.  

This is the simplest form of the problem I'm having.  It first
appeared in an attempt to create python wrappers for a custom c++
wrapping of fftw; calls to those functions failed in the same way.

Thanks,

Jeff
--------------------------------------------------------------------------------



#include "Python.h"
#include <complex.h>
#include <iostream.h>


static
PyObject *jnk_test (PyObject *self, PyObject *args)
{
	complex<double> *a;

	if (!PyArg_ParseTuple(args, ""))
		return NULL;

	printf("before a\n");
	a = new complex<double>(0,1);
	printf("a = %g %g\n", real(*a), imag(*a));

	delete a;

	printf("before cout\n");
	cout << "some stuff" << endl;

	Py_INCREF(Py_None);
	return Py_None;

}

static PyMethodDef jnk_methods[] = {
	{"test", (PyCFunction) jnk_test, 1},
	{NULL, NULL}
};

#ifdef __cplusplus
extern "C" {
#endif

void
initjnk()
{
	PyObject *m;
	
	m = Py_InitModule("jnk", jnk_methods);
	if (PyErr_Occurred())
		Py_FatalError("Can't initialize module jnk");
}
#ifdef __cplusplus
}
#endif


From Oliphant.Travis@mayo.edu  Mon Jul 12 04:00:32 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sun, 11 Jul 1999 22:00:32 -0500 (CDT)
Subject: [Matrix-SIG] Re: Example Code: Bresenham Line Algorithm
In-Reply-To: <7m9tln$6qg$4@rks1.urz.tu-dresden.de>
References: <7m9tln$6qg$4@rks1.urz.tu-dresden.de>
Message-ID: <Pine.LNX.4.10.9907112154520.15581-100000@us2.mayo.edu>

Phillip,

I'm not sure what the Bresenham Line Algorithm does.  If you could send me
a brief description, I could evaluate whether or not I'd like to include
it in the package that I'm developing (Multipack), which builds on the
NumPy array extension to give Python the numerical convenience (and
eventually the graphical convenience) of common interactive data analysis
packages like MATLAB.

I'm posting this to the newsgroup to remind other individuals who would
like to contribute to such an effort that they can send their code to me
(Oliphant.Travis@altavista.net).  For people who are really interested in
this there is even a CVS server where development takes place.

Thanks, 

Travis Oliphant









From pearu@ioc.ee  Mon Jul 12 14:44:58 1999
From: pearu@ioc.ee (Pearu Peterson)
Date: Mon, 12 Jul 1999 16:44:58 +0300 (EETDST)
Subject: [Matrix-SIG] Fortran to Python Interface Generator
Message-ID: <Pine.HPX.4.05.9907121554370.18865-100000@egoist.ioc.ee>

Travis and others interested in doing fast math in Python:

Now I have a first working alpha version of f2py.py --- a Fortran to
Python Interface Generator.
Travis: you can checkout f2py.py from the CVS server under module named
f2py.

I think you will be interested in the test results below.

For a first test I took ddot.f --- it contains Level 1 BLAS function ddot
for finding a dot product of two vectors.
Now
> f2py.py -mblas tests/ddot.f
will create a file blasmodule.c, that is a Python-C API module and can be
compiled in a standard way.

Below you will find two sets of test results. One uses standard BLAS
library and the other optimized BLAS library for Intel. In both cases
comparison is carried out against Numeric function Numeric.dot.
In all test cases 10 000 iterations were made.

These tests show that blas.ddot is approx 80% faster than Numeric.dot for
small length vectors (length<=500). For standard BLAS the difference
decreases approx to 60% for vectors having length of few thousand. And
then rapidly decreases to 14% (to be still faster) for vectors with
a length of 10 thousand.
But note that when using optimized BLAS this rapid decrease is not
happening: blas.ddot will remain to be more than 50% faster than
Numeric.dot for very lengthy vectors.

Pearu

********* Standard BLAS **********
> python test.py
retval = _ddot(n,dx,incx,dy,incy)
Numeric.dot(x,y)= 249.301376637
blas.ddot(x,y)= 249.301376637

Length of vectors = 10
Numeric.dot:  1.0199 seconds
blas.ddot:  0.1447 seconds
blas.ddot  is 85.81% faster.

Length of vectors = 50
Numeric.dot:  0.858 seconds
blas.ddot:  0.1546 seconds
blas.ddot  is 81.98% faster.

Length of vectors = 100
Numeric.dot:  0.892 seconds
blas.ddot:  0.1685 seconds
blas.ddot  is 81.11% faster.

Length of vectors = 500
Numeric.dot:  1.0237 seconds
blas.ddot:  0.2575 seconds
blas.ddot  is 74.85% faster.

Length of vectors = 1000
Numeric.dot:  1.3121 seconds
blas.ddot:  0.4935 seconds
blas.ddot  is 62.39% faster.

Length of vectors = 5000
Numeric.dot:  2.2982 seconds
blas.ddot:  1.8268 seconds
blas.ddot  is 20.51% faster.

Length of vectors = 10000
Numeric.dot:  4.4357 seconds
blas.ddot:  3.8062 seconds
blas.ddot  is 14.19% faster.

*********** Optimized BLAS ***********
> python test.py
retval = _ddot(n,dx,incx,dy,incy)
Numeric.dot(x,y)= 254.269018269
blas.ddot(x,y)= 254.269018269

Length of vectors = 10
Numeric.dot:  0.872 seconds
blas.ddot:  0.1411 seconds
blas.ddot  is 83.81% faster.

Length of vectors = 50
Numeric.dot:  0.8596 seconds
blas.ddot:  0.1471 seconds
blas.ddot  is 82.89% faster.

Length of vectors = 100
Numeric.dot:  0.893 seconds
blas.ddot:  0.1559 seconds
blas.ddot  is 82.55% faster.

Length of vectors = 500
Numeric.dot:  1.0232 seconds
blas.ddot:  0.2043 seconds
blas.ddot  is 80.03% faster.

Length of vectors = 1000
Numeric.dot:  1.2427 seconds
blas.ddot:  0.3484 seconds
blas.ddot  is 71.97% faster.

Length of vectors = 5000
Numeric.dot:  2.275 seconds
blas.ddot:  1.0139 seconds
blas.ddot  is 55.43% faster.

Length of vectors = 10000
Numeric.dot:  4.2813 seconds
blas.ddot:  2.0242 seconds
blas.ddot  is 52.72% faster.




From Oliphant.Travis@mayo.edu  Tue Jul 13 15:59:47 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Tue, 13 Jul 1999 09:59:47 -0500 (CDT)
Subject: [Matrix-SIG] Re: FPIG: dot with error checking
In-Reply-To: <Pine.HPX.4.05.9907131312220.871-100000@egoist.ioc.ee>
Message-ID: <Pine.LNX.4.10.9907130956330.17965-100000@us2.mayo.edu>

> Travis,
> 
> I have defined user-friendly dot(x,y) that checks which ??dot to call from
> the BLAS. I have tried also to check that x and y have the same types. If
> they are not, say, x.astype(y.typecode()) is called. It turns out this
> will be a real performance killer. With out this check my dot is
> still 50% faster than Numeric.dot, otherwise it was a little slower.
> 
> In conclusion, I think in doing the interface with f2py, the user should
> be responsible for type conversation. f2py should only result in
> very low level python functions, so that one can write maximally optimised
> code in python -- type conversation should be carried out in the top level
> of application function in order to minimise the nof calls to *.astype().
> Interface generated by f2py, should only check that the arguments are in a
> correct type --- it should not then affect the performance (I hope).
> 
> How do you feel about the policy above?

Yes, I think this is a good plan.  I think we need to empower the user and
make them responsible for a low-level tool like this.  It is always
possible to make an interface that guarantees stability on top of a raw,
optimized one (we should have basic error checking but not try to out
guess the user).

> 
> And how do you feel on continuing this conversation in matrix-sig in order
> to  grab more people into Multipack project?  
> 
> Pearu

Good idea, I'll post this to matrix-sig as well.




From Oliphant.Travis@mayo.edu  Tue Jul 13 17:24:43 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Tue, 13 Jul 1999 11:24:43 -0500 (CDT)
Subject: [Matrix-SIG] Re: FPIG: advice needed
In-Reply-To: <Pine.HPX.4.05.9907131100580.29559-100000@egoist.ioc.ee>
Message-ID: <Pine.LNX.4.10.9907131000030.17965-100000@us2.mayo.edu>

> 
> Travis,
> 
> I have found that there are number of ways how to access fortran/c raw
> functions using f2py.py from python. I need to choose one before I can
> write f2py.py any further.
> 
> Say, we have a fortran subroutine:
> subroutine f(n,x)
> integer n
> real*8 x(*)
> ... (say, fill array x of length n with ones)
> end
> In order to access it from python, the following policies are possible:

> 1) Currently implemented one generates the following python function:
>   {'n':n} = _f(n,x)
> That is if argument is of numeric type (like 'n' is int here), its value
> (if it is changed in f) can be accessed from the dictionary that _f
> returns. If argument is numeric array ('x'), its contents is accessed by
> its reference, so that _f changes x in place. But this matter makes
> checking arguments difficult: if x is assumed to be an array, but I call
> _f with x being, say, float, then it is not immidately clear how to make
> the conversation.

Why does this make it difficult to check the arguments?  You have an
"O!" in the appropriate position, if it is called with a float
argument the routine returns with an exception.

Force it to be an array.  Again, this is a low-level tool.  The user will
have to make Python wrappers (which are easier to write and maintain) if
he/she wants adjustments to the default handling.   

> Advantage is that the interface is very direct and fast --- but again, it
> works only if arguments are correct.

That's O.K.  I like this approach better.  I think I would prefer, though, 
that the dictionary contain a reference to the input argument 'x' for
completeness.  This would make it easier for the user who would know what
to expect.

O.K. wait, I think I see the trouble.  The problem is not if x is a
Python float but if is the wrong array type (say integer rather than
double).

Yes, this needs to be fixed even for a low-level tool.  The initiated user
will know that a performance hit might be taken if the routine has to copy
an integer array to a double array but at least no one will get core-dumps
for incorrect arrays being pased to raw fortran code that doesn't check
bounds.

It's not hard to make sure the array is the right type.  A call
to PyContiguous_FromObject(obj, type, min_dim, max_dim) will
do it for you. If the array is already the right type, no copying takes
place.   This also allows arbitrary sequences to be used as input
arguments, which is nice.


> 
> 2) More secure would be, if the result of f2py is python function having
> form:
>   n,x = _f(n,x)
> that is, if needed, type conversation can be implemented easily and in a
> general way. Disadvantage is that using it in a python, results a little
> longer code. For example, dswap from the blas should be always called as
> follows:
>   n,x,incx,y,incy = blas._dswap(n,x,incx,y,incy)
> instead of current shorter version:
>   blas._dswap(len(x),x,1,y,1)

I don't understand why the "longer-code" here.  Maybe I don't understand
the point you are making.  But, why couldn't you have the same calling
syntax as 1.

> Final implementation of 1) may be complex (I don't see right know how to
> avoid its problems. These could be ignored but then only correct
> arguments should be assumed). Implementation of 2) means more code but it
> seems easier to carry out and should be safer. But performance will
> probably be lower, I think.
> 
> What do you think? Which ways would you prefer as a f2py.py user?
> Or should be both ways present trough an optional key in f2py.py?

I'm not sure exactly what the concern is.  If the concern is over type
casting, then we should use PyArray_ContiguousFromObject()

Otherwise I'm not sure what the concern is here.




From pearu@ioc.ee  Tue Jul 13 19:15:36 1999
From: pearu@ioc.ee (Pearu Peterson)
Date: Tue, 13 Jul 1999 21:15:36 +0300 (EETDST)
Subject: [Matrix-SIG] Re: FPIG: advice needed
In-Reply-To: <Pine.LNX.4.10.9907131000030.17965-100000@us2.mayo.edu>
Message-ID: <Pine.HPX.4.05.9907132015550.5004-100000@egoist.ioc.ee>

On Tue, 13 Jul 1999, Travis Oliphant wrote:
> > 
> > Travis,
> > 
> > I have found that there are number of ways how to access fortran/c raw
> > functions using f2py.py from python. I need to choose one before I can
> > write f2py.py any further.

I have rewritten f2py.py on the part where *module.c is generated.
For those, how don't have access to CVS server (where Multipack is), I
have copied the relavant files to
  http://koer.ioc.ee/~pearu/python/f2py/

> > 
> > Say, we have a fortran subroutine:
> > subroutine f(n,x)
> > integer n
> > real*8 x(*)
> > ... (say, fill array x of length n with ones)
> > end
> > In order to access it from python, the following policies are possible:
> > 1) Currently implemented one generates the following python function:
> >   {'n':n} = _f(n,x)

Now f2py.py generates python function
	None = _f(n,x)
It means that _f will return always None on success (in unsuccess
exception is raised anyway --- not implemented yet; if f is function,
its value will be returned).
It is always assumed that x is an array (if fortran code requires that).
Period.

Now if x=Numeric.array([2,3],'d') then
n=len(x)
_f(n,x)
print x
should display [1.,1.].
Note that in this way the syntax of _f will be exactly the same as in
fortran code. It means that it is much easier to use _f as no changes is
needed in the documentation of fortran function f.

> > That is if argument is of numeric type (like 'n' is int here), its value
> > (if it is changed in f) can be accessed from the dictionary that _f
> > returns. If argument is numeric array ('x'), its contents is accessed by
> > its reference, so that _f changes x in place. But this matter makes
> > checking arguments difficult: if x is assumed to be an array, but I call
> > _f with x being, say, float, then it is not immidately clear how to make
> > the conversation.
> 
> Why does this make it difficult to check the arguments?  You have an
> "O!" in the appropriate position, if it is called with a float
> argument the routine returns with an exception.

I probably will use "O!" for argument checking and only.

> 
> Force it to be an array.  Again, this is a low-level tool.  The user will
> have to make Python wrappers (which are easier to write and maintain) if
> he/she wants adjustments to the default handling.   
> 
> > Advantage is that the interface is very direct and fast --- but again, it
> > works only if arguments are correct.
> 
> That's O.K.  I like this approach better.  I think I would prefer, though, 
> that the dictionary contain a reference to the input argument 'x' for
> completeness.  This would make it easier for the user who would know what
> to expect.
> 
> O.K. wait, I think I see the trouble.  The problem is not if x is a
> Python float but if is the wrong array type (say integer rather than
> double).
> 
> Yes, this needs to be fixed even for a low-level tool.  The initiated user
> will know that a performance hit might be taken if the routine has to copy
> an integer array to a double array but at least no one will get core-dumps
> for incorrect arrays being pased to raw fortran code that doesn't check
> bounds.
> 
> It's not hard to make sure the array is the right type.  A call
> to PyContiguous_FromObject(obj, type, min_dim, max_dim) will
> do it for you. If the array is already the right type, no copying takes
> place.   This also allows arbitrary sequences to be used as input
> arguments, which is nice.

This does not work for current implementation (I think) where f2py.
Say, if x = [2,3] (it is a list),
then calling from python
	_f(len(x),x)
first in C 
  PyArg_ParseTuple("OO",&n,&x) 
will give x containing reference to the list. 
Second a new array should be generated in C: say
  x_api=PyArray_Contiguous_FromObject(x,...);
Third, call fortran function
  f_(&(n->ob_ival),(double *)(x_api->data));
(that fulfills x_api with ones)
But now I don't see how to get the contents of x_api to x without copying:
  x=x_api; will not work (I guess).

Travis: About you concern of changing from format "iO" to "OO":
I needed that because some fortran routines may want to change, say,
flags, etc that are integers, or more generally they may change numeric
types. If I will use "iO", the code will be more complicated to get these 
changed values back (previously dictionary were returned with numeric
variables). With "OO", as it is now, it is relatively clean and simple.
For argument checking I will use "O!" construction as you suggested.

Again, f2py.py generates a very low level python functions. The user
should be responsible that input arrays are in the right length because
f2py cannot always find out the correct length of an argument array (as
in fortran some times there is statement 'REAL*8 x(*)' instead of 'REAL*8
x(n)'). Best that f2py can do, is to check only the dimensions
(1D,2D,...).
So, f2py cannot prevent code dumps in general: it is programmers
responsibility.

Pearu



From warren@pfiesteria.gsfc.nasa.gov  Wed Jul 14 16:32:59 1999
From: warren@pfiesteria.gsfc.nasa.gov (Warren B. Focke)
Date: Wed, 14 Jul 1999 11:32:59 -0400 (EDT)
Subject: [Matrix-SIG] FFT:real_fft/FFT:inverse_real_fft
Message-ID: <Pine.LNX.3.96.990714112229.25208A-100000@pfiesteria.gsfc.nasa.gov>

	Some confusion has been generated by FFT:inverse_real_fft. 
Normally I like confusion is a good thing, but someone asked me to look at
this, so I'll raise^H^H^H^H^Hmake an exception.

	FFT:real_fft was coded with the intent that it return the
nonnegative frequency part of the Fourier transform of data which is real
in the time domain.  Only the nonnegative frequencies are necessary
because this data has hermitian symmetry in the frequency domain. 
	Many users expect FFT:inverse_real_fft to perform the inverse of
that operation - that is, to transform the nonnegative frequency part of
data which has hermitian symmetry in the frequency domain to the time
domain, where it would be real.  It was, however, coded with the intent
that, given data which is real in the frequency domain, it would return
the nonnegative time portion of the time-domain representation of that
data, which would have hermitian symmetry about t=0.
	Unfortunately, neither FFT:inverse_real_fft nor FFT:real_fft
perform as advertised, and I know that RFFTB (the routine in FFTPACK which
is used by FFT:inverse_real_fft) has the intent of the first transform
described in the previous paragraph.  Or, at least, I have written working
programs based on that assumption.  So I took a look.  The results:

real_fft:		Fixed.  Does what it was intended to.
real_inverse_fft:	Does the inverse of real_fft.

hermite_fft:		Takes the nonnegative time portion of data with
			hermitian symmetry, returns the (real) frequency
			domain representation of that data.
hermite_inverse_fft:	Does the inverse of hermite_fft - this is what
			inverse_real_fft was meant to do.

inverse_real_fft:	Another name for hermite_inverse_fft.

Test 'em, if you would.  The test code is designed to work with the
original versions, too. 
	All have the same calling semantics as the routines that existed
before: real_fft(array, npts, axis).  npts always refers to the number of
points in the whole sequence, not the number in the nonnegative
frequency/time portion of data with hermitian symmetry (that is, it's N,
not N/2+1).  If this number is not supplied, there are two possible values
for the real_inverse and hermite transforms:  (array.shape[axis]-1)*2 and
(array.shape[axis]-1)*2+1.  The routines always guess the former, so if
you want your result from these routines to have an odd number of points,
you must supply it.
	real_inverse_fft and hermite_fft pad the data to twice the size it
needs to be (this happens in _raw_fft).  I didn't see a way around this
without special-casing _raw_fft or losing the ability to get back an odd
number of points.
	I chose names that did not interfere with the old ones.  I think I
would prefer to name real_inverse_fft and hermite_inverse_fft
inverse_real_fft and inverse_hermite_fft instead.  This should not break
old code since inverse_real_fft did not work before.  Opinons?

	I'll be happy to document these after they are tested and naming
etc. issues are resolved.  (OK, maybe not happy, but I'll do it.)

	Looking over things while packing this up just now, I noticed that
real_fft2d does not do the right thing.  I'll fix that later, I wanna get
this out now.


Warren Focke


Eh? Wassat? Oh, the code! Here, apply with "patch -Np0" from the directory
where you unzipped LLNLDistribution11.tgz.
----------------------- cut here --------------------------------------
diff -Naur orig.LLNLDistribution11/Numerical/Lib/FFT.py LLNLDistribution11/Numerical/Lib/FFT.py
--- orig.LLNLDistribution11/Numerical/Lib/FFT.py	Thu Apr  1 19:14:45 1999
+++ LLNLDistribution11/Numerical/Lib/FFT.py	Tue Jul 13 19:37:36 1999
@@ -44,9 +44,19 @@
 def real_fft(a, n=None, axis=-1): 
 	return _raw_fft(a.astype(Numeric.Float), n, axis, fftpack.rffti, fftpack.rfftf, _real_fft_cache)
 
-def inverse_real_fft(a, n=None, axis=-1): 
+def real_inverse_fft(a, n=None, axis=-1): 
+	if n == None: n = (Numeric.shape(a)[axis]-1)*2
+	return _raw_fft(a.astype(Numeric.Complex), n, axis, fftpack.rffti, fftpack.rfftb, _real_fft_cache)/n
+
+def hermite_fft(a, n=None, axis=-1):
+	if n == None: n = (Numeric.shape(a)[axis]-1)*2
+	return real_inverse_fft(Numeric.conjugate(a), n, axis)*n
+	
+def hermite_inverse_fft(a, n=None, axis=-1):
 	if n == None: n = Numeric.shape(a)[axis]
-	return _raw_fft(a.astype(Numeric.Float), n, axis, fftpack.rffti, fftpack.rfftb, _real_fft_cache)/n
+	return Numeric.conjugate(real_fft(a, n, axis))/n
+
+inverse_real_fft = hermite_inverse_fft
 
 def _raw_fft2d(a, s=None, axes=(-2,-1), function=fft):
 	a = Numeric.asarray(a)
@@ -58,7 +68,7 @@
 	return _raw_fft2d(a,s,axes,fft)
 
 def inverse_fft2d(a, s=None, axes=(-2,-1)):
-    return _raw_fft2d(a, s, axes, inverse_fft)
+	return _raw_fft2d(a, s, axes, inverse_fft)
 
 def real_fft2d(a, s=None, axes=(-2,-1)):
 	return _raw_fft2d(a, s, axes, real_fft)
@@ -73,5 +83,134 @@
 	print inverse_fft2d (fft2d( [(0, 1), (1, 0)] ) )
 	print real_fft2d([(0,1),(1,0)] )
 	print real_fft2d([(1,1),(1,1)] )
+
+
+	import sys
+
+	oosq2 = 1.0/Numeric.sqrt(2.0)
+
+	toler = 1.e-10
+	
+	p = Numeric.array(((1, 1, 1, 1, 1, 1, 1, 1),
+			   (1, oosq2, 0, -oosq2, -1, -oosq2, 0, oosq2),
+			   (1, 0, -1, 0, 1, 0, -1, 0),
+			   (1, -oosq2, 0, oosq2, -1, oosq2, 0, -oosq2),
+			   (1, -1, 1, -1, 1, -1, 1, -1),
+			   (1, 0, 0, 0, 0, 0, 0, 0),
+			   (0, 0, 0, 0, 0, 0, 0, 0)))
+	
+	q = Numeric.array(((8,0,0,0,0,0,0,0),
+			   (0,4,0,0,0,0,0,4),
+			   (0,0,4,0,0,0,4,0),
+			   (0,0,0,4,0,4,0,0),
+			   (0,0,0,0,8,0,0,0),
+			   (1,1,1,1,1,1,1,1),
+			   (0,0,0,0,0,0,0,0)))
+
+	def cndns(m):
+		return Numeric.maximum.reduce(abs(m).flat)
+
+	try:
+		junk = hermite_fft
+		new = 1
+	except NameError:
+		new = 0
+
+	# Tests for correctness.
+## Somewhat limited since
+## p (and thus q also) is real and hermite, and the dimension we're
+## testing is a power of 2.  If someone can cook up more general data
+## in their head or with another program/library, splice it in!
+
+	print "\nCorrectness testing dimension -1."
+
+	sys.stdout.write("fft: ")
+	sys.stdout.flush()
+	P = fft(p)
+	if cndns(P-q) / cndns(q) > toler:
+		print "inaccurate"
+	else:
+		print "OK"
+
+	sys.stdout.write("real_fft: ")
+	sys.stdout.flush()
+	RP = real_fft(p)
+	npt = p.shape[-1]
+	rpt = npt/2 + 1
+	qr = q[:,:rpt]
+	if cndns(RP-qr) / cndns(qr) > toler:
+		print "inaccurate"
+	else:
+		print "OK"
+
+	if new:
+		sys.stdout.write("real_inverse_fft: ")
+		sys.stdout.flush()
+		if cndns(real_inverse_fft(q, npt)-p) / cndns(p) > toler:
+			print "inaccurate"
+		else:
+			print "OK"
+	else:
+		sys.stdout.write("inverse_real_fft: ")
+		sys.stdout.flush()
+		hp = inverse_real_fft(q)
+		pr = p[:,:rpt]
+		if cndns(hp-pr) / cndns(pr) > toler:
+			print "inaccurate"
+		else:
+			print "OK"
+
+	# now just test consistency
+
+	for dim in range(len(p.shape)):
+		print "\nConsistency testing dimension %d, length %d."%(dim, p.shape[dim])
+		
+		sys.stdout.write("fft/inverse_fft: ")
+		sys.stdout.flush()
+		P = fft(p, None, dim)
+		Q = inverse_fft(P, None, dim)
+		if cndns(Q-p) / cndns(p) > toler:
+			print "inconsistent"
+		else:
+			print "OK"
+			
+		sys.stdout.write("fft/real_fft: ")
+		sys.stdout.flush()
+		RP = real_fft(p, None, dim)
+		npt = p.shape[dim]
+		rpt = npt/2 + 1
+		
+		P = Numeric.take(P, range(rpt), dim)
+		if cndns(RP-P) / cndns(RP) > toler:
+			print "inconsistent"
+		else:
+			print "OK"
+
+		sys.stdout.write("inverse_fft/inverse_real_fft: ")
+		sys.stdout.flush()
+		hp = inverse_real_fft(q, npt, dim)
+		Q = inverse_fft(q, None, dim)
+		Q = Numeric.take(Q, range(rpt), dim)
+		if cndns(hp-Q) / cndns(hp) > toler:
+			print "inconsistent"
+		else:
+			print "OK"
+        
+		if new:
+			sys.stdout.write("real_fft/real_inverse_fft: ")
+			sys.stdout.flush()
+			if cndns(real_inverse_fft(RP, npt, dim)-p) / cndns(p) > toler:
+				print "inconsistent"
+			else:
+				print "OK"
+
+			sys.stdout.write("inverse_real_fft/hermite_fft: ")
+			sys.stdout.flush()
+			if cndns(hermite_fft(hp, npt, dim)-q) / cndns(q) > toler:
+				print "inconsistent"
+			else:
+				print "OK"
+
+
 
 if __name__ == '__main__': test()
diff -Naur orig.LLNLDistribution11/Numerical/Src/fftpackmodule.c LLNLDistribution11/Numerical/Src/fftpackmodule.c
--- orig.LLNLDistribution11/Numerical/Src/fftpackmodule.c	Thu Apr  1 19:14:46 1999
+++ LLNLDistribution11/Numerical/Src/fftpackmodule.c	Tue Jul 13 19:37:02 1999
@@ -108,7 +108,7 @@
   PyObject *op1, *op2;
   PyArrayObject *data, *ret;
   double *wsave, *dptr, *rptr;
-  int npts, nsave, nrepeats, i;
+  int npts, nsave, nrepeats, i, rstep;
 
   if(!PyArg_ParseTuple(args, "OO", &op1, &op2)) return NULL;
   data = (PyArrayObject *)PyArray_ContiguousFromObject(op1, PyArray_DOUBLE, 1, 0);
@@ -117,6 +117,7 @@
   data->dimensions[data->nd-1] = npts/2+1;
   ret = (PyArrayObject *)PyArray_FromDims(data->nd, data->dimensions, PyArray_CDOUBLE);
   data->dimensions[data->nd-1] = npts;
+  rstep = (ret->dimensions[ret->nd-1])*2;
 
   if (PyArray_As1D(&op2, (char **)&wsave, &nsave, PyArray_DOUBLE) == -1) 
     goto fail;
@@ -132,11 +133,11 @@
   dptr = (double *)data->data;
   
   for (i=0; i<nrepeats; i++) {
-	memcpy((char *)rptr, dptr, npts*sizeof(double));
+	memcpy((char *)(rptr+1), dptr, npts*sizeof(double));
     rfftf(npts, rptr+1, wsave);
 	rptr[0] = rptr[1];
 	rptr[1] = 0.0;
-    rptr += npts+2;
+    rptr += rstep;
 	dptr += npts;
   }
   PyArray_Free(op2, (char *)wsave);
@@ -161,12 +162,10 @@
   int npts, nsave, nrepeats, i;
 
   if(!PyArg_ParseTuple(args, "OO", &op1, &op2)) return NULL;
-  data = (PyArrayObject *)PyArray_ContiguousFromObject(op1, PyArray_DOUBLE, 1, 0);
+  data = (PyArrayObject *)PyArray_ContiguousFromObject(op1, PyArray_CDOUBLE, 1, 0);
   if (data == NULL) return NULL;
   npts = data->dimensions[data->nd-1];
-  data->dimensions[data->nd-1] = npts/2+1;
-  ret = (PyArrayObject *)PyArray_FromDims(data->nd, data->dimensions, PyArray_CDOUBLE);
-  data->dimensions[data->nd-1] = npts;
+  ret = (PyArrayObject *)PyArray_FromDims(data->nd, data->dimensions, PyArray_DOUBLE);
 
   if (PyArray_As1D(&op2, (char **)&wsave, &nsave, PyArray_DOUBLE) == -1) 
     goto fail;
@@ -177,17 +176,16 @@
     goto fail;
   }
 
-  nrepeats = PyArray_SIZE(data)/npts;
+  nrepeats = PyArray_SIZE(ret)/npts;
   rptr = (double *)ret->data;
   dptr = (double *)data->data;
   
   for (i=0; i<nrepeats; i++) {
-	memcpy((char *)rptr, dptr, npts*sizeof(double));
-    rfftb(npts, rptr+1, wsave);
-	rptr[0] = rptr[1];
-	rptr[1] = 0.0;
-    rptr += npts+2;
-	dptr += npts;
+	memcpy((char *)(rptr+1), (dptr+2), (npts-1)*sizeof(double));
+	rptr[0] = dptr[0];
+    rfftb(npts, rptr, wsave);
+    rptr += npts;
+	dptr += npts*2;
   }
   PyArray_Free(op2, (char *)wsave);
   Py_DECREF(data);








From amullhau@zen-pharaohs.com  Thu Jul 15 09:34:19 1999
From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt)
Date: Thu, 15 Jul 1999 04:34:19 -0400
Subject: [Matrix-SIG] Fortran code to use with NumPy in W9x?
References: <Pine.HPX.4.05.9907132015550.5004-100000@egoist.ioc.ee>
Message-ID: <004501bece9c$d6263200$99a0720a@amullhau>

I have a bunch of Fortran code, the Digital (soon to be Compaq) Visual
Fortran V6 compiler, and a version of NumPy running on Windows 98.

Any chance I can write code that can be called from NumPy using just these?
Does anyone have a simple example that could get me started?

Thanks in Advance,
Andrew Mullhaupt




From mhagger@blizzard.harvard.edu  Thu Jul 15 23:20:25 1999
From: mhagger@blizzard.harvard.edu (Michael Haggerty)
Date: 15 Jul 1999 22:20:25 -0000
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
In-Reply-To: <199906232112.RAA10630@sundog.stsci.edu> (rlw@stsci.edu)
References: <199906232112.RAA10630@sundog.stsci.edu>
Message-ID: <19990715222025.21329.qmail@cyclone.harvard.edu>

> I think it would be simpler both to implement and to understand if
> there was just a 'd2' datatype that is above 'd' and if the
> promotion hierarchy is defined so that binary operations between
> 'f2' and 'd' get promoted to 'f2', but binary operations between
> 'f2' and 'd2' get promoted to 'd2'.

This proposal (discussed by several people) sounds like the best
direction for solving the promotion problem, but I think the
terminology is confusing.  (Imagine trying to explain it to a
beginner.)  Therefore I suggest a slight change:

Instead of creating new datatypes with weird places the type
hierarchy, let's rather define an additional attribute of the array
typecodes which might be called `force'.  So an array with typecode
ForcedFloat32 (I prefer a spelling such as 'f*') would be identical to
an array with typecode 'f' except that the result of ANY operation
involving such an array would be coerced to the same typecode, namely
'f*'.  Similarly, all of the other existing typecodes would have
forced versions.  Any non-forced object that appears in an expression
with a forced object would be ruthlessly cast to the forced data
object's type, even if that requires a downcast or a conversion from
floating point to integer.  An expression involving two incompatible
forced objects would raise an exception.

To typecast a forced object into another type (including casts into
the non-forced version of the same type) would require an explicit
conversion such as with array():

    >>> a = arange(5, typecode='f*')
    >>> b = 2.0 * a
    >>> print b
    array([  0.,   2.,   4.,   6.,   8.], 'f*')
    >>> print array(b, 'd')
    array([  0.,   2.,   4.,   6.,   8.])

This proposal probably doesn't differ in effect from the previous one,
but I think it is conceptually simpler to understand and to explain.

Michael

--
Michael Haggerty
mhagger@blizzard.harvard.edu


From rlw@stsci.edu  Thu Jul 15 23:33:35 1999
From: rlw@stsci.edu (Rick White)
Date: Thu, 15 Jul 1999 18:33:35 -0400 (EDT)
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
Message-ID: <199907152233.SAA05162@sundog.stsci.edu>

Michael Haggerty writes:

>Instead of creating new datatypes with weird places the type
>hierarchy, let's rather define an additional attribute of the array
>typecodes which might be called `force'.  So an array with typecode
>ForcedFloat32 (I prefer a spelling such as 'f*') would be identical to
>an array with typecode 'f' except that the result of ANY operation
>involving such an array would be coerced to the same typecode, namely
>'f*'.  Similarly, all of the other existing typecodes would have
>forced versions.

I think this is fine, and this was one of the first ideas
that we discussed internally to solving the unwanted promotion
problem.  As you say, the results are really the same whether
it is called a separate type or the same type with an additional
attribute.  Whichever is cleanest in implementation and use
should be preferred.

I'd prefer a shorter name than 'ForcedFloat32', but the basic
idea looks good to me.

>An expression involving two incompatible
>forced objects would raise an exception.

I can't agree with that, though.  I'm afraid that will result
in more ugly, hard-to-read code with lots of explicit casts.
I believe that an operation between two forced objects should
obey the normal promotion rules, with the lower forced type
being promoted to the higher forced type.

- Rick White


From Oliphant.Travis@altavista.net  Fri Jul 16 00:03:40 1999
From: Oliphant.Travis@altavista.net (Travis Oliphant)
Date: Thu, 15 Jul 1999 18:03:40 -0500
Subject: [Matrix-SIG] Writing code to interface NumPy with Python.
Message-ID: <99071518095301.22659@us2.mayo.edu>

Probably the best suggestion I could give you is to get the f2py.py program
discussed a couple of days ago on this list.

This will generate C-code that interfaces with your Fortran code.  It is
already pretty useable and is complete with error checking on array arguments
(unless you don't want them).  The only thing left to implement is callback
functions and that's maybe a week or two away.  If you don't have a C-compiler
download gcc.  Robert Kern has a site which he has posted to this list that
explains using gcc under Windows.   That gives you all the compiler power you
need.

Compile the Fortran code into a library or object.  Compile the auto-generated
interface module (with a C compiler) into an object file  Use the Fortran
compiler to make a shared library from the fortran object code and the
interface code. 

It is so easy to do with gcc that I'm thinking I might do some more coding in
Fortran again....

Best,

Travis


From beach@verinet.com  Fri Jul 16 04:31:39 1999
From: beach@verinet.com (David J. C. Beach)
Date: Thu, 15 Jul 1999 21:31:39 -0600
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
In-Reply-To: <199907152233.SAA05162@sundog.stsci.edu>; from Rick White on Thu, Jul 15, 1999 at 06:33:35PM -0400
References: <199907152233.SAA05162@sundog.stsci.edu>
Message-ID: <19990715213139.B11996@sim.verinet.com>

On Thu, Jul 15, 1999 at 06:33:35PM -0400, Rick White wrote:
> >An expression involving two incompatible
> >forced objects would raise an exception.
> 
> I can't agree with that, though.  I'm afraid that will result
> in more ugly, hard-to-read code with lots of explicit casts.
> I believe that an operation between two forced objects should
> obey the normal promotion rules, with the lower forced type
> being promoted to the higher forced type.

Yes.  Then maybe there should be a ForcedForcedFloat32 which is
"stronger" (more forceful?) than a plain ol' ForcedFloat32.  Doesn't
this problem just start to repeat itself?  Do numeric types need a
"degree of force" (e.g., a Force5Float32 beats out a Force2Float64, so
the result is then typed as a Force5Float32 because 5 is "stronger"
than 2)?  Where is this going?

Will adding forced types break number-crunching code that counts on
working with a greater precision internally?  Are there any examples
of packages that use such a mechanism already in existence?

Forgive me for raising this point, I've mostly been a passive observer
of NumPy... This issue caught my attention.

Dave

-- 
David J. C. Beach
<beach@verinet.com>


From thomas.hauser@usa.net  Fri Jul 16 13:12:50 1999
From: thomas.hauser@usa.net (thomas.hauser@usa.net)
Date: Fri, 16 Jul 1999 08:12:50 -0400 (EDT)
Subject: [Matrix-SIG] Where can I find f2py.py
In-Reply-To: <199907160501.BAA07005@python.org>
References: <199907160501.BAA07005@python.org>
Message-ID: <14223.8596.526906.167443@ci974016-a.lxintn1.ky.home.com>

Hi,

I have some fortran code I'd love to interface to python. Where can I
find f2py.py ?

thanks

thomas



From rlw@stsci.edu  Fri Jul 16 13:20:37 1999
From: rlw@stsci.edu (Rick White)
Date: Fri, 16 Jul 1999 08:20:37 -0400 (EDT)
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
Message-ID: <199907161220.IAA06094@sundog.stsci.edu>

David Beach writes:

% On Thu, Jul 15, 1999 at 06:33:35PM -0400, Rick White wrote:
% 
% > >An expression involving two incompatible
% > >forced objects would raise an exception.
% > 
% > I can't agree with that, though.  I'm afraid that will result
% > in more ugly, hard-to-read code with lots of explicit casts.
% > I believe that an operation between two forced objects should
% > obey the normal promotion rules, with the lower forced type
% > being promoted to the higher forced type.
% 
% Yes.  Then maybe there should be a ForcedForcedFloat32 which is
% "stronger" (more forceful?) than a plain ol' ForcedFloat32.  Doesn't
% this problem just start to repeat itself?  Do numeric types need a
% "degree of force" (e.g., a Force5Float32 beats out a Force2Float64, so
% the result is then typed as a Force5Float32 because 5 is "stronger"
% than 2)?  Where is this going?

Maybe you missed the original reason for these types, which is that any
operations with Python scalars lead to promotions, effectively making
the lower types (Float32, Int16, etc.) nearly useless except for input
and output.  For example, if x is a Float32 array, then (x+1) is a
Float64 array.  Adding Numeric types that do not get promoted in
operations with scalars puts the programmer back in control.

At that point, in my opinion, the least surprising behavior would be
for promotions to occur in the normal way within the hierarchy.  Only
operations with other forced arrays would lead to promotion, and so the
programmer can easily control that (just like you do when you write
non-Numeric Python.)

---
Richard L. White    rlw@stsci.edu    http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD


From pearu@ioc.ee  Fri Jul 16 14:23:28 1999
From: pearu@ioc.ee (Pearu Peterson)
Date: Fri, 16 Jul 1999 16:23:28 +0300 (EETDST)
Subject: [Matrix-SIG] Where can I find f2py.py
In-Reply-To: <14223.8596.526906.167443@ci974016-a.lxintn1.ky.home.com>
Message-ID: <Pine.HPX.4.05.9907161610310.15397-100000@egoist.ioc.ee>

On Fri, 16 Jul 1999 thomas.hauser@usa.net wrote:

> Hi,
> 
> I have some fortran code I'd love to interface to python. Where can I
> find f2py.py ?
> 
> thanks
> 
> thomas
> 

Latest alpha version can be found in 
  http://koer.ioc.ee/~pearu/python/f2py/
It is currently under active development so that f2py.py may change in
days (I am rewriting it to be better, smarter, faster, ...:-).

Pearu



From craig@yttria.mse.ufl.edu  Fri Jul 16 16:01:33 1999
From: craig@yttria.mse.ufl.edu (Craig Schardt)
Date: Fri, 16 Jul 1999 11:01:33 -0400
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
In-Reply-To: <199907161220.IAA06094@sundog.stsci.edu>
Message-ID: <4.2.0.56.19990716091201.00a4f430@silica.mse.ufl.edu>

At 08:20 AM 7/16/99 , Rick White wrote:
>Maybe you missed the original reason for these types, which is that any
>operations with Python scalars lead to promotions, effectively making
>the lower types (Float32, Int16, etc.) nearly useless except for input
>and output.  For example, if x is a Float32 array, then (x+1) is a
>Float64 array.  Adding Numeric types that do not get promoted in
>operations with scalars puts the programmer back in control.
>
>At that point, in my opinion, the least surprising behavior would be
>for promotions to occur in the normal way within the hierarchy.  Only
>operations with other forced arrays would lead to promotion, and so the
>programmer can easily control that (just like you do when you write
>non-Numeric Python.)

I was in favor of the extended casting hierarchy approach discussed earlier 
on this list. It was my understanding that the non-promotable types were 
designed to defeat the default upcasting. As such, any casting between 
'Forced' types should cast to the smallest (ie. most restrictive) of the 
two types. An operation between a ForcedFloat32 and a ForcedInt16 should 
return a ForcedInt16. After declaring a type Forced, it is the 
responsibility of the programmer to specify that the restriction can be 
loosened by an explicit cast.

The current Python hierarchy is:

         Int16 -> Int32 -> Float32 -> Float64

I suggest that the Forced be the reverse of the normal hierarchy:

         ForcedFloat64 -> ForcedFloat32 -> ForcedInt32 -> ForcedInt16

This system respects the size restrictions that the user places on their 
data. A user accepts the potential loss of accuracy when they declare 
something Forced, in exchange, the type system should guarantee that the 
Forced declaration is respected.

IMNSHO, the main reason for using the Forced types is to eliminate the 
memory bloat which occurs when small types are upcast. If I declare an 
array ForcedInt16, I want it to stay that way for the sake of conserving 
memory. If I pass it to a function I don't want the function to be able to 
override my type declaration and return an array cast to ForcedFloat32. If 
I wanted a ForcedFloat32 I would have declared it that way from the start.

If the Forced types follow the normal promotion order, then the Forced type 
system is just a hack to get around the python core's upcasting of scalars 
to Float64. The reverse promotion order may be more surprising, but it is 
also more in line with the original need for such a secondary type system, 
and it gives the programmer more control over data-types and memory usage 
during numerical computations.

But will any of this fix the integer division nit?
-craig.



From dubois1@llnl.gov  Fri Jul 16 16:06:09 1999
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 16 Jul 1999 08:06:09 -0700
Subject: [Matrix-SIG] Where can I find f2py.py
References: <199907160501.BAA07005@python.org> <14223.8596.526906.167443@ci974016-a.lxintn1.ky.home.com>
Message-ID: <001001becf9c$bcd9f100$f4160218@plstn1.sfba.home.com>

ftp://ftp-icf.llnl.gov/pub/python/dubois contains my new tool Pyfort. The
doc is there too.
I am looking for friendly users to try it. I don't have any info on the
differences between it and f2py.py since the author of that just announced
it and I haven't had time to look at it.

----- Original Message -----
From: <thomas.hauser@usa.net>
To: <matrix-sig@python.org>
Sent: Friday, July 16, 1999 5:12 AM
Subject: [Matrix-SIG] Where can I find f2py.py


> Hi,
>
> I have some fortran code I'd love to interface to python. Where can I
> find f2py.py ?
>
> thanks
>
> thomas
>
>
> _______________________________________________
> Matrix-SIG maillist  -  Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
>



From minxu@scisun.sci.ccny.cuny.edu  Fri Jul 16 21:29:19 1999
From: minxu@scisun.sci.ccny.cuny.edu (Min Xu)
Date: Fri, 16 Jul 1999 16:29:19 -0400
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
In-Reply-To: Message from Craig Schardt <craig@yttria.mse.ufl.edu>
 of "Fri, 16 Jul 1999 11:01:33 EDT." <4.2.0.56.19990716091201.00a4f430@silica.mse.ufl.edu>
Message-ID: <199907162029.QAA18985@star.future.com>

> IMNSHO, the main reason for using the Forced types is to eliminate the 
> memory bloat which occurs when small types are upcast. If I declare an 
> array ForcedInt16, I want it to stay that way for the sake of conserving 
> memory. If I pass it to a function I don't want the function to be able to 
> override my type declaration and return an array cast to ForcedFloat32. If 
> I wanted a ForcedFloat32 I would have declared it that way from the start.
> 
> If the Forced types follow the normal promotion order, then the Forced type 
> system is just a hack to get around the python core's upcasting of scalars 
> to Float64. The reverse promotion order may be more surprising, but it is 
> also more in line with the original need for such a secondary type system, 
> and it gives the programmer more control over data-types and memory usage 
> during numerical computations.
> 
> But will any of this fix the integer division nit?
> -craig.
> 
Excuse me if I do not catch what this thread said. 
I will say it again the blind promotion of operation to Float64 is one of the 
main defect of Python to handle large data sets. As in other languages like C, 
Fortran, a promotion to the highest data type involved in the operation is 
reasonable. Other needs can always be met with a explicit cast.

When we can explicit cast any result to a desired data type, I think it can 
perform  any operations an extra fore data type attribute does. So I do not 
see any reason for a forced data type attribute.

But one concern is then for a function like sin(x), it should then be able to 
handle the following cases:
      sin( Float32 ) -> Float32,
      sin( Int32 ) -> Int32 ... etc
So we need some kind of overloading for operators and functions as in C++. 

This is another defect of Python. Correct me if it is not the case.








-- 
Min Xu				
City College of NY, CUNY		
Email:	mxu1@email.gc.cuny.edu
       	minxu@sci.ccny.cuny.edu	 
Tel:	(O) (212) 650-6865
	(O) (212) 650-5046
	(H) (212) 690-2119		




From mhagger@blizzard.harvard.edu  Sun Jul 18 01:31:36 1999
From: mhagger@blizzard.harvard.edu (Michael Haggerty)
Date: 18 Jul 1999 00:31:36 -0000
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
In-Reply-To: <199907152233.SAA05162@sundog.stsci.edu> (rlw@stsci.edu)
References: <199907152233.SAA05162@sundog.stsci.edu>
Message-ID: <19990718003136.29132.qmail@cyclone.harvard.edu>

> >An expression involving two incompatible
> >forced objects would raise an exception.
> 
> I can't agree with that, though.  I'm afraid that will result
> in more ugly, hard-to-read code with lots of explicit casts.
> I believe that an operation between two forced objects should
> obey the normal promotion rules, with the lower forced type
> being promoted to the higher forced type.

The reason I would disallow operations between incompatible forced
objects is the principle of least surprise.  ``Forcing'' an array
should be a guarantee to the user that whatever happens to the data in
the array (short of an explicit cast), the result will be of the
requested type.  An operation between incompatible forced arrays
cannot satisfy that guarantee, and therefore should be disallowed.

Forced arrays will probably be used primarily for huge arrays such as
image files.  There will only be a few around at a time and they are
likely to be of the same type anyway, so I don't expect many explicit
casts to be necessary even for strict forced arrays.  Meanwhile the
impact of implicit casts of such arrays is by assumption large and
therefore *should* have to be thought about by the programmer.
Imagine a subroutine to which both your gigantic ForcedInt8 array and
a small ForcedFloat64 are accidentally passed; they get combined
somehow and boom you have a gigantic ForcedFloat64 array that doesn't
fit into memory.  In a case like that it would be helpful to have an
exception thrown so that the user recognizes the problem and can
easily track it down and correct it.

Craig Schardt <craig@yttria.mse.ufl.edu> says:
> I suggest that the Forced be the reverse of the normal hierarchy:
>
>          ForcedFloat64 -> ForcedFloat32 -> ForcedInt32 -> ForcedInt16

Yes, I can see the rationale for this idea.  But as you admit, this
promotion order would be surprising.  The most important virtue of
``strict forcing'' is that it is unsurprising and easy to explain.

By the way, there is a way to break the ``result type equals forced
type'' guarantee: reduce the array to a scalar, which would be
converted to a python scalar, whereupon the `forced' type attribute
would be lost.  But I think this is of only academic interest since a
forced scalar is not very useful.

Michael

--
Michael Haggerty
mhagger@blizzard.harvard.edu


From Oliphant.Travis@mayo.edu  Mon Jul 19 20:50:44 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Mon, 19 Jul 1999 14:50:44 -0500 (CDT)
Subject: [Matrix-SIG] Success with the other Fortran wrapping program.
In-Reply-To: <Pine.HPX.4.05.9907191751190.27580-100000@egoist.ioc.ee>
Message-ID: <Pine.LNX.4.10.9907191432030.1304-100000@us2.mayo.edu>

Recently on this list two Fortran wrapping programs have been presented.
I thought I would share a couple of observations of both codes and report
some results with Pearu's f2py code.

Paul Dubois has an excellent PyFort program which uses interface files to
generate relatively high-level wrappings of users Fortran code.  He has
done a nice job.

I have been involved with Pearu in development of another Fortran-wrapper
generator which has a somewhat different design philosophy which may be
more suitable for some uses.

Pearu's f2py program does not require interface definition files as it
gets the information directly from the Fortran code itself.  The resulting
wrapper is a direct translation to Python of the underlying Fortran, so
the same documentation applies.  The idea is to make available large
numbers of routines quickly to Python where higher-level calling sytnax
could be developed more quickly and generally.  The low-level code checks
the type and size of the arguments but little else.

We have implemented call_back functions in the same low-level manner so
that Fortran codes requiring call-back functions can be wrapped.  In this
case, however, the user must provide a Fortran delcaration statement of
the call-back function (similar to the python-interface definition file of
PyFort but without the extra features).  The advantage is that only one
declaration statement must be included for all functions to be wrapped
that use that statement.

As an example of the utility of the lower-level approach for some
problems, I have wrapped up all of lapack and quadpack and made those
routines available to Python using the following commands:

./f2py.py -m_quad -ffdefs ../multipack/quadpack/*.f
gcc -I/usr/include/python1.5 -c _quadmodule.c
g77 -shared -o _quadmodule.so _quadmodule.o -L../multipack/lib -lquadpack
-llinpack_lite -lblas -lmach

./f2py.py -m_lapack -ffdefs ../multipack/lapack/SRC/*.f
gcc -I/usr/include/python1.5 -c _lapackmodule.c
g77 -shared -o _lapackmodules.so _lapackmodule.o -L../multipack/lib
-llapack -lblas

The fdefs.py file looked like this:

func_defs={'lsoda':"""\
subroutine f(neq,t,y,ydot)
integer neq
real*8 t,y(neq),ydot(neq)
end
subroutine jac(neq,t,y,ml,mu,pd,nrowpd)
integer neq,nl,ml,mu,nrowpd
real*8 t,y(neq),pd(nrowpd,1)
end
""",
           'dq*':"""
real*8 function f(x)
real*8 x
end
real*8 function w(x)
real*8 x
end
""",
           'sg*':"""
logical function select(wr,wi)
real wr, wi
end
""",
           'dg*':"""
logical function select(wr,wi)
double precision wr, wi
end
""",
           'cg*':"""
logical function select(w)
complex w
end
""",
           'zg*':"""
logical function select(w)
complex*16 w
end
"""
}


I just thought some people would be interested in the two approaches to
wrapping Fortran code and how they differ and the benefits of the "no
interface file" for making lots of Fortran code available to Python
quickly.  With f2py it is not inconceivable to wrap up all of the Fortran
code at netlib.org for use with NumPy.

For practical use of these routines, perhaps a friendlier interface could
be written (in Python only) to make it easier to use some of these
functions.

Note that f2py could also be used to generate preliminary *.pyf files for
PyFort

Best,

Travis




From hinsen@cnrs-orleans.fr  Tue Jul 20 17:46:40 1999
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Tue, 20 Jul 1999 18:46:40 +0200
Subject: [Matrix-SIG] Numeric Nits--a slightly different proposal
In-Reply-To: <4.2.0.56.19990716091201.00a4f430@silica.mse.ufl.edu> (message
 from Craig Schardt on Fri, 16 Jul 1999 11:01:33 -0400)
References: <4.2.0.56.19990716091201.00a4f430@silica.mse.ufl.edu>
Message-ID: <199907201646.SAA13288@chinon.cnrs-orleans.fr>

> The current Python hierarchy is:
> 
>          Int16 -> Int32 -> Float32 -> Float64
> 
> I suggest that the Forced be the reverse of the normal hierarchy:
> 
>          ForcedFloat64 -> ForcedFloat32 -> ForcedInt32 -> ForcedInt16

Would anyone really want an automatic cast from Float32 to Int32?
There's nothing to gain in that operation.

I see a need only for "forced" versions of Int16 and Float32.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From dubois1@llnl.gov  Tue Jul 20 20:45:42 1999
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 20 Jul 1999 12:45:42 -0700
Subject: [Matrix-SIG] Pyfort -- small fixes
Message-ID: <99072012494500.32456@almanac>

I fixed a bug in the "inout" handler.
I removed the restriction on double quotes in comments.
I fixed up some things in the doc as suggested by Guido.

ftp://ftp-icf.llnl.gov/pub/python/dubois  {pyfort.tar, pyfort.pdf}

Planned but not done yet: support dimension (*) meaning, no length check.
This is a concession to some suicidal friends.


From dubois1@llnl.gov  Wed Jul 21 21:28:24 1999
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 21 Jul 1999 13:28:24 -0700
Subject: [Matrix-SIG] Your wish is my command
References: <Pine.LNX.4.10.9907211114220.11971-100000@us2.mayo.edu>
Message-ID: <99072113382800.01884@almanac>

I don't have time to do the doc to reflect it but the pyfort.tar now out there
does this:

If the last dimension of an array is declared * or 1, no length check is
performed on that dimension.

A * in a non-final position is not legal Fortran, but the Pyfort parser will
not detect that and will treat it as a 1. And of course in that position it
will be checked so I don't think such a mistake would survive much testing.
I could work on the grammer to fix this but I doubt it is worth it.

-- P.






From collins@seal.aero.org  Wed Jul 21 22:53:58 1999
From: collins@seal.aero.org (Jeff Collins)
Date: Wed, 21 Jul 1999 14:53:58 -0700
Subject: [Matrix-SIG] ezplot problems
Message-ID: <199907212153.OAA13370@malibu.sipnet>

I am having problems running the examples in the ezplot
manual (example 1, pp 11).  The following is the session
output.  Some of the errors (nf(), in particular) may
be due to previous errors.

LLNLDistribution11 is installed, along with Yorick-1.4.

Am I missing an update to either the manuals or the software?

Thanks,

Jeff



Python 1.5.2+ (#10, Jul  6 1999, 15:06:04)  [GCC 2.7.2.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> from ezplot import *
Opening Gist graphics.
>>> win("on")
>>> plot (arange(20, typecode=Float) ** 0.5 )
Opening default cgm plotter.
Opening graphics window 0.
>>> plot (arange(20, typecode=Float) ** 1.2)
Opening plot file Ai00.cgm.
>>> cgm ("send")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 511, in cgm
    if _cgm_plotter_ != win_no :
UnboundLocalError: win_no
>>> nf()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 698, in nf
    cgm ("plot", new_frame = new_frame, window = _cgm_plotter_)
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 497, in cgm
    win_no = _get_win_ (kw ["window"], _CgmError_)
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 429, in _get_win_
    raise error, "There seems to be nothing there!"
CgmError: There seems to be nothing there!
>>> plot (arange(15, typecode=Float) ** 1.2)
>>> cgm("send")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 511, in cgm
    if _cgm_plotter_ != win_no :
UnboundLocalError: win_no
>>> ps("send")
Opening plot file Ac00.ps.
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 637, in ps
    if new_frame == "no" :
UnboundLocalError: new_frame
>>> nf()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 698, in nf
    cgm ("plot", new_frame = new_frame, window = _cgm_plotter_)
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 497, in cgm
    win_no = _get_win_ (kw ["window"], _CgmError_)
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 429, in _get_win_
    raise error, "There seems to be nothing there!"
CgmError: There seems to be nothing there!
>>> plot (arange(15, typecode=Float) ** 1.4)
>>> ps("send")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/arrayfcns/ezplot.py", line 617, in ps
    if _ps_plotter_ != win_no :
UnboundLocalError: win_no
>>> 


From zcm@llnl.gov  Wed Jul 21 23:24:06 1999
From: zcm@llnl.gov (Zane Motteler)
Date: Wed, 21 Jul 1999 15:24:06 -0700
Subject: [Matrix-SIG] ezplot problems
In-Reply-To: <199907212153.OAA13370@malibu.sipnet>
Message-ID: <v03130308b3bbf87d6a1d@[128.115.36.161]>

Jeff,

Thanks for the bug report. I'm about to leave for the day but will
look at it tomorrow. Either I'll find out what you did wrong or
supply you with a patch.

Zane

--------------------
Zane C. Motteler, Ph. D.
   Professor Emeritus of Computer Science and Engineering
   California Polytechnic State University, San Luis Obispo
   zmottel@calpoly.edu
Currently:
   Computer Scientist
   Lawrence Livermore National Laboratory
   P O Box 808, L-038 (Street address 7000 East Avenue, L-038)
   Livermore, CA 94551-9900
   zcm@llnl.gov  925/423-2143, FAX 925/423-9969




From zcm@llnl.gov  Thu Jul 22 17:25:39 1999
From: zcm@llnl.gov (Zane Motteler)
Date: Thu, 22 Jul 1999 09:25:39 -0700
Subject: [Matrix-SIG] ezplot problems
In-Reply-To: <199907212153.OAA13370@malibu.sipnet>
Message-ID: <v0313030cb3bcf42289d8@[128.115.36.161]>

Jeff,

In looking over your output, I think the first error cascaded all
the others.

Mea culpa, mea culpa, mea maxima culpa! Here's a patch that
should fix the problem. Note that a similar patch is needed
in the postscript routine.

***************
*** 508,513 ****
--- 508,515 ----
            GistPlotter.Plotter ( "none" , n = _cgm_plotter_, hcp = _cgm_file_)
        _win_plotters_ [_cgm_plotter_].set_bytscl (_cmin_, _cmax_)
        _set_axis_limits_ ( )
+       if not hasattr (cgm, "win_no") :
+          win_no = _win_plotters_ [_cgm_plotter_]._n
        if _cgm_plotter_ != win_no :
           _object_list_ [_cgm_plotter_] = _object_list_ [win_no]
        if _current_graph_ [_cgm_plotter_] == None :
***************
*** 614,619 ****
--- 616,623 ----
            GistPlotter.Plotter ( "none" , n = _ps_plotter_, hcp = _ps_file_)
        _win_plotters_ [_ps_plotter_].set_bytscl (_cmin_, _cmax_)
        _set_axis_limits_ ( )
+       if not hasattr (ps, "win_no") :
+          win_no = _win_plotters_ [_cgm_plotter_]._n
        if _ps_plotter_ != win_no :
           _object_list_ [_ps_plotter_] = _object_list_ [win_no]
        if _current_graph_ [_ps_plotter_] == None :

Cheers,

Zane

--------------------------------------
Zane C. Motteler
Computer Scientist, LCP, X, and A Divisions
Lawrence Livermore National Laboratory
7000 East Avenue, L-038
Livermore, CA 94550-9234
925/423-2143, FAX 925/423-9969
zcm@llnl.gov




From jcollins@pacificnet.net  Thu Jul 22 20:05:47 1999
From: jcollins@pacificnet.net (Jeffery D. Collins)
Date: Thu, 22 Jul 1999 12:05:47 -0700
Subject: [Matrix-SIG] ezplot problems
References: <v0313030cb3bcf42289d8@[128.115.36.161]>
Message-ID: <37976B8A.C4D4E797@pacificnet.net>

Thanks for the quick response.  That seemed to work.  How about
the following?  BTW, my working copy of ezplot.py with the
updates is myplot.py, evident from the traceback below.

>>> ez.win("on")
>>> ez.plot(sin(arange(20)*pi/20))
Opening default cgm plotter.
Opening graphics window 0.
>>> ez.cgm("send")
Opening plot file Aa00.cgm.
>>> ez.ps("send")
Opening plot file Aa00.ps.
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/home/jcollins/python-dev/myplot.py", line 641, in ps
    if new_frame == "no" :
NameError: new_frame


Zane Motteler wrote:

> Jeff,
>
> In looking over your output, I think the first error cascaded all
> the others.
>
> Mea culpa, mea culpa, mea maxima culpa! Here's a patch that
> should fix the problem. Note that a similar patch is needed
> in the postscript routine.
>
> ***************
> *** 508,513 ****
> --- 508,515 ----
>             GistPlotter.Plotter ( "none" , n = _cgm_plotter_, hcp = _cgm_file_)
>         _win_plotters_ [_cgm_plotter_].set_bytscl (_cmin_, _cmax_)
>         _set_axis_limits_ ( )
> +       if not hasattr (cgm, "win_no") :
> +          win_no = _win_plotters_ [_cgm_plotter_]._n
>         if _cgm_plotter_ != win_no :
>            _object_list_ [_cgm_plotter_] = _object_list_ [win_no]
>         if _current_graph_ [_cgm_plotter_] == None :
> ***************
> *** 614,619 ****
> --- 616,623 ----
>             GistPlotter.Plotter ( "none" , n = _ps_plotter_, hcp = _ps_file_)
>         _win_plotters_ [_ps_plotter_].set_bytscl (_cmin_, _cmax_)
>         _set_axis_limits_ ( )
> +       if not hasattr (ps, "win_no") :
> +          win_no = _win_plotters_ [_cgm_plotter_]._n
>         if _ps_plotter_ != win_no :
>            _object_list_ [_ps_plotter_] = _object_list_ [win_no]
>         if _current_graph_ [_ps_plotter_] == None :
>
> Cheers,
>
> Zane
>
> --------------------------------------
> Zane C. Motteler
> Computer Scientist, LCP, X, and A Divisions
> Lawrence Livermore National Laboratory
> 7000 East Avenue, L-038
> Livermore, CA 94550-9234
> 925/423-2143, FAX 925/423-9969
> zcm@llnl.gov
>
> _______________________________________________
> Matrix-SIG maillist  -  Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig



From zcm@llnl.gov  Thu Jul 22 21:32:18 1999
From: zcm@llnl.gov (Zane Motteler)
Date: Thu, 22 Jul 1999 13:32:18 -0700
Subject: [Matrix-SIG] ezplot problems
In-Reply-To: <37976B8A.C4D4E797@pacificnet.net>
References: <v0313030cb3bcf42289d8@[128.115.36.161]>
Message-ID: <v03130314b3bd2f8c7f69@[128.115.36.161]>

Jeff,

You wrote:

>Thanks for the quick response.  That seemed to work.  How about
>the following?  BTW, my working copy of ezplot.py with the
>updates is myplot.py, evident from the traceback below.
>
>>>> ez.win("on")
>>>> ez.plot(sin(arange(20)*pi/20))
>Opening default cgm plotter.
>Opening graphics window 0.
>>>> ez.cgm("send")
>Opening plot file Aa00.cgm.
>>>> ez.ps("send")
>Opening plot file Aa00.ps.
>Traceback (innermost last):
>  File "<stdin>", line 1, in ?
>  File "/home/jcollins/python-dev/myplot.py", line 641, in ps
>    if new_frame == "no" :
>NameError: new_frame

Sigh. I'll never worry about lack of things to do again,
with friends like you.  ;-}

Zane

--------------------------------------
Zane C. Motteler
Computer Scientist, LCP, X, and A Divisions
Lawrence Livermore National Laboratory
7000 East Avenue, L-038
Livermore, CA 94550-9234
925/423-2143, FAX 925/423-9969
zcm@llnl.gov




From zcm@llnl.gov  Thu Jul 22 21:46:49 1999
From: zcm@llnl.gov (Zane Motteler)
Date: Thu, 22 Jul 1999 13:46:49 -0700
Subject: [Matrix-SIG] ezplot problems
Message-ID: <v03130317b3bd33ab7713@[128.115.36.161]>

>Date: Thu, 22 Jul 1999 13:45:50 -0700
>To: "Jeffery D. Collins" <jcollins@pacificnet.net>
>From: Zane Motteler <zcm@llnl.gov>
>Subject: Re: [Matrix-SIG] ezplot problems
>Cc:
>Bcc:
>X-Attachments:
>
>Jeff,
>
>Here's the patch (the line numbers are with respect to the
>new version with the previous patch).
>
>***************
>*** 549,554 ****
>--- 549,556 ----
>        new_frame = kw ["new_frame"]
>     elif _ezcshow_ == "false" :
>        new_frame = "no"
>+    else :
>+       new_frame = "yes"
>     if val == "on" or val == "ON" or val == "On" \
>        or val == "open" or val == "OPEN" or val == "Open" :
>        _ps_ = "yes"
>
>Cheers,
>
>Zane
>

--------------------------------------
Zane C. Motteler
Computer Scientist, LCP, X, and A Divisions
Lawrence Livermore National Laboratory
7000 East Avenue, L-038
Livermore, CA 94550-9234
925/423-2143, FAX 925/423-9969
zcm@llnl.gov




From zcm@llnl.gov  Fri Jul 23 16:37:11 1999
From: zcm@llnl.gov (Zane Motteler)
Date: Fri, 23 Jul 1999 08:37:11 -0700
Subject: [Matrix-SIG] updated Graphics, Numeric
Message-ID: <v03130321b3be3a4c2c1c@[128.115.36.161]>

To matrix-sig colleagues:

In recent weeks I have made a number of bug fixes to the Graphics
subdirectory of LLNLDistribution. In addition, I have moved
arrayfnsmodule.c from Graphics to Numerical, as it seems more
appropriately placed there.

At this point we are not ready for a full release of
LLNLDistribution, but I have tarred up LLNLDistribution/Graphics
and LLNLDistribution/Numerical and placed them on our
anonymous ftp site for those of you who would like the
latest and greatest. Here's the URL:

   ftp://ftp-icf.llnl.gov/pub/motteler/GraphNum.tar.gz

Please keep me apprised of any further problems with Graphics.
(You can bug Paul Dubois about everything else. ;) Many thanks
to those members of the Python community who have kept me on
my toes with bug reports.

Zane

--------------------------------------
Zane C. Motteler
Computer Scientist, LCP, X, and A Divisions
Lawrence Livermore National Laboratory
7000 East Avenue, L-038
Livermore, CA 94550-9234
925/423-2143, FAX 925/423-9969
zcm@llnl.gov




From tismer@appliedbiometrics.com  Fri Jul 23 19:06:33 1999
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 23 Jul 1999 20:06:33 +0200
Subject: [Matrix-SIG] FFT:real_fft/FFT:inverse_real_fft
References: <Pine.LNX.3.96.990714112229.25208A-100000@pfiesteria.gsfc.nasa.gov>
Message-ID: <3798AF29.4F3EC6FB@appliedbiometrics.com>


"Warren B. Focke" wrote:
...
> real_fft:               Fixed.  Does what it was intended to.
> real_inverse_fft:       Does the inverse of real_fft.
> 
> hermite_fft:            Takes the nonnegative time portion of data with
>                         hermitian symmetry, returns the (real) frequency
>                         domain representation of that data.
> hermite_inverse_fft:    Does the inverse of hermite_fft - this is what
>                         inverse_real_fft was meant to do.
> 
> inverse_real_fft:       Another name for hermite_inverse_fft.

Wonderful. Thanks :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home


From vanandel@ucar.edu  Fri Jul 23 21:46:43 1999
From: vanandel@ucar.edu (Joe Van Andel)
Date: Fri, 23 Jul 1999 14:46:43 -0600
Subject: [Matrix-SIG] Limiting size of arrays printed by Numeric
References: <Pine.LNX.3.96.990714112229.25208A-100000@pfiesteria.gsfc.nasa.gov> <3798AF29.4F3EC6FB@appliedbiometrics.com>
Message-ID: <3798D4B3.3DA90187@ucar.edu>

I'm writing a radar data processing system that uses fairly large
arrays.  (360 x 900).  When I have a list or dictionary that contains
such an array, I frequently want to see just the size and type of the
array,
 without getting all the content printed by the default repr() function. 
Otherwise, using Numeric Python interactively is rather awkward, since
you never know when you may end up accidently printing out some enormous
(Megabytes!) amount of data.


 Has anyone over-ridden the repr() function to have thresholds that
would print "small" arrays as usual, but would print large arrays as
something like:

array(500x300, FLOAT)

How do I over-ride the built in function?  Once I over-ride it, how do I
access the original built-in function?

Thanks much, I appreciate your help.


-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu


From rburnham@cri-inc.com  Fri Jul 23 23:29:56 1999
From: rburnham@cri-inc.com (Roger Burnham)
Date: Fri, 23 Jul 1999 14:29:56 -800
Subject: [Matrix-SIG] Limiting size of arrays printed by Numeric
In-Reply-To: <3798D4B3.3DA90187@ucar.edu>
Message-ID: <199907232129.QAA00278@mail1.gte.net>

On 23 Jul 99, at 14:46, Joe Van Andel mused:

> I'm writing a radar data processing system that uses fairly large
> arrays.  (360 x 900).  When I have a list or dictionary that contains
> such an array, I frequently want to see just the size and type of the
> array,
>  without getting all the content printed by the default repr() function. 
> Otherwise, using Numeric Python interactively is rather awkward, since
> you never know when you may end up accidently printing out some enormous
> (Megabytes!) amount of data.
> 
> 
>  Has anyone over-ridden the repr() function to have thresholds that
> would print "small" arrays as usual, but would print large arrays as
> something like:
> 
> array(500x300, FLOAT)
> 
> How do I over-ride the built in function?  Once I over-ride it, how do I
> access the original built-in function?
> 
> Thanks much, I appreciate your help.

Joe,

This is taken from a windows specific app that gives the user the choice of 
printing the arrary or not.  Should give you the idea...

_opts = {
    'maxLineWidth': 132,
    'precision': 4,
    'suppressSmall': 1,
    'maxElements': 1024,
   }

def _checkSize(a):
    '''Helper to ensure that one does not accidentally try to print a
    huge array (kiss the process good-bye if you do!).
    '''
    size = 1
    for dimSize in a.shape:
        size = size * dimSize
    if size > _opts['maxElements']:
        msg = '''
You have asked to print a very large array.

This array contains %d elements and may take a very
long time and use a lot of memory to actually convert
to a string.

Do you really wish to convert this array to a string?

''' % size
        ans = win32ui.MessageBox(msg, 'Really print the array?',
                                 (win32con.MB_YESNO|
                                  win32con.MB_ICONQUESTION|
                                  win32con.MB_SYSTEMMODAL))
        return (ans == win32con.IDYES)
    else:
        return 1
    
def my_array_repr(a,max_line_width=None, precision=None, suppress_small=None):
    '''Replacement for Numeric.array_repr to check for too large of a string
    conversion, and a way for the user to change the conversion parameters.
    '''
    if max_line_width == None:
        max_line_width = _opts['maxLineWidth']
    if precision == None:
        precision = _opts['precision']
    if suppress_small == None:
        suppress_small = _opts['suppressSmall']
    if _checkSize(a):
        return array2string(a, max_line_width, precision,
                            suppress_small, ', ', 1)
    else:
        return '<array_repr cancelled>'

def my_array_str(a, max_line_width=None, precision=None, suppress_small=None):
    '''Replacement for Numeric.array_str to check for too large of a string
    conversion, and a way for the user to change the conversion parameters.
    '''
    if max_line_width == None:
        max_line_width = _opts['maxLineWidth']
    if precision == None:
        precision = _opts['precision']
    if suppress_small == None:
        suppress_small = _opts['suppressSmall']
    if _checkSize(a):
        return array2string(a, max_line_width, precision,
                            suppress_small, ' ', 0)
    else:
        return '<array_str cancelled>'

# Replace Numeric.array_repr and Numeric.array_str with our "friendly"
# versions.

import Numeric
Numeric.array_repr = my_array_repr
Numeric.array_str = my_array_str

# Do the same for the multiarray module.

import multiarray
multiarray.set_string_function(my_array_str, 0)
multiarray.set_string_function(my_array_repr, 1)

# Clean up the namespace...

del Numeric
del multiarray


Cheers,

Roger Burnham   
Cambridge Research & Instrumentation   
rburnham@cri-inc.com   
http://www.cri-inc.com/   
http://starship.python.net/crew/roger/   
PGP Key: http://www.nai.com/default_pgp.asp   
PGP Fingerprint: 5372 729A 9557 5F36 177F  084A 6C64 BE27 0BC4 CF2D   


From vanandel@ucar.edu  Fri Jul 23 23:23:52 1999
From: vanandel@ucar.edu (Joe Van Andel)
Date: Fri, 23 Jul 1999 16:23:52 -0600
Subject: [Matrix-SIG] Limiting size of arrays printed by Numeric
References: <199907232129.QAA00278@mail1.gte.net>
Message-ID: <3798EB78.E0A3409B@ucar.edu>

This is a multi-part message in MIME format.
--------------009AE0FFEF300E5932AF0151
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Roger:
Thanks for the incredibly fast response to my question.  I wanted a
module I could re-use in multiple routines, and here's my first cut:


I may add some of the features Roger had in his procedure later, but for
now, I can use Numeric Python interactively without being buried by
unwanted output.
-- 

Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
--------------009AE0FFEF300E5932AF0151
Content-Type: text/plain; charset=us-ascii;
 name="NumUtil.py"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NumUtil.py"

# smarter array printing by limiting maximum size

MaxElems = 100
import Numeric

def smartArrayRepr(a, max_line_width = None, precision = None, suppress_small = None
):
    global MaxElems
    shape = a.shape
    elems =  Numeric.product(shape)
    if elems > MaxElems:
        return 'array(%s),%s'% (shape,a.typecode())
    else:
        return Numeric.array2string(a, max_line_width, precision, suppress_small, ', ',1)

def smartArrayStr(a, max_line_width = None, precision = None, suppress_small =None ):
    global MaxElems
    shape = a.shape
    elems =  product(shape)
    if elems > MaxElems:
        return 'array(%s),%s'% (shape,a.typecode())
    else:
        return Numeric.array2string(a, max_line_width, precision, suppress_small, ', ', 1)

# replace the default with a smarter function for huge arrays
Numeric.array_repr = smartArrayRepr
Numeric.array_str = smartArrayStr

# fixup multiarray, as well.
import multiarray
multiarray.set_string_function(smartArrayStr, 0)
multiarray.set_string_function(smartArrayRepr, 1)

--------------009AE0FFEF300E5932AF0151--



From dubois1@llnl.gov  Sun Jul 25 18:41:29 1999
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Sun, 25 Jul 1999 10:41:29 -0700
Subject: [Matrix-SIG] updated Graphics, Numeric
References: <v03130321b3be3a4c2c1c@[128.115.36.161]>
Message-ID: <005501bed6c4$ee008c60$f4160218@plstn1.sfba.home.com>

I am on vacation which led to a faulty communication with Zane. The
Numerical part of the tar file he just put out on the ftp site is definitely
not functional; please do not use it.

Our apologies for the error.

-- Paul Dubois

----- Original Message -----
From: Zane Motteler <zcm@llnl.gov>
To: <matrix-sig@python.org>
Cc: Sharon Wilson <wilson25@llnl.gov>; Fred N. Fritsch <fnf@llnl.gov>;
Charles F. Crabb <ccrabb@llnl.gov>; Lee Busby <leebusby@llnl.gov>; Stewart
A. Brown <sabrown@llnl.gov>; Dennis M. Braddy <braddy1@llnl.gov>
Sent: Friday, July 23, 1999 8:37 AM
Subject: [Matrix-SIG] updated Graphics, Numeric


> To matrix-sig colleagues:
>
> In recent weeks I have made a number of bug fixes to the Graphics
> subdirectory of LLNLDistribution. In addition, I have moved
> arrayfnsmodule.c from Graphics to Numerical, as it seems more
> appropriately placed there.
>
> At this point we are not ready for a full release of
> LLNLDistribution, but I have tarred up LLNLDistribution/Graphics
> and LLNLDistribution/Numerical and placed them on our
> anonymous ftp site for those of you who would like the
> latest and greatest. Here's the URL:
>
>    ftp://ftp-icf.llnl.gov/pub/motteler/GraphNum.tar.gz
>
> Please keep me apprised of any further problems with Graphics.
> (You can bug Paul Dubois about everything else. ;) Many thanks
> to those members of the Python community who have kept me on
> my toes with bug reports.
>
> Zane
>
> --------------------------------------
> Zane C. Motteler
> Computer Scientist, LCP, X, and A Divisions
> Lawrence Livermore National Laboratory
> 7000 East Avenue, L-038
> Livermore, CA 94550-9234
> 925/423-2143, FAX 925/423-9969
> zcm@llnl.gov
>
>
>
> _______________________________________________
> Matrix-SIG maillist  -  Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
>



From hinsen@cnrs-orleans.fr  Mon Jul 26 14:23:03 1999
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Mon, 26 Jul 1999 15:23:03 +0200
Subject: [Matrix-SIG] ScientificPython 2.0b1
Message-ID: <199907261323.PAA16775@chinon.cnrs-orleans.fr>

The first public beta release of ScientificPython 2.0 is now available
from
       http://starship.python.net/crew/hinsen/scientific.html
and
       http://dirac.cnrs-orleans.fr/programs/scientific.html

This is a completely revised release and *not* compatible with earlier
releases. The major difference is the introduction of a package
structure; all modules are now submodules of the top-level module
Scientific. Version 2 also includes the netCDF interface module, which
was previously in a separate distribution. Another important new
feature is full documentation :-)

Following established traditions in the Python community, I will be
on vacation for three weeks from Wednesday. Please take your time
to fix any bugs before reporting them to me ;-)
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From collins@seal.aero.org  Mon Jul 26 17:06:57 1999
From: collins@seal.aero.org (Jeff Collins)
Date: Mon, 26 Jul 1999 09:06:57 -0700
Subject: [Matrix-SIG] ezplot fixes/suggestions - again
Message-ID: <199907261606.JAA28700@malibu.sipnet>


I'm submitting these patches without fully understanding
the ezplot package, but they seem to fix the following problems:

1)  When cgm("on") is called before win("on"), then no x-window
is opened for plotting - only the cgm file is used.  The first portion
of the patch fixes this (though there is probably a better way).

2)  Corrected a typo to prevent font-lock problems in emacs

3)  Modified titles() to accept the window keyword, so that
different titles can be placed on different windows.  It wasn't
clear how to accomplish this without the fix.

Thanks,

Jeff




--- /usr/local/lib/python1.5/site-packages/oog/ezplot.py	Fri Jun 11 10:20:19 1999
+++ ezplot.py	Fri Jul 23 11:34:25 1999
@@ -227,8 +227,17 @@
    if val == "on" or val == "ON" or val == "On" \
       or val == "open" or val == "OPEN" or val == "Open" :
       _window_number_ = _check_win_ (_window_number_)
-      if _window_number_ == []:
+      _file_windows_ = []
+      _win_windows_ = _window_number_[:]
+      if _cgm_plotter_ in _win_windows_:
+         _file_windows_.append(_cgm_plotter_)
+         del _win_windows_[_cgm_plotter_]
+      if _ps_plotter_ in _win_windows_:
+         _file_windows_.append(_ps_plotter_)
+         del _win_windows_[_ps_plotter_]
+      if _win_windows_ == []:
          _window_number_ = [_get_free_win_number_ ( )]
+         _window_number_ = _window_number_ + _file_windows_
          if _window_number_ [0] < 0 :
             raise _WinSpecError_, "win ('open'): all windows are in use."
       for i in _window_number_:
@@ -267,7 +276,7 @@
 
 def new_plot_file ( filename ) :
    """new_plot_file ( ) will eventually return the name of the next
-   available file in the sequence "Aa00.ps/cgm", Ab00.ps/cgm", etc.
+   available file in the sequence "Aa00.ps/cgm", "Ab00.ps/cgm", etc.
    """
    if not os.path.isfile ("./" + filename) :
       return filename
@@ -508,6 +517,8 @@
             GistPlotter.Plotter ( "none" , n = _cgm_plotter_, hcp = _cgm_file_)
       _win_plotters_ [_cgm_plotter_].set_bytscl (_cmin_, _cmax_)
       _set_axis_limits_ ( )
+      if not hasattr (cgm, "win_no") :
+         win_no = _win_plotters_ [_cgm_plotter_]._n
       if _cgm_plotter_ != win_no :
          _object_list_ [_cgm_plotter_] = _object_list_ [win_no]
       if _current_graph_ [_cgm_plotter_] == None :
@@ -546,7 +557,9 @@
    if kw.has_key ("new_frame") :
       new_frame = kw ["new_frame"]
    elif _ezcshow_ == "false" :
-      new_frame = "no"
+      new_frame = "no" 
+   else:
+      new_frame = "yes"
    if val == "on" or val == "ON" or val == "On" \
       or val == "open" or val == "OPEN" or val == "Open" :
       _ps_ = "yes"
@@ -614,6 +627,8 @@
             GistPlotter.Plotter ( "none" , n = _ps_plotter_, hcp = _ps_file_)
       _win_plotters_ [_ps_plotter_].set_bytscl (_cmin_, _cmax_)
       _set_axis_limits_ ( )
+      if not hasattr (cgm, "win_no") :
+         win_no = _win_plotters_ [_cgm_plotter_]._n
       if _ps_plotter_ != win_no :
          _object_list_ [_ps_plotter_] = _object_list_ [win_no]
       if _current_graph_ [_ps_plotter_] == None :
@@ -743,7 +758,7 @@
    else :
       _displays_ = vals
 
-def titles (* vals) :
+def titles (*vals, **keywords):
    global _titles_
    if len (vals) == 0 :
       _titles_ = [defbot, deftop, defleft, defright]
@@ -761,6 +776,11 @@
       else :
          _titles_ [2] = defleft
          _titles_ [3] = defright
+   if keywords.has_key ("window") :
+      window = keywords ["window"]
+   else :
+      window = "all"
+   sf( window=window)
 
 def titleb (val) :
    global _titles_



From scolsen@uci.edu  Mon Jul 26 18:21:35 1999
From: scolsen@uci.edu (scolsen@uci.edu)
Date: Mon, 26 Jul 1999 10:21:35 -0700
Subject: [Matrix-SIG] c histogram module
Message-ID: <7ni5ev$qshh@eGroups.com>

Hi,

I've written some modules that I thought others might be interested in,
including a histogram module in c that's pretty fast and doesn't 
upcast all types.

http://essgrad.ps.uci.edu/~olsen/Pages/LinuxPython/Tools.html

I hope someone finds them useful.
Please let me know if you find any bugs.

Seth Olsen
scolsen@uci.edu