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

[Numpy-discussion] Pyfort 3.1 at Source Forge

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

Pyfort,  a Python-Fortran connection tool, is now available at
pyfortran.sourceforge.net, instead of xfiles.llnl.gov. Documentation is
available at the site.

Version 3.1 uses distutils for easy extension building. A sample package is in
the test subdirectory.

Support for the pgf90 compiler on Linux is now available. Note that the
limitation to non-explicitly interfaced routines has not been removed yet, but
it will handle using pgf90-compiled F90 files in your Fortran.

Re: [Numpy-discussion] Derivatives

[Zow T. B. <zo...@pe...>]

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

Content-Type: text/plain; charset=us-ascii

> Whenever I see somebody implementing code based on "Numerical Recipies", I
> feel obligated to send them the following link:
> 
> http://math.jpl.nasa.gov/nr/nr.html
> 
Funny - that's the first thing I thought of too (just looking at it 
yesterday). Don't neglect to look at "the NR response" link buried at the very 
bottom of the page.

> YMMV, as always . . .
> 
More precisely, I think the point is that yourself or some other person so 
qualified should review any algorithm provided by a third party to ensure 
applicability to your problem domain.

> Kevin Rodgers

"Zow" Terry Brugger
zo...@ac...
zo...@ll...



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBOL1YI6fuGVwXgOQkEQIg7QCgtysc351lOuA3zP41XXaRZdhVoQ4An0S9
UWudL1u0qIvPZumAOVkAtEnA
=UXpc
-----END PGP SIGNATURE-----

RE: [Numpy-discussion] Derivatives

[Rodgers, K. <KRo...@ry...>]

Whenever I see somebody implementing code based on "Numerical Recipies", I
feel obligated to send them the following link:

http://math.jpl.nasa.gov/nr/nr.html

YMMV, as always . . .

Kevin Rodgers
Northrop Grumman Ryan Aeronautical Center
kro...@ry...

> -----Original Message-----
> From:	Hassan Aurag [SMTP:au...@cr...]
> Sent:	Wednesday, March 01, 2000 6:33 AM
> To:	Gma...@li...;
> num...@li...
> Subject:	[Numpy-discussion] Derivatives
> 
> 
> 
> Hi,
> 
> attached is a file called Derivative.py.
> 
> It computes derivatives and is based on an algorithm found in 
> Numerical Recipes in C.
> 
> What to do you think about it and has anyone started a "serious" 
> calculus oriented subpackage for Numerical Python in general?
> 
> I mean: derivatives, partial derivatives, jacobian, hessian 
> implemented fast and precise.
> 
> On another note, why isn't infinity defined in NumPy?
> 
> Why is tan(pi/2) a number even if big? Shouldn't it be infinity?
> 
>  
> 
> 
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Derivatives

[Hassan A. <au...@CR...>]

 The answer is yes!
 It is an 1e10 and not 1e-10. At 0.0 you got to pick the interval yourself. You 
can't just use the starting point x
 
 
> Date: Wed, 1 Mar 2000 16:06:28 +0100 (MET)
> From: Fredrik Stenberg <su9...@na...>
> To: Hassan Aurag <au...@CR...>
> Subject: Re: [Numpy-discussion] Derivatives
> MIME-Version: 1.0
> 
> > Hi,
> > 
> > attached is a file called Derivative.py.
> > 
> > It computes derivatives and is based on an algorithm found in 
> > Numerical Recipes in C.
> > 
> > What to do you think about it and has anyone started a "serious" 
> > calculus oriented subpackage for Numerical Python in general?
> > 
> > I mean: derivatives, partial derivatives, jacobian, hessian 
> > implemented fast and precise.
> > 
> > On another note, why isn't infinity defined in NumPy?
> > 
> > Why is tan(pi/2) a number even if big? Shouldn't it be infinity?
> > 
> >  
> > 
> 
> I tried your algoritm on sin(x) and i got some rather interesting
> results.
> 
> ######### EXAMPLE#############
> from math import sin
> 
> def f(x):
>     return sin(x)
> 
> import Derivative
> 
> print Derivative.Diff(f,0.0)
> 
> ########RESULT################
> -2.03844228853e-10
> 
> It should be approx 1.0 
> 
> 
> 
> I found the error i think..
> check row 28 in Derivative
>         h = random()/1e-10
> should that be h = random()/1e+10??
> 
> 
> Fredrik
> 

