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

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

[Chris B. <Chr...@no...>]

Jochen Küpper wrote:
> "Chris Barker" <Chr...@no...> writes:
>>Do you mean this? :
> yes

OK, so I've done what I can.

> To find out you might have to look at the LAPACK functions you are
> using and compare them against the ones provided by ATLAS.

Well, I'm testing using LinearAlgebra.solve_linear_equations() from 
Numeric (and numarray). The reason I'm wondering is that on my last 
machine, a 1ghz PIII laptop running Gentoo, using the Gentoo provided 
atlas/lapack, I got a 6-7 times speed up over lapack_lite.

On my new machine, a 2GHz Pentium M laptop running FC4, I got about a 2 
times speed-up, which is nice, but not nearly as impressive.

Another possible issue is that I used pre-complied binaries form the 
atlas site, which are a bit old, maybe I should compile myself. Any 
thoughts?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[Numpy-discussion] New e-mail address

[Pieter v. B. <pi...@dj...>]

*English follows below*


Geachte relatie,


Ooit (misschien recent, misschien al weer jaren geleden) heeft u e-mail 
verstuurd naar mijn voormalige e-mail adres: _vanbeek@q-factor.nl_.

Bij deze wil ik u mededelen dat mijn e-mail adres is gewijzigd in 
pi...@dj.... Gelieve deze wijziging door te voeren in uw 
adresbestand.


Met vriendelijke groet,
Pieter van Beek

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

Dear relation,


Once (maybe recently, maybe years ago) you have been sending mail to my 
former e-mail address: _vanbeek@q-factor.nl_.

Hereby I'd like to inform you that my e-mail address has changed into 
pi...@dj.... Please change my e-mail address in your address book.


Kind regards,
Pieter van beek

[Numpy-discussion] Interfacing to other array classes

[Joachim D. <jo...@ee...>]

I am one the authors of 'cvxopt', a Python package that includes simple 
matrix classes aimed at numerical linear algebra for convex solvers, and 
I saw the discussion on the list regarding interfacing to such classes.

I think the idea of an advanced interface or buffer protocol
to exchange information between simple array types without using
(or knowing) the API of the different classes is great.

What is the status of the new array interface? When it is ready for testing,
I will definitely try it out.

- Joachim

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

[Chris B. <Chr...@no...>]

Jochen Küpper wrote:
>>Does anyone have a suggestion for how to add the addional lapack
>>stuff I need, while still using atlas stuff where possible?
> 
> See the ATLAS installation manual.

Thanks for the tip.

Do you mean this? :

"""
******** GETTING A FULL LAPACK LIB **************************
ATLAS does not provide a full lapack library.  However, there is a 
simple way
to get ATLAS to provide its faster LAPACK routines to a full LAPACK library.
ATLAS's internal routines are distinct from LAPACK's, so it is safe to 
compile
ATLAS's LAPACK routines directly into a netlib-style LAPACK library.
First, obtain the LAPACK src from netlib and build the LAPACK library as
normal.  Then, in this directory (where you should have a liblapack.a),
issue the following commands:
   mkdir tmp
   cd tmp
   ar x ../liblapack.a
   cp <your LAPACK path & lib> ../liblapack.a
   ar r ../liblapack.a *.o
   cd ..
   rm -rf tmp

Just linking in ATLAS's liblapack.a first will not get you the best LAPACK
performance, mainly because LAPACK's untuned ILAENV will be used instead
of ATLAS's tuned one.
"""

If so, I did that (see a later post to this list). However, I found that 
I got about the same performance improvement doing this as I had gotten 
compiling against just the atlas BLAS and lapack_lite. It makes me 
wonder if I'm really getting the benefit of atlas lapack.

I don't' have hard-core performance needs at the moment, so I'm done, 
but I'm still surprised I couldn't find a ready-to-go atlas rpm for 
Fedora Core 4. It actually makes me miss Gentoo.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] convolve

[<rba...@cl...>]

Le Jeudi 28 Juillet 2005 03:26, Alan G Isaac a =E9crit :
> On Wed, 27 Jul 2005, Robert Kern apparently wrote:
> > Whatever problem that once existed is now fixed in CVS.

