headers
Leila baghdadi | 1 Mar 2005 23:30
Picon

help building scipy on Opteron 64 bit

Hello everyone,

I am new to this so bear with me!

I have been trying to build scipy on our Opteron machine (linux
enterprise 3, gcc 3.2.3) and had no success,

I searched the mailing list and found the link about optimization and
gcc version
http://www.scipy.net/pipermail/scipy-user/2004-November/003815.html

and decided to only build blas and lapack and see if I can get the
correct answer for the example that is given in the above link

I tried  with gcc 3.2.3 and no optimization and had no luck

I then build a local copy of gcc 3.4.3 and tried with/without
optimization and still have no luck 

my answers are

wr=9.32183,-9.59852e-16,-0.321825,wi=0,0,0

whereas the above link gives 
wr=9.32183,-6.20979e-16,-0.321825,wi=0,0,0

at this point I am unable to proceed simply because I have no idea what
to do, according to the above link gcc 3.4.3 should solve the problem
but I am not sure why it does not do it in my case.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Swan | 2 Mar 2005 11:20
Picon

sparse matrix multiplication

Hi - I am wondering if there is a problem with the following code:

from scipy_base import *
from scipy.sparse import csc_matrix, dok_matrix
x = dok_matrix()
x[0,0] = 2
x[1,1] = 1
x[2,1] = 1
y = csc_matrix(x)
yt = y.transp()
yy = yt * y
print yy.todense()

The print statement gives:

[[ 4.  0.]
 [ 2.  0.]]

When the answer I was expecting was:

array([[4, 0],
       [0, 2]])

Thanks in advance...
---- Msg sent via - People Telecom Webmail
Permalink | Reply | 0 comments |
headers
Duncan Child | 3 Mar 2005 00:18

Performance question.

I am working on developing algorithms that are usually called with 
parameters that are Numeric arrays.  We have the usual challenge though 
of trying to craft code that will gracefully accept both floats or 
arrays. Because of the often discussed problem with the handling of zero 
length arrays we expend some effort to ensure that we don't make calls 
on floats that only work on arrays and have ended up with a bunch of 
code like safe_len() that can be called with either.

Today we have a related problem but now it is with performance (see code 
below). Numeric is faster than NumArray operating on smaller arrays but 
it is still relatively slow handling regular floats. We could add to the 
safe_ suite of functions the fast_ series but this still entails a 
significant performance hit and is not exactly elegant.

The problem is larger than just handling sqrt so I would appreciate any 
feedback or suggestions on how best to proceed.

Thanks,

Duncan

=================================================
def safe_len(a):
    # Return the length of the input array or 1 if it is a scalar
    try:
        safelen = len(a)
    except:
        safelen = 1
    return safelen
=================================================
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Kern | 3 Mar 2005 01:33
Favicon

Re: Performance question.

Duncan Child wrote:
> I am working on developing algorithms that are usually called with 
> parameters that are Numeric arrays.  We have the usual challenge though 
> of trying to craft code that will gracefully accept both floats or 
> arrays. Because of the often discussed problem with the handling of zero 
> length arrays we expend some effort to ensure that we don't make calls 
> on floats that only work on arrays and have ended up with a bunch of 
> code like safe_len() that can be called with either.
> 
> Today we have a related problem but now it is with performance (see code 
> below). Numeric is faster than NumArray operating on smaller arrays but 
> it is still relatively slow handling regular floats. We could add to the 
> safe_ suite of functions the fast_ series but this still entails a 
> significant performance hit and is not exactly elegant.

A potential solution to the performance problem, though not the elegance 
problem, might be Pyrex.

An untested sketch:

cdef extern from "Numeric/arrayobject.h":
     bool PyArray_Check(object x)

cdef extern from "math.h":
     double sqrt(double x)

import Numeric

def fast_sqrt(object x):
     if PyArray_Check(x):
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pearu Peterson | 3 Mar 2005 09:48
Favicon

Re: help building scipy on Opteron 64 bit


On Tue, 1 Mar 2005, Leila baghdadi wrote:

> Hello everyone,
>
> I am new to this so bear with me!
>
> I have been trying to build scipy on our Opteron machine (linux
> enterprise 3, gcc 3.2.3) and had no success,
>
> I searched the mailing list and found the link about optimization and
> gcc version
> http://www.scipy.net/pipermail/scipy-user/2004-November/003815.html
>
> and decided to only build blas and lapack and see if I can get the
> correct answer for the example that is given in the above link
>
> I tried  with gcc 3.2.3 and no optimization and had no luck
>
> I then build a local copy of gcc 3.4.3 and tried with/without
> optimization and still have no luck
>
> my answers are
>
> wr=9.32183,-9.59852e-16,-0.321825,wi=0,0,0
>
> whereas the above link gives
> wr=9.32183,-6.20979e-16,-0.321825,wi=0,0,0