[Numpy-discussion] Derivative II

[Hassan A. <au...@cr...>]

 Forgot to attach file. Here it is

[Numpy-discussion] Derivatives

[Hassan A. <au...@cr...>]

Hi,

attached is a file called Derivative.py.

It computes derivatives and is based on an algorithm found in 
Numerical Recipes in C.

What to do you think about it and has anyone started a "serious" 
calculus oriented subpackage for Numerical Python in general?

I mean: derivatives, partial derivatives, jacobian, hessian 
implemented fast and precise.

On another note, why isn't infinity defined in NumPy?

Why is tan(pi/2) a number even if big? Shouldn't it be infinity?

 

[Numpy-discussion] Matrix.py problem

[JEFFERY C. <co...@ru...>]

I installed the Numpy 15.2 and got the following error during the
import of Matrix.  Apparently, the version number is no longer
embedded in the module doc string following the # sign.

>>> import Matrix
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/Numeric/Matrix.py", line 5, in ?
    __version__ = int(__id__[string.index(__id__, '#')+1:-1])
  File "/usr/local/lib/python1.5/string.py", line 138, in index
    return _apply(s.index, args)
ValueError: substring not found in string.index

Jeff

[Numpy-discussion] Casting problems with new version of NumPy.

[Travis O. <Oli...@ma...>]

The code sent by Herbert Roitblat pointed out some inconsistencies in the
current NumPy, that I've fixed with two small changes:

1) Long's can no longer be safely cast to Int's (this is not safe on
64-bit machines anyway) -- this makes Numeric more consistent with how it
interprets Python integers.

2) Automatic casting will be done when using rank-0 arrays to set elements
of a Numeric array to be consistent with the behavior for Python scalars.

The changes are in CVS right now, but are simple to change back if there
is a problem.

-Travis

[Numpy-discussion] Array-casting problem.

[Travis O. <Oli...@ma...>]

Hi Herb,

It has taken awhile for me to respond to this, but your problem's here
illustrate exactly the kinds of difficulties one encounters with the
current NumPy coercion rules:

You do not have a bad version of Numeric.  The behavior you describe is
exactly what "should" happen though it needs to be fixed.  I'll trace
for you exactly what is going on as it could be illustrative to others:

>>> a = zeros((5,5),'b')
# You've just created a 5x5 byte array that follows "normal" coercion
#   rules filled with zeros.

>>> a[3,3] = 8
# This line copies the rank-0 array of type 'b' created from the Python
#  Integer 8 (by a direct coercion in C) into element (3,3) of matrix a

>>> temp = a[3,3]
# This selects out the rank-0 array of typecode 'b' at position (3,3).  As
# of 15.2 this is nolonger changed to a scalar.  Note that rank-0 arrays
# act alot like scalars, but because there is not a one-to-one
# correspondence between the Python Scalars and rank-0 arrays, this is not
# automatically converted to a Python scalar (this is a change in 15.2)

>>> temp = temp + 3
# This is the problem line for you right here.  Something is wrong though,
# since it should not be, a problem.
# You are adding a rank-0 array of typecode 'b' to a Python Integer which 
# is interpreted by Numeric as a rank-0 array of typecode 'l'.  The result
# should be a Python Integer.  For some reason this is returning an array 
# of typecode 'i' (which does not get automatically converted to a Python
# scalar).

>>> a[3,3] = temp
# This would work fine if temp were the Python scalar it should be. 
# Right now, assignment doesn't let you assign an array of a "larger" type 
# to elements of a smaller type (except for Python scalars).  Since temp
# is (incorrectly I think) a type 'i' rank-0 array, it does not let you 
# make the assignment.  At any rate it is inconsistent to let you assign
# Python scalars but not rank-0 arrays of arbitrary precision, this should
# be fixed.  It is also a problem that temp + 3 returns an array of
# typecode 'i'.

I will look into fixing the above problems this example points out.  Of 
course, it could also be fixed by having long integers lower in the
coercion tree than byte arrays.

Thanks for the feedback,

Travis Oliphant

[Numpy-discussion] Re: [Matrix-SIG] Numeric Array: adding a 0-D array to a cell in a 2-D array

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