Yes, it works !

Thanks,

Ren=E9
>
> Great!
>
> Thanks,
> Alan
>
>

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

[<jo...@fh...>]

"Chris Barker" <Chr...@no...> writes:

> Does anyone have a suggestion for how to add the addional lapack
> stuff I need, while still using atlas stuff where possible?

See the ATLAS installation manual.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re[2]: [Numpy-discussion] convolve

[Alan G I. <ai...@am...>]

On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
> Whatever problem that once existed is now fixed in CVS.=20

Great!

Thanks,
Alan

Re: [Numpy-discussion] convolve

[Robert K. <rk...@uc...>]

Alan G Isaac wrote:
>>>On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
>>>
>>>>I do not see the behavior Ren=E9 is claiming. Perhaps Ren=E9=20
>>>>can tell us what version of numarray he is using?=20
>=20
>>Alan G Isaac wrote:=20
>>
>>>I see it in version 1.1,=20
>>>for the example he provided.=20
>=20
> On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
>=20
>>What example? Either his message has not yet propogated to me or the=20
>>mailing list archives, or he sent it to you privately. The problem does=
=20
>>not seem to exist any longer in CVS.=20
>=20
> My bad.
> It was indeed off list.
> It is (essentially) replicated below.

Whatever problem that once existed is now fixed in CVS. The example you=20
give works fine.

--=20
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Re[2]: [Numpy-discussion] convolve

[Alan G I. <ai...@am...>]

>> On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
>>> I do not see the behavior Ren=E9 is claiming. Perhaps Ren=E9=20
>>> can tell us what version of numarray he is using?=20

> Alan G Isaac wrote:=20
>> I see it in version 1.1,=20
>> for the example he provided.=20

On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
> What example? Either his message has not yet propogated to me or the=20
> mailing list archives, or he sent it to you privately. The problem does=
=20
> not seem to exist any longer in CVS.=20

My bad.
It was indeed off list.
It is (essentially) replicated below.
Alan


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

#-*-coding:latin-1-*-
#from Numeric import arrayrange,asarray
#from Numeric import convolve
from numarray import arrayrange,asarray
from numarray.convolve.Convolve import convolve
=20
def explo0():
    a=3Darrayrange(10.)
    b=3Dasarray([1., 0., 2., -1., 3., -2.])
    c=3Dconvolve(a, b)
    print c
    d=3Dconvolve(b, a)
    print d

 =20
if __name__=3D=3D"__main__":
    explo0()

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Mon, 2005-07-25 at 22:39 -0700, Robert Kern wrote:
> Soeren Sonnenburg wrote:
>
> [snip]
> 
> > In my eyes 'array broadcasting' is confusing and should rather be in a
> > function like meshgrid and instead a*b should return
> > matrixmultiply(a,b) ...
> 
> Spend some time with it. It will probably grow on you. Numeric is not 
[...]
> Again, Numeric is a package for arrays, not just linear algebra. Please 
> spend some more time with Python and Numeric before deciding that they 
> must be changed to match your preconceptions.

I realize that I just need plain matrices and operations on them so I am
probably better off with cvxopt at that point.

> > I realize that with lists it is ok to grow them via slicing.
> > 
> > x=[]
> > x[0]=1
> > IndexError: list assignment index out of range
> > x[0:0]=[1]
> > x
> > [1]
> > 
> > that seems not to work with numarray ... or ?
> > 
> > y=array()
> > y[0]=1
> > TypeError: object does not support item assignment
> > y[0:0]=array([1])
> > TypeError: object does not support item assignment
> 
> Python lists are designed to grow dynamically. Their memory is 
> preallocated so that growing them is on average pretty cheap. Numeric 
> arrays are not, nor will they be.

Well I don't claim that this is/must be efficient. It is just what I
would have expected to work if I use standard python arrays and now
numarrays.

Soeren.

Re: [Numpy-discussion] 2-D FFT input/ouput storage

[Robert K. <rk...@uc...>]

