headers
Michel Sanner | 1 Feb 2001 21:29
Picon
Favicon

New packages

Hello,

Is there any reason why Numeric never became a "New" Python package with a
__init__.py ?

-Michel

PS: I have been adding __init__.py to my installation for a long time now and
it works just fine. For those who want to be able to import directly we could
extend the python path in __init__ so that after an import Numeric all .so
would be directly loadable

--

-- 

-----------------------------------------------------------------------

>>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sanner <at> scripps.edu                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Paul F. Dubois | 2 Feb 2001 16:16

RE: New packages

Well, we talked about it some but didn't want to break existing code. To my
recollection nobody has suggested the trick you suggest here. I think it
would work, although there are cases where people import Precision in a
given module but not Numeric (the numeric objects they deal with get
returned by C or Fortran calls). Anybody see any real downside here?

-----Original Message-----
Is there any reason why Numeric never became a "New" Python package with a
__init__.py ?

-Michel

PS: I have been adding __init__.py to my installation for a long time now
and
it works just fine. For those who want to be able to import directly we
could
extend the python path in __init__ so that after an import Numeric all .so
would be directly loadable

--

-----------------------------------------------------------------------

>>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jon Moody | 3 Feb 2001 22:16
Picon
Favicon

cephes.arraymap & multipack

Two questions:

* Has anyone been using the arraymap function that's in Travis's
  cephes 1.2 module?  I think this is an interesting idea: giving
  arbitrary python functions ufunc-like (array broadcasting)
  properties when given numpy array arguments.  (I noticed the Pearu's
  multipack CVS module has only cephes 1.1 which seems to be missing
  arraymap)

* Maybe I'm missing something, but is there any reason why multipack's
  functions are not implemented as ufuncs?  For example, it would be
  useful to be able to use multipack.leastsq() along an axis of a 3-d
  array, or to use multipack.quad() over a 2 or 3-d space of
  integration parameters.

--
Jon Moody
Permalink | Reply | 2 comments |
headers
John J. Lee | 4 Feb 2001 03:45
Picon
Picon

Re: cephes.arraymap & multipack

On Sat, 3 Feb 2001, Jon Moody wrote:
[...]
> * Maybe I'm missing something, but is there any reason why multipack's
>   functions are not implemented as ufuncs?  For example, it would be
>   useful to be able to use multipack.leastsq() along an axis of a 3-d
>   array, or to use multipack.quad() over a 2 or 3-d space of
>   integration parameters.
[...]

Not sure aboout the latter, but couldn't the former just be done by
slicing?  How does this relate to ufuncs?

They were only intended to be simple wrappings around the FORTRAN / C I
think, so I suspect Travis would say 'feel free to add it'.

John
Permalink | Reply | 1 comment |
headers
Nils Wagner | 5 Feb 2001 15:38
Picon
Favicon

Python routines for evaluation of special functions

Hi,

I am looking for Python routines for evaluation of special functions,
including Airy, Bessel, beta, exponential integrals, logarithmic
integrals.

Thanks

                                        Nils
Permalink | Reply | 0 comments |
headers
Jon Moody | 5 Feb 2001 17:56
Picon
Favicon

Re: cephes.arraymap & multipack

On Sun, Feb 04, 2001 at 02:45:51AM +0000, John J. Lee wrote:
> Not sure aboout the latter, but couldn't the former just be done by
> slicing?  How does this relate to ufuncs?

I'm probably being a little foggy on the distinction between the
ufuncs (element-wise operations on arrays) and the array functions
that sometimes allow you to specify an axis along which to apply the
function.

The problem I'm having with multipack.leastsq() is that the python
function I supply as the model for the fit is expected to return a 1-d
array or a single value.

So if, for example, the independent variable is a 1-d array of shape
(4,) and the data is a 3-d array of shape (4,256,256), to apply
leastsq() along axis 0 you have to either loop in python or set things
up so that you can map(leastsq, ....).  

It seems this kind of thing should properly be in the wrapper, and I
would guess it should be in the C half of the wrapper for speed,
unless there's some clever way to phrase it using native Numeric
functions from python.

> 
> They were only intended to be simple wrappings around the FORTRAN / C I
> think, so I suspect Travis would say 'feel free to add it'.