> We get the type error from trying to set the matrix element with a matrix
> element (apparently).  In the old version (1.9) on our NT box,
> temp=a[kwd,kwd] results in temp being an int type.  How can we either cast
> the temp to an int or enable what we really want, which is to add an int to
> a[kwd,kwd], as in a[kwd,kwd] = a[kwd,kwd] + jwd ?
> 
> Do we have a bad version of Numeric?

Maybe an experimental version. If you check the archives of this
mailing list, you can find a recent discussion about proposed
modifications. One of them was to eliminate the automatic conversion
of rank-0 arrays to scalars, in order to prevent type promotion.
Perhaps this proposal was implemented in the version you have.


Note to the NumPy maintainers: please announce all new releases on
this list, mentioning changes, especially those that affect backward
compatibility. As a maintainer of code that makes heavy use of NumPy,
I keep getting questions and bug reports caused by some new NumPy
release that I haven't even heard of. A recent example is the change
of location of the header files; C modules using arrays now have to
include Numeric/arrayobject.h instead of simply arrayobject.h. I can
understand this change (although I am not sure it's important enough
to break compatibility), but I'd have preferred to learn about it
directly and as early as possible. It's really no fun working through
a 2 KB bug report sent by someone with zero knowledge of C.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
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
-------------------------------------------------------------------------------

[Numpy-discussion] Re: [PSA MEMBERS] Numeric Python under IRIX646

[Mitch C. <mit...@mc...>]

On Sat, 19 Feb 2000, Michel Sanner wrote:
> Hi There,
> 
> I just tried to add SGI running IRIX6.5 to the collection of Unix boxes I will
> support and I ran into the following problem:
> 
> If I compile Python -O2 loading the Numeric extensions dumps the core,
> if I compile Python -g it works just fine and this regardless if Numeric is
> compile -g or -O2.
> 
> After I re-compiled Objects/complexobject.o using -g (everything else being
> compiled -O2) I got it to work ...
> 
> did anyone else out there see this kind of behavior ?


I saw exactly this behavior just last Friday afternoon.
After all of Python was recompiled with -g the bus error went away.

Thanks for pointing out that only complexobject needs to be compiled
with -g.  It didn't occur to me to try this, despite the location of
the bus error, because it was possible to exercise complex objects
interactively w. no problems.

BTW I don't know whether you were compiling N32 or N64.  In our
case N32 created the bus error.

-- 
Mitch Chapman
mit...@mc...

[Numpy-discussion] Numeric Python under IRIX646

[Michel S. <sa...@sc...>]

Hi There,

I just tried to add SGI running IRIX6.5 to the collection of Unix boxes I will
support and I ran into the following problem:

If I compile Python -O2 loading the Numeric extensions dumps the core,
if I compile Python -g it works just fine and this regardless if Numeric is
compile -g or -O2.

After I re-compiled Objects/complexobject.o using -g (everything else being
compiled -O2) I got it to work ...

did anyone else out there see this kind of behavior ?

I also post this to psa-members just in case this might be Python related


-Michel


-- 

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

>>>>>>>>>> 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
sa...@sc...                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------

Re: [Numpy-discussion] numpy documentation - alternative format?

[Peter C. <pe...@ee...>]

On Fri, 18 Feb 2000, Herbert L. Roitblat wrote:

> Adobe Acrobat has a shrink to fit option in their print menu.  I'm not sure
> if it comes with their free-reader.

Is it available for Linux? I'll check it out...

> Try printing as a 1up.  It seems a small adaptation.

I'm trying to save dead trees, i.e. print out 40 odd pages instead of 90
odd.

Peter

Re: [Numpy-discussion] numpy documentation - alternative format?

[Herbert L. R. <roi...@ha...>]

Adobe Acrobat has a shrink to fit option in their print menu.  I'm not sure
if it comes with their free-reader.
Try printing as a 1up.  It seems a small adaptation.
HLR
-----Original Message-----
From: Peter Chang <pe...@ee...>
To: Num...@li...
<Num...@li...>
Date: Friday, February 18, 2000 7:09 AM
Subject: [Numpy-discussion] numpy documentation - alternative format?