Daniel Sheltraw wrote:
> Hello All
> 
> Now that I have Numeric loading properly at the Python command line I
> went in search of some docs on the 2-D FFT. How are the input and output
> to the forward and inverse 2-D FFTs stored? Is it simply a 2-D version
> of the 1-D storage? When I do "print FFT.inverse_fft2d.__doc__" I get no
> helpful info about storage.

The 2-D layout follows directly as a consequence of the 1-D layout and 
the definition of a 2-D FFT.

In [14]: import FFT

In [15]: def my2dfft(A):
    ....:     A = array(A, Complex)
    ....:     for i in range(A.shape[0]):
    ....:         A[i] = FFT.fft(A[i])
    ....:     for i in range(A.shape[-1]):
    ....:         A[:,i] = FFT.fft(A[:,i])
    ....:     return A
    ....:

In [16]: A = reshape(arange(16.), (4,4))

In [17]: my2dfft(A)
Out[17]:
array([[ 120. +0.j,   -8. +8.j,   -8. +0.j,   -8. -8.j],
        [ -32.+32.j,    0. +0.j,    0. +0.j,    0. +0.j],
        [ -32. +0.j,    0. +0.j,    0. +0.j,    0. +0.j],
        [ -32.-32.j,    0. +0.j,    0. +0.j,    0. +0.j]])

In [18]: FFT.fft2d(A)
Out[18]:
array([[ 120. +0.j,   -8. +8.j,   -8. +0.j,   -8. -8.j],
        [ -32.+32.j,    0. +0.j,    0. +0.j,    0. +0.j],
        [ -32. +0.j,    0. +0.j,    0. +0.j,    0. +0.j],
        [ -32.-32.j,    0. +0.j,    0. +0.j,    0. +0.j]])

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Tue, 2005-07-26 at 09:37 -0400, Perry Greenfield wrote:
> On Jul 26, 2005, at 12:35 AM, Soeren Sonnenburg wrote:
[...]
> > Hmmhh while we are at it, is there work on a consensus num* ? I've seen
> > the PEP for inclusion of numarray, now I see numeric3 and scipy and  
> > also
> > cvxopt - are people actually converging towards a single num* package ?
> >
> That's what the goal of Numeric3 is as far as different underlying  
> array engines. But if you mean a merging of the array/matrix  
> viewpoints, I think you've answered your own question.

As Alan and Travis suggested Matrices scipy.mat, one could have matrices
more or less independently of num* if one could convert them back and
forth. Doing so would even allow for doing things differently, like
getting submatrices, allowing for real matrix-matrix multiplication etc.

However that of course kills consistency.

Soeren

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Wed, 2005-07-27 at 02:02 -0600, Travis Oliphant wrote:
> Soeren Sonnenburg wrote:
> 
> >I am realizing that this must have been why cvxopt switched away from
> >numarray/numeric. There slicing/indexing and '*' work as I would have
> >expected:
> >  
> >
> cvxopt uses it's own classes because they did not feel that a general 
> purpose array was needed.  They wanted to define a matrix class with 
> sparse matrix and dense matrix sub-classes.   In fact, cvxopt's matrix 
> classes can not be used as ubiquitously as Numeric/numarray arrays.   
> Everything is not a matrix.  In fact, I would like to see more general 
> linear algebra routines that allow people to more naturally deal with 
> (for example) six-dimensional linear operators mapping from a 
> three-dimensional space to a three-dimensional space.  Currently, you 
> are forced to perform an artificial row-scanning procedure just to 
> interface with matrix libraries.  Scipy can help with this kind of thing.

Hmmhh, 

> I do not see cvxopt as a competing array implementation.   At some 
> point, hopefully cvxopt will be integrated with scipy.  I am continually 
> looking for feasible ways to make scipy more attractive to 
> contributors.  Everybody benefits when their is a standard 
> infrastructure.   For example, there are sparse matrices in SciPy.  If 
> cvxopt has better sparse matrix objects, I would love to use them.  
> Hopefully, the array interface will assist on a more abstract scale so 
> that memory re-use can occur for at least the dense cvxopt matrices.