I don't see what is the problem here, the results are equal up-to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Walton | 4 Mar 2005 01:58
Favicon

bdist-rpm problem

Hi, All,

A week or so ago, I posted to matplotlib-users about a problem with 
bdist_rpm.  I'd asked about python 2.3 on Fedora Core 1.

It turns out there are two problems.  One is that even if one has 
python2.3 and python2.2 installed, bdist_rpm always calls the 
interpreter named 'python', which is 2.2 on FC1.  The other problem is 
that in bdist_rpm.py there is a set of lines near line 307 which tests 
if the number of generated RPM files is 1.  This fails because all of 
matplotlib, numeric, numarray and scipy generate a debuginfo RPM when 
one does 'python setup.py bdist_rpm'.  (Why the RPM count doesn't fail 
with Python 2.3 on FC3 is beyond me, but nevermind.)  The patch is at

http://opensvn.csie.org/pyvault/rpms/trunk/python23/python-2.3.4-distutils-bdist-rpm.patch

and I have verified that after applying this patch to 
/usr/lib/python2.2/distutils/command/bdist_rpm.py on FC1 that 'python 
setup.py bdist_rpm' works for numarray 1.2.2, scipy current CVS, and 
matplotlib 0.72 (after changing setup.py for python2.2 as documented in 
the latter).  It still fails with Numeric 23.6 however for reasons I'm 
still checking into;  the failed "setup.py bdist_rpm" claims that 
arraytypes.c doesn't exist.

Steve Walton
Permalink | Reply | 0 comments |
headers
Stephen Walton | 4 Mar 2005 02:01
Favicon

Re: bdist-rpm problem

Stephen Walton wrote:

> [bdist_rpm] still fails with Numeric 23.6 however for reasons I'm 
> still checking into;

Posted too soon;  this problem is fixed at Numeric 23.7.
Permalink | Reply | 0 comments |
headers
Pearu Peterson | 4 Mar 2005 02:04
Favicon

Re: bdist-rpm problem


On Thu, 3 Mar 2005, Stephen Walton wrote:

> Hi, All,
>
> A week or so ago, I posted to matplotlib-users about a problem with 
> bdist_rpm.  I'd asked about python 2.3 on Fedora Core 1.
>
> It turns out there are two problems.  One is that even if one has python2.3 
> and python2.2 installed, bdist_rpm always calls the interpreter named 
> 'python', which is 2.2 on FC1.

Using `bdist_rpm --fix-python` should take care of this issue.

Pearu
Permalink | Reply | 0 comments |
headers
Fernando Perez | 4 Mar 2005 02:22
Picon
Favicon

Re: bdist-rpm problem

Stephen Walton wrote:
> Hi, All,
> 
> A week or so ago, I posted to matplotlib-users about a problem with 
> bdist_rpm.  I'd asked about python 2.3 on Fedora Core 1.
> 
> It turns out there are two problems.  One is that even if one has 
> python2.3 and python2.2 installed, bdist_rpm always calls the 
> interpreter named 'python', which is 2.2 on FC1.  The other problem is 

You need to 'fix' the python version to be called inside the actual rpm build. 
  From the ipython release script:

# A 2.4-specific RPM, where we must use the --fix-python option to ensure that
# the resulting RPM is really built with 2.4 (so things go to
# lib/python2.4/...)
python2.4 ./setup.py bdist_rpm --release=py24 --fix-python

> that in bdist_rpm.py there is a set of lines near line 307 which tests 
> if the number of generated RPM files is 1.  This fails because all of 
> matplotlib, numeric, numarray and scipy generate a debuginfo RPM when 
> one does 'python setup.py bdist_rpm'.  (Why the RPM count doesn't fail 
> with Python 2.3 on FC3 is beyond me, but nevermind.)  The patch is at

This problem has been fixed in recent 2.3 and 2.4.  2.2 still has it.

Best,

f
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Novak | 4 Mar 2005 07:15
Favicon

Re: Numeric Documentation

On a whim I searched http://www.archive.org for the PDF documentation
of Numpy, and lo! they had it.  I didn't think they archived binary
files, but I was mistaken...

I've posted it at http://www.ucolick.org/~novak/numpy.pdf. It'd be
great if someone could snatch it from there and post it to the scipy
web site so that it doesn't perish from the world...

Thanks!
Greg
Permalink | Reply | 501 comments |

Gmane