>
>Hi there,
>
>I've just started to use python and numpy and want to print out the numpy
>document but the PDF file has a strange aspect ratio which makes it hard
>to print it as 2up on A4 paper. (I've tried hacking about with the
>postscript generated by xpdf but it seems that there is no global setting
>for page size!)
>
>Could the authors please provide alternative formats for the doc, eg.
>as postscript files sized for A4 and letter so that people can print them
>out easier?
>
>Thanks
> Peter
>
>
>
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
>

[Numpy-discussion] numpy documentation - alternative format?

[Peter C. <pe...@ee...>]

Hi there,

I've just started to use python and numpy and want to print out the numpy
document but the PDF file has a strange aspect ratio which makes it hard
to print it as 2up on A4 paper. (I've tried hacking about with the
postscript generated by xpdf but it seems that there is no global setting
for page size!)

Could the authors please provide alternative formats for the doc, eg.
as postscript files sized for A4 and letter so that people can print them
out easier?

Thanks
 Peter

Re: [Numpy-discussion] more speed?

[Syrus Nemat-N. <sy...@lo...>]

On Thu, 17 Feb 2000, andrew x swan wrote:

> is this because the element by element
> calculations involved are contained in python for
> loops?

Hi Andrew!

I've only just begun using Numeric Python, but I'm a long-time user of GNU
Octave and a sporadic user of MatLab. In general, for loops kill the
execution speed of interpretive environments like Numpy and Octave. 

The high-speed comes when one uses vector operations such as Matrix
multiplication.

If you can vectorize your code, meaning replace all the loops with matrix
operations, you should see equivalent speed to Fortran for large data
sets. As far as I know, you will never see an interpreted language match a
compiled one in the execution of for loops.

Thanks. Syrus.

-- 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Syrus Nemat-Nasser <sy...@uc...>    UCSD Physics Dept.

Re: [Numpy-discussion] more speed?

[David A. <da...@sk...>]

From: andrew x swan <arc...@db...>

> python took this long:
> 
> 362.25user 0.74system 6:09.78elapsed 98%CPU 
> 
> and fortran took this long:
> 
> 2.68user 1.12system 0:03.89elapsed 97%CPU
> 
> is this because the element by element
> calculations involved are contained in python for
> loops?

yes.

--david ascher

[Numpy-discussion] more speed?

[andrew x s. <arc...@db...>]

This message was sent from Geocrawler.com by "andrew x swan" <a....@an...>
Be sure to reply to that address.

hi - i've only just started using python and
numpy... the program i wrote below runs much more
slowly than a fortran equivalent. ie. on a dataset
where the order of the matrix is (3325,3325),
python took this long:

362.25user 0.74system 6:09.78elapsed 98%CPU 

and fortran took this long:

2.68user 1.12system 0:03.89elapsed 97%CPU

is this because the element by element
calculations involved are contained in python for
loops?

thanks

#!/usr/bin/python

from Numeric import *

def nrm(pedigree):

    n_animals = len(pedigree) + 1
    
    nrm = zeros((n_animals,n_animals),Float)

    for i in xrange(1,n_animals):
        isire = pedigree[i-1][1]
        idam = pedigree[i-1][2]
        nrm[i,i] = 1.0 + 0.5 * nrm[isire,idam]
        for j in xrange(i+1,n_animals):
            jsire = pedigree[j-1][1]
            jdam = pedigree[j-1][2]
            nrm[j,i] = 0.5 * (nrm[jsire,i] +
nrm[jdam,i])
            nrm[i,j] = nrm[j,i]

    return nrm

if __name__ == '__main__':

    test_ped = [(1,0,0),(2,0,0),(3,1,0),(4,1,2),
                (5,3,4),(6,1,4),(7,5,6)]

    a = nrm(test_ped)
    print a
    


Geocrawler.com - The Knowledge Archive

[Numpy-discussion] re: scientific Python publishing venue

[<gvw...@ne...>]

Hi, folks. A former colleague of mine is now editing a magazine devoted to
scientific computing, and is looking for articles.  If you're doing
something scientific with Python, and want to tell the world about it,
please give me a shout, and I'll forward more information.

Greg Wilson
http://www.software-carpentry.com

[Numpy-discussion] Binary distribution available

[David A. <da...@sk...>]