I guess we now observe the different communities different expectations
problem :/ In any case I agree that a standard infrastructure is very
desirable. However it might come at a cost one might not want to pay,
but still at least conversion functions from say cvxopt <-> numarray are
worth spending time on.

> >It now seems very difficult for me to end up with a single
> >numeric/matrix package that makes it into core python - which is at the
> >  
> >
> >same time very sad.
> >  
> >
> 
> Their are several issues here.  But, yes a Matrix object will always be 
> a separate object just as quaternions should be because they represent 
> an interpretation to a memory block.  In Numeric/numarray the focus is 
> on generic multidimensional arrays.  Therefore numeric operators must be 
> element-by element. 

OK.

> Note that Numeric does have a Matrix object that allows you to use '*' 
> to represent matrix multiplication.   It's only problem is that passing 
> this object to a function usually returns an array again instead of a 
> Matrix. 

So the cvxopt approach is pretty valid, doing everything for matrices as
they do, but allowing other types as 'int' etc..

Soeren

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Tue, 2005-07-26 at 09:30 -0700, Chris Barker wrote:
> Soeren Sonnenburg wrote:
> > Hmmhh. I see that this again breaks with R/octave/matlab. One should not
> > do so if there is no serious reason. It just makes life harder for every
> > potential convert from any of these languages.
> 
> If you're looking for a matlab clone, use octave or psilab, or....

No I am not, I am sold to python.

> Speaking as an ex-matlab user, I much prefer the NumPy approach. The
> reason is that I very rarely did linear algebra, and generally used
> matlab as a general computational environment. I got very tired of
> having to type that "." before all my operators. I also love array
> broadcasting, it seems so much cleaner and efficient.

Well coming from machine learning I am used to having just matrices.

> When I moved from Matlab to NumPy, I missed these things:
> 
> Integrated plotting: many years later, this is still weak, but at least
> for 2-d matplotlib is wonderful.

I agree here.

[no single numeric package in python]
> But I'm not sure we should be sad about it. What we all  want is the
> package best suited to our own needs to be in the standard library.
> However, I'd rather the current situation than having a package poorly
> suited to my needs in the standard library. As this thread proves, there
> is no one kind of array package that would fit even most people's needs.
> 
> However, there is some promise for the future:
> 
> 1) SciPy base may serve to unify Numeric/numarray
> 
> 2) Travis has introduced the "array interface"
> 
> http://numeric.scipy.org/array_interface.html
> 
> this would provide an efficient way for the various array and matrix
> packages to exchange data. It does have a hope of making it into the
> standard library, though even if it doesn't, if a wide variety of add-on
> packages use it, then the same thing is accomplished. If fact, if
> packages that don't implement an array type, but might use one (like
> PIL, wxPython, etc) accept this interface, then any package that
> implements it can be used together with them.
> 
> 3) What  about PEP 225: Elementwise/Objectwise Operators?
> It's listed under:
> 
> Deferred, Abandoned, Withdrawn, and Rejected PEPs
> 
> Which of those applied here? I had high hope for it one time.
> 
> By the way, I had not seen cvxopt before, thanks for the link. Perhaps
> it would serve as a better base for a full-featured linear algebra
> package than Numeric/numarray. Ideally, it could use the array
> interface, for easy exchange of data with other packages.

Actually that would be nice. Having had a closer look at cvxopt that
might suit *my* needs more, but having an interface to get cvxopt
matrices -> numarray/numeric without trouble to get certain potentially
missing functionality would be nice.

Thanks,
Soeren

[Numpy-discussion] Suggested Addition to the new array PEP

[Chris B. <Chr...@no...>]

Hi all, but particularly Travis,

I just took the time to read the new array PEP:

http://numeric.scipy.org/PEP.txt

It looks great.

I do have one suggestion for an addition method:

change_type(NewType) # or some other name:

Change the type that the bytes in the array represent, without changing 
the data at. Dimensions will change if the new type has a different 
itemsize than the old.

This would be the equivalent of:

A = Numeric.fromstring(A.tostring(), NewType)