Maybe I should try.  Is there any general objection (don't all barf at
once) to using Fortran for an wrapper via pyfort (I don't know C)?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berthold Höllmann | 6 Feb 2001 10:31

more general LAPACK support for NumPy

Hello,

From time to time we need an additional linear algebra routine to be
avaible in Python. I find myself wrapping these functions then. As
these are FORTRAN routines, doing this for Python version on Solaris
(Sun CC/Sun F77), linux (gcc/g77) and Windows (VC++/Digital VF)
becomes nontrivial. Neither f2py nor pyfort provide Win support and I
doubt that automatic generation is usefull for many LAPACK routines,
especially those that need workspace, because usually we want LWORK to
be the optimal size.

So my Question is, are there other users wrapping LAPACK routines for
NumPy. If so, how are you doing it. For the C/FORTRAN wrapping I
somehow like the approach used for cfortran.h (see
http://www-zeus.desy.de/~burow/cfortran/index.html), but I'm afraid,
the license is not acceptable.

Is anyone aware of a C version of LAPACK besides the f2c version on
netlib. I do like the approach used in the ATLAS clapack part, but
there are only a very few LAPACK routines handeled there. If there is
greater need for additional LAPACK routines for NumPy, should we
bundle the efforts in

 (a) developing guidelines for how to write Python wrappers for LAPACK
     routines and

 (b) collecting routines provided by different users to provide a
     hopefully growing support for LAPACK in Python.

Greetings
(Continue reading)

Permalink | Reply | 4 comments |
headers
Janko Hauser | 6 Feb 2001 13:07
Picon

Re: more general LAPACK support for NumPy

There is an old binding to the complete CLapack package, which can be
found at 

ftp://dirac.cnrs-orleans.fr/pub/PyLapack.tar.gz

It does not seem to have special support for Windows, but one can perhaps
start from there. I have tried cfortran ones and the wrapped function
signatures become quite long and verbose. I think one important
extension would be to make the automatic wrapper generators pyfort and
f2py support some windows compilers, although I must admit, I have not
looked into them for windows support yet.

__Janko
Permalink | Reply | 3 comments |
headers
Berthold Höllmann | 6 Feb 2001 14:55

Re: more general LAPACK support for NumPy

OK, I got, compiled and installed PyLapack.tar.gz. It looks quite
complete, for LAPACK 1 or 2, but, of course those routines I need are
new in LAPACK 3 :-(. 

It seemes, Doug Heisterkamp used some kind of a script or program to
generate the wrapper. Is there anyone who knows, whether this program
is avaible anywhere, so it could be extended for LAPACK 3 and Win?

Thanks

Berthold
--

-- 
       email: hoel <at> GermanLloyd.org
   )   tel. : +49 (40) 3 61 49 - 73 74
  (
C[_]  These opinions might be mine, but never those of my employer.
Permalink | Reply | 0 comments |
headers
Paul F. Dubois | 6 Feb 2001 16:26

RE: more general LAPACK support for NumPy

Two notes in regard to this thread:
1. I am in progress making Pyfort support Digital Visual Fortran on Windows.
2. Pyfort does have a facility for automatic allocation of work space, at
least in the case that the size can be computed using ordinary arithmetic
from the sizes of other arguments or other integer arguments.

-----Original Message-----
From: numpy-discussion-admin <at> lists.sourceforge.net
[mailto:numpy-discussion-admin <at> lists.sourceforge.net]On Behalf Of Janko
Hauser
Sent: Tuesday, February 06, 2001 4:08 AM
To: Berthold Hollmann
Cc: numpy-discussion <at> lists.sourceforge.net
Subject: Re: [Numpy-discussion] more general LAPACK support for NumPy

There is an old binding to the complete CLapack package, which can be
found at

ftp://dirac.cnrs-orleans.fr/pub/PyLapack.tar.gz

It does not seem to have special support for Windows, but one can perhaps
start from there. I have tried cfortran ones and the wrapped function
signatures become quite long and verbose. I think one important
extension would be to make the automatic wrapper generators pyfort and
f2py support some windows compilers, although I must admit, I have not
looked into them for windows support yet.

__Janko
Permalink | Reply | 1 comment |

Gmane