With Travis' wise advice, I appear to have succeeded in putting forth a
binary installation of Numerical-15.2.

Due to a bug in distutils, this is an 'install in place' package, instead of
a 'run python setup.py install' package. So, unzip the file in your main
Python tree, and it should 'work'. Let me (and Paul and Travis) know if it
doesn't.

Download is available from the main page
(http://sourceforge.net/project/?group_id=1369 look for [zip]) or from
http://download.sourceforge.net/numpy/python-numpy-15.2.zip

--david ascher

Re: [Numpy-discussion] Re: [Matrix-SIG] An Experiment in code-cleanup.

[David A. <da...@sk...>]

> it as an example for people who want to learn stuff about mmap. As it
> stands, there was some similar code I was able to produce at some point. I
> forget who here has a copy, maybe Konrad, maybe David Ascher.
>
> Later,
> Andrew Mullhaupt

I did have some of that code, but it was almost 3 years ago and five
computers ago.  In other words, it's *somewhere*.  I'll start a grep, but
don't hold your breath...

--da

[Numpy-discussion] Re: [Matrix-SIG] An Experiment in code-cleanup.

[skaller <sk...@ma...>]

Konrad Hinsen wrote:
> 
> > silently). Consider a function
> >
> >       k0 = 100
> >       k = 99
> >       while k < k0:
> >               ..
> >               k0 = k
> >               k = ...
> >
> > which refines a calculation until the measure k stops decreasing.
> > This algorithm may terminate when k is a float, but _fail_ when
> > k is a double  -- the extra precision may cause the algorithm
> 
> I'd call this a buggy implementation. Convergence criteria should be
> explicit and not rely on the internal representation of data
> types. 

> If you care at all about portability, you shouldn't even think about
> this.

	But sometimes you DON'T care about portability.
Sometimes, you want the best result the architecture can support,
and so you need to perform a portable computation of an architecture
dependent value.

-- 
John (Max) Skaller, mailto:sk...@ma...
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller

Re: [Numpy-discussion] digest

[David A. <da...@sk...>]

> just switched over from matrix-sig to numpy-discussion. in the process
> i changed to the digest version and got my first issue.
>
> is it possible to distribute the digests properly formatted as
> multipart/digests as per rfc822 and company?

Did you try to edit your configuration on the mailman control panel?  There
is a choice between MIME and plain-text digests.

--david ascher

[Numpy-discussion] Re: [Matrix-SIG] An Experiment in code-cleanup.

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

> > onto my FTP server if there is a need.
> 
> Yes, I'd like to get a copy! You can simply e-mail it to me, if you'd
> prefer.

OK, coming soon...

> I'll have to look at this more carefully. Due to my relative lack of Python
> experience, I hacked the C code so that Fortran routines could be called
> instead, producing the expected results.

That's fine, you can simply replace the f2c-generated code by
Fortran-compiled code, as long as the calling conventions are the
same. I have used optimized BLAS as well on some machines.

> Where? Even in the latest f2c'd source code that I downloaded from
> SourceForge, I see all names written using the
> lower-case-trailing-underscore convention (e.g., dgeqrf_). The Intel MKL was

Sure, f2c generates the underscores. But the LAPACK interface code
(the one I'll send you, and also LAPACK Lite) supports both
conventions, controlled by the preprocessor symbol NO_APPEND_FORTRAN
(maybe not the most obvious name). On the other hand, there is
no support for uppercase names; that convention is not used in the
Unix world. But I suppose it could be added by machine transformation
of the code.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
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
-------------------------------------------------------------------------------

[Numpy-discussion] digest

[Les S. <god...@ne...>]

just switched over from matrix-sig to numpy-discussion. in the process 
i changed to the digest version and got my first issue.

is it possible to distribute the digests properly formatted as
multipart/digests as per rfc822 and company?

having such a formatted digest makes it very easy when using an
emailer like VM in emacs: VM automatically displays the digest as a
virtual folder, allowing one to browse all the posts in a given digest
very quickly and easily. don't know whether the other (lacklusters)
emailers out there will handle it so nicely, but i don't think the
extra required markers will interfere with your reading of the digests
at all.

highly recommended. i'd be glad to work with whoever has control over
this to ensure that the proper markers get placed into the digests.

les schaffer