but without the extra copies of the data.

When would anyone want this? I've written a function that does exactly 
this with Numeric arrays in order to efficiently slice, dice and 
re-arange a bunch of binary data files.

The files consist of a bunch of C structs written sequentially to a 
file. In this case the structs are: (long, long, char)

I have a file which is N of these structs written sequentially to a 
file, I can do:

NumBytes = 9 # number of bytes in a record
# Read the file
data = fromstring(file.read(NumBytes*NumTimesteps*NumLEs),UnsignedInt8)
file.close()

data.shape = (NumTimesteps,NumLEs,NumBytes)
# extract LE data:
LEs = data[:,:,:8].copy()
# extract the flags
flags = data[:,:,8].copy()
del data

# here I can create the Int32 array without making a copy:
# changetype returns a rank-1 array
changetype(LEs,Int32)

# It now gets reshaped to fit what it represents.
LEs.shape = (NumTimesteps,NumLEs,2)

I think it would only work in the general case with a contiguous array. 
All this really requires is to re-set the attributes of the array. with 
Numeric, the code is (for contiguous arrays):

     NewDescription = PyArray_DescrFromType(typecode);
     NewElementSize = NewDescription->elsize;

     if (TotalBytes % NewElementSize > 0){
       PyErr_SetString (PyExc_ValueError,
                        "The input array is the wrong size for the 
requested type");
       return NULL;
     }

     Array->descr = NewDescription;
     // does the old descr need to be freed?? how??

     Array->nd = 1;
     Array->strides[0] = NewElementSize;
     Array->dimensions[0] = TotalBytes / NewElementSize; The core


By the way, I'm also not seeing tostring() or tobuffer() listed in the PEP

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] convolve

[Robert K. <rk...@uc...>]

Alan G Isaac wrote:
> On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
>=20
>>I do not see the behavior Ren=E9 is claiming. Perhaps Ren=E9=20
>>can tell us what version of numarray he is using?=20
>=20
> I see it in version 1.1,
> for the example he provided.

What example? Either his message has not yet propogated to me or the=20
mailing list archives, or he sent it to you privately. The problem does=20
not seem to exist any longer in CVS.

--=20
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Re[2]: [Numpy-discussion] convolve

[Alan G I. <ai...@am...>]

On Wed, 27 Jul 2005, Robert Kern apparently wrote:=20
> I do not see the behavior Ren=E9 is claiming. Perhaps Ren=E9=20
> can tell us what version of numarray he is using?=20

I see it in version 1.1,
for the example he provided.

Cheers,
Alan Isaac

Re: [Numpy-discussion] convolve

[Robert K. <rk...@uc...>]

Alan G Isaac wrote:
> On Wed, 27 Jul 2005, Ren=E9 Bastian apparently wrote:=20
>=20
>>Outcommenting
>>if len(data) < len(kernel):
>>   data, kernel =3D kernel, data
>>in convolve.py gives the correct result.=20
>=20
> The author is not listed for this numarray module,
> so we cannot directly ask why this behavior was chosen.

This behavior was chosen for performance reasons. Since convolution is=20
commutative, it doesn't matter what order the arguments come in. I do=20
not see the behavior Ren=E9 is claiming. Perhaps Ren=E9 can tell us what=20
version of numarray he is using? or provide an example? I am using CVS=20
as of a week ago, I think.

In [10]: import numarray

In [11]: import numarray.convolve

In [12]: a =3D numarray.arange(10) + 1.

In [13]: b =3D numarray.arange(5) + 2.

In [14]: c =3D a - 1.

In [15]: numarray.convolve.convolve(a,b)
Out[15]:
array([   2.,    7.,   16.,   30.,   50.,   70.,   90.,  110.,  130.,
         150.,  148.,  133.,  104.,   60.])

In [16]: numarray.convolve.convolve(b,a)
Out[16]:
array([   2.,    7.,   16.,   30.,   50.,   70.,   90.,  110.,  130.,
         150.,  148.,  133.,  104.,   60.])

In [17]: numarray.convolve.convolve(a,c)
Out[17]:
array([   0.,    1.,    4.,   10.,   20.,   35.,   56.,   84.,  120.,
         165.,  210.,  244.,  266.,  275.,  270.,  250.,  214.,  161.,
          90.])

In [18]: numarray.convolve.convolve(c,a)
Out[18]:
array([   0.,    1.,    4.,   10.,   20.,   35.,   56.,   84.,  120.,
         165.,  210.,  244.,  266.,  275.,  270.,  250.,  214.,  161.,
          90.])

--=20
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Re: [Numpy-discussion] loading Numeric module

[Alan G I. <ai...@am...>]

On Wed, 27 Jul 2005, Daniel Sheltraw apparently wrote:=20
> Is there a way to give the full path within the import=20
> statement (when I try I get a syntax error message)?=20

import sys
sys.path.append("/path/to/myfiles")
import mystuff

hth,
Alan Isaac

Re[2]: [Numpy-discussion] convolve

[Alan G I. <ai...@am...>]

On Wed, 27 Jul 2005, Ren=E9 Bastian apparently wrote:=20
> Outcommenting
> if len(data) < len(kernel):
>    data, kernel =3D kernel, data
> in convolve.py gives the correct result.=20


The author is not listed for this numarray module,
so we cannot directly ask why this behavior was chosen.
You might use Numeric.convolve instead of
numarray.convolve.Convolve.convolve:
Numeric gives the expected result here.

fwiw,
Alan Isaac

[Numpy-discussion] 2-D FFT input/ouput storage

[Daniel S. <she...@un...>]

Hello All

Now that I have Numeric loading properly at the Python 
command line I
went in search of some docs on the 2-D FFT. How are the 
input and output
to the forward and inverse 2-D FFTs stored? Is it simply a 
2-D version
of the 1-D storage? When I do "print 
FFT.inverse_fft2d.__doc__" I get no
helpful info about storage.

Thanks,
Daniel

Re: [Numpy-discussion] loading Numeric module

[Robert K. <rk...@uc...>]

Daniel Sheltraw wrote:
> Hello all
> 
> When I try doing a "from Numeric import *" at the Python command line I get
> the error message "ImportError: No module named Numeric" so obviously
> the module is not in the path known to command line Python. However when
> the same import statement is part of a Python script file the module is
> found correctly. How do I fix this?

Are you sure that the Python interpreter is the same in both instances? 
Print sys.path before importing in both instances to see what paths are 
being searched.

> Is there a way to give the full path
> within the import statement (when I try I get a syntax error message)?

Not really, no.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

[Numpy-discussion] loading Numeric module

[Daniel S. <she...@un...>]

Hello all

When I try doing a "from Numeric import *" at the Python 
command line I get
the error message "ImportError: No module named Numeric" 
so obviously
the module is not in the path known to command line 
Python. However when
the same import statement is part of a Python script file 
the module is
found correctly. How do I fix this? Is there a way to give 
the full path
within the import statement (when I try I get a syntax 
error message)?

Thanks,
Daniel

Re: [Numpy-discussion] convolve

[Alan G I. <ai...@am...>]

On Tue, 26 Jul 2005, Ren=E9 Bastian apparently wrote:=20
> convolve(a,b)=3D=3Dconvolve(b,a)[::-1]

I do not see this behavior.
Can you post a self-contained example?

Thanks,
Alan Isaac

[Numpy-discussion] "Using Python for Interactive Data Analysis" tutorial available

[Perry G. <pe...@st...>]

A tutorial that illustrates how Python can be used to analyze and 
visualize astronomical data (much like one can do in IDL) has been 
written and now is available at:

http://www.scipy.org/wikis/topical_software/Tutorial

While much of the focus is on astronomical data, most of it probably 
could serve as a general tutorial as well if sections on more advanced 
pyfits usage are skipped (only a few pages). There are  appendices that 
contrast Python/numarray with IDL, I'd be happy to include the 
equivalent for Matlab if anyone who is familiar with both would like to 
write such appendices.

Suggestions for improvements are welcome.

Perry