From bazell at comcast.net  Wed Dec  4 14:45:45 2002
From: bazell at comcast.net (Dave Bazell)
Date: Wed, 04 Dec 2002 14:45:45 -0500
Subject: [SciPy-user] SciPy setup problem under RH 7.3
Message-ID: <001e01c29bcd$bcbed860$6401a8c0@DB>

I just tried installing scipy on my redhat 7.3 system.  I installed the fftw package and the numpy (numeric22) package and then the scipy package.  When I start python and try to access scipy to run the test module I get some errors and the tests don't run.  Perhaps someone can seem my error and enlighten me.  I have included printout to detail the problems


Python 2.2.2 (#1, Oct 21 2002, 12:22:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help()

Welcome to Python 2.2!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://www.python.org/doc/tut/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> Help on module numeric_version:

NAME
    numeric_version

FILE
    /usr/local/lib/python2.2/site-packages/Numeric/numeric_version.py

DATA
    __file__ = '/usr/local/lib/python2.2/site-packages/Numeric/numeric_ver...
    __name__ = 'numeric_version'
    version = '22.0'


help> 
You are now leaving help and returning to the Python interpreter.
If you want to ask for help on a particular object directly from the
interpreter, you can type "help(object)".  Executing "help('string')"
has the same effect as typing a particular string at the help> prompt.
>>> 
>>> import scipy
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 41, in ?
    from handy import *
  File "/usr/local/lib/python2.2/site-packages/scipy/handy.py", line 1, in ?
    import Numeric
  File "/usr/local/lib/python2.2/site-packages/Numeric/Numeric.py", line 93, in ?
    from Precision import *
  File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 26, in ?
    _code_table = _fill_table(typecodes)
  File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 23, in _fill_table
    table[key] = _get_precisions(value)
  File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 18, in _get_precisions
    lst.append( (zeros( (1,), t ).itemsize()*8, t) )
ValueError: Invalid type for array
>>> 
>>> import scipy
>>> 
>>> scipy.test()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'test'
>>> 
>>> 

Any help would be appreciated.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20021204/f99791b7/attachment.html>

From pearu at cens.ioc.ee  Wed Dec  4 15:36:30 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 4 Dec 2002 22:36:30 +0200 (EET)
Subject: [SciPy-user] SciPy setup problem under RH 7.3
In-Reply-To: <001e01c29bcd$bcbed860$6401a8c0@DB>
Message-ID: <Pine.LNX.4.21.0212042231090.25325-100000@cens.kybi>

On Wed, 4 Dec 2002, Dave Bazell wrote:

> I just tried installing scipy on my redhat 7.3 system.  I installed
> the fftw package and the numpy (numeric22) package and then the scipy
> package.  When I start python and try to access scipy to run the test
> module I get some errors and the tests don't run.  Perhaps someone can
> seem my error and enlighten me.  I have included printout to detail
> the problems
> 
> You are now leaving help and returning to the Python interpreter.
> If you want to ask for help on a particular object directly from the
> interpreter, you can type "help(object)".  Executing "help('string')"
> has the same effect as typing a particular string at the help> prompt.
> >>> 
> >>> import scipy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 41, in ?
>     from handy import *
>   File "/usr/local/lib/python2.2/site-packages/scipy/handy.py", line 1, in ?
>     import Numeric
>   File "/usr/local/lib/python2.2/site-packages/Numeric/Numeric.py", line 93, in ?
>     from Precision import *
>   File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 26, in ?
>     _code_table = _fill_table(typecodes)
>   File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 23, in _fill_table
>     table[key] = _get_precisions(value)
>   File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line 18, in _get_precisions
>     lst.append( (zeros( (1,), t ).itemsize()*8, t) )
> ValueError: Invalid type for array

This is just a wild guess: did you have some older version of Numeric
installed before? If yes, could you check that Numeric install acctually
copied the latest version of arrayobject.h to
/usr/local/include/python2.2/Numeric?

Pearu

PS: Please turn off html when sending messages to this list.



From s.mogck at phys.rug.nl  Thu Dec  5 03:37:38 2002
From: s.mogck at phys.rug.nl (Stefan Mogck)
Date: Thu, 5 Dec 2002 09:37:38 +0100
Subject: [SciPy-user] Possibly bug in signal.module mean function
Message-ID: <200212050827.JAA05227@dep.phys.rug.nl>

Hi scipy-user,

I'd like to use the wienfilter for filtering my images. I tried again first 
an example from the manual:

stefan at mk39:~> python
Python 2.2.2 (#1, Nov 28 2002, 09:15:11) 
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gui_thread
>>> <Importing wxPython...  done.>
>>> from scipy import *
>>> from scipy import plt
>>> from Numeric import *
>>> from RandomArray import normal
>>> img=plt.lena()
>>> plt.image(img)
<type 'array'> ['__copy__', '__deepcopy__', 'astype', 'byteswapped', 'copy', 
'iscontiguous', 'itemsize', 'resize', 'savespace', 'spacesaver', 'tolist', 
'toscalar', 'tostring', 'typecode']
<C wxFrame instance at _41200618_wxFrame_p>
>>> noisy_img=img+normal(0,32,shape(img))
>>> plt.figure()
<C wxFrame instance at _886a420_wxFrame_p>
>>> plt.image(noisy_img)
<type 'array'> ['__copy__', '__deepcopy__', 'astype', 'byteswapped', 'copy', 
'iscontiguous', 'itemsize', 'resize', 'savespace', 'spacesaver', 'tolist', 
'toscalar', 'tostring', 'typecode']
<C wxFrame instance at _886a420_wxFrame_p>
>>> cleaned_img=signal.wiener(noisy_img)        
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/scipy/signal/signaltools.py", 
line 223, in wiener
    noise = Numeric.mean(Numeric.ravel(lVar))
AttributeError: 'module' object has no attribute 'mean'


I am using SciPy -0.2.0_alpha_144.4350 and Numeric-22.0 under pythojn 2.2.2. 
Have anyvbody an idea about this problem. I want to understand this problem

Stefan


From s.mogck at phys.rug.nl  Thu Dec  5 04:17:16 2002
From: s.mogck at phys.rug.nl (Stefan Mogck)
Date: Thu, 5 Dec 2002 10:17:16 +0100
Subject: [SciPy-user] Bug in signaltools.py in Scipy-0.2
Message-ID: <200212050906.KAA07687@dep.phys.rug.nl>

I just posted a possibly bug in the signal module. mean 
function. What I found that the function 'mean' is not 
defined directly in Numerical. Therefore I added in 
signaltools.py: import MLab and changed also line 223:
 
noise = Numeric.mean(Numeric.ravel(lVar)) to

noise = MLab.mean(Numeric.ravel(lVar))

The same in line 231 and 232:

    im = Numeric.maximum(im,0)
    lVar = Numeric.maximum(lVar,noise)

to   im =  MLab.maximum(im,0)
    lVar = MLab.maximum(lVar,noise)

After this changes the wiener filter is working. See 
example under:
 
http://www.scipy.org/site_content/screen_shots

May be this is not the best solution, but it helps

Stefan Mogck





From aureli at ipk.fhg.de  Thu Dec  5 06:03:45 2002
From: aureli at ipk.fhg.de (Aureli Soria Frisch)
Date: Thu, 5 Dec 2002 12:03:45 +0100
Subject: [SciPy-user] Bug in signaltools.py in Scipy-0.2
In-Reply-To: <200212050906.KAA07687@dep.phys.rug.nl>
References: <200212050906.KAA07687@dep.phys.rug.nl>
Message-ID: <a05111b00ba14e19a3154@[153.97.92.109]>

Hi,

>
>noise = Numeric.mean(Numeric.ravel(lVar)) to

The mean function is called average in Numeric (I suppose they return 
the same)...

noise=Numeric.average(Numeric.ravel(lVar))

>
>     im = Numeric.maximum(im,0)
>     lVar = Numeric.maximum(lVar,noise)



I think maybe in this case the Numeric.ravel function is missing:
im=Numeric.maximum(Numeric.ravel(im),0)
LVar = Numeric.maximum(Numeric.ravel(lVar),noise)

But it should be tested...and if it works you could avoid importing MLab...

Regards,
Aureli
-- 
#################################
Aureli Soria Frisch
Fraunhofer IPK
Dept. Pattern Recognition

post: Pascalstr. 8-9, 10587 Berlin, Germany
e-mail: aureli at ipk.fhg.de
fon: +49 30 39006-143
fax: +49 30 3917517
web: http://vision.fhg.de/~aureli/web-aureli_en.html
#################################


From s.mogck at phys.rug.nl  Thu Dec  5 09:16:39 2002
From: s.mogck at phys.rug.nl (Stefan Mogck)
Date: Thu, 5 Dec 2002 15:16:39 +0100
Subject: [SciPy-user] Importing foreign images
Message-ID: <200212051406.PAA28503@dep.phys.rug.nl>

Hallo Scipy-user,

How can I import e.g.  *.tiff and *.jpg files for image processing?
I think, I can do it also with python

Stefan


From aureli at ipk.fhg.de  Thu Dec  5 09:25:46 2002
From: aureli at ipk.fhg.de (Aureli Soria Frisch)
Date: Thu, 5 Dec 2002 15:25:46 +0100
Subject: [SciPy-user] Importing foreign images
In-Reply-To: <200212051406.PAA28503@dep.phys.rug.nl>
References: <200212051406.PAA28503@dep.phys.rug.nl>
Message-ID: <a05111b01ba15118e7581@[153.97.92.109]>

Hi,

>How can I import e.g.  *.tiff and *.jpg files for image processing?
>I think, I can do it also with python

One can use PIL (Python Image Library) for opening the images and 
then transforming the images to Numeric arrays. For that purpose you 
can use following functions:

##########################################################
##dataConversion.py
##functions for data conversion between Numeric and PIL
#
import Numeric
import Image
from ArrayPrinter import array2string

#conversion image object (PIL) to narray object (Numeric)
#outputDim: rank of output array
def image2array(im,outputDim=3):
     if im.mode=="1":
	a=Numeric.fromstring(im.tostring(),Numeric.UnsignedInt8) 
#mystery why is needed
	im.mode="L"
	a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8)
	a = a > 0
	bands=1
     elif im.mode == "L":
         a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8)
	bands=1
     elif im.mode == "F":
         a = Numeric.fromstring(im.tostring(), Numeric.Float32)
	bands=1
     elif (im.mode=='RGB')|(im.mode=='YCbCr'):
	a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8)
	bands=3
     elif (im.mode=='RGBA')|(im.mode=='CMYK'):
	a = Numeric.fromstring(im.tostring(), Numeric.UnsignedInt8)
	bands=4
     else:
	 raise ValueError, im.mode+" mode not considered"
     #print "array u to now"
     #print a
     if outputDim==3:
	    a.shape=(im.size[1],im.size[0],bands)
     elif outputDim==2:
	    a=Numeric.reshape(a,(im.size[1],im.size[0]))
     elif outputDim==1:
	    a=Numeric.reshape(a,(im.size[1]*im.size[0],))
     #print "shape change"
     #print a
     return a

    
#autoescaling function for representation with UnsignedInt8
def _imagesc(mat):

	maxV=max(Numeric.ravel(mat))
	minV=min(Numeric.ravel(mat))
	if maxV<>minV:
		return 
(255*(mat-minV)/(maxV-minV)).astype(Numeric.UnsignedInt8)

#conversion array object (Numeric) to image object (PIL)
#scale=1: autoscales image, each chanel independently
#scale=2: autoscales image, with max value of all channels
#scale=0: do not autoscale
def array2image(a,scale=1):
     #print a.shape
     if len(a.shape)==3:
	b=()
	if scale==2:
		a=_imagesc(a)
	for i in range(a.shape[2]):
		#print a[:,:,i].shape

		if scale==1:
			a[:,:,i]=_imagesc(a[:,:,i])
		b+=(array2image(a[:,:,i]),)
	#print b[0].size
	if a.shape[2]==3:
		#print "here shape 3",b
		#return b
		return Image.merge("RGB",b)
	elif a.shape[2]==1:
		#print "here shape 1",b
		return b[0]
     elif len(a.shape)==2:
	    print "autoescaling image"
	    a=_imagesc(a)
	    mode ="L"
     elif a.typecode() == Numeric.UnsignedInt8:
         mode = "L"
     elif a.typecode() == Numeric.Float32:
         mode = "F"
     else:
         raise ValueError, "unsupported image mode"
     return Image.fromstring(mode, (a.shape[1], a.shape[0]), 
a.astype(a.typecode()).tostring())

-- 
#################################
Aureli Soria Frisch
Fraunhofer IPK
Dept. Pattern Recognition

post: Pascalstr. 8-9, 10587 Berlin, Germany
e-mail: aureli at ipk.fhg.de
fon: +49 30 39006-143
fax: +49 30 3917517
web: http://vision.fhg.de/~aureli/web-aureli_en.html
#################################


From oliphant at ee.byu.edu  Thu Dec  5 12:57:27 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 5 Dec 2002 10:57:27 -0700 (MST)
Subject: [SciPy-user] Possibly bug in signal.module mean function
In-Reply-To: <200212050827.JAA05227@dep.phys.rug.nl>
Message-ID: <Pine.LNX.4.33L2.0212051056530.11151-100000@oliphant.ee.byu.edu>

> Hi scipy-user,
>
> I'd like to use the wienfilter for filtering my images. I tried again first
> an example from the manual:
>
> stefan at mk39:~> python
> Python 2.2.2 (#1, Nov 28 2002, 09:15:11)
> [GCC 2.95.3 20010315 (SuSE)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import gui_thread
> >>> <Importing wxPython...  done.>
> >>> from scipy import *
> >>> from scipy import plt
> >>> from Numeric import *
> >>> from RandomArray import normal
> >>> img=plt.lena()
> >>> plt.image(img)
> <type 'array'> ['__copy__', '__deepcopy__', 'astype', 'byteswapped', 'copy',
> 'iscontiguous', 'itemsize', 'resize', 'savespace', 'spacesaver', 'tolist',
> 'toscalar', 'tostring', 'typecode']
> <C wxFrame instance at _41200618_wxFrame_p>
> >>> noisy_img=img+normal(0,32,shape(img))
> >>> plt.figure()
> <C wxFrame instance at _886a420_wxFrame_p>
> >>> plt.image(noisy_img)
> <type 'array'> ['__copy__', '__deepcopy__', 'astype', 'byteswapped', 'copy',
> 'iscontiguous', 'itemsize', 'resize', 'savespace', 'spacesaver', 'tolist',
> 'toscalar', 'tostring', 'typecode']
> <C wxFrame instance at _886a420_wxFrame_p>
> >>> cleaned_img=signal.wiener(noisy_img)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.2/site-packages/scipy/signal/signaltools.py",
> line 223, in wiener
>     noise = Numeric.mean(Numeric.ravel(lVar))
> AttributeError: 'module' object has no attribute 'mean'
>

This is an error.  Please change Numeric.mean to scipy.mean in the
signaltools.py code.


-Travis O.




From oliphant at ee.byu.edu  Thu Dec  5 13:00:32 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 5 Dec 2002 11:00:32 -0700 (MST)
Subject: [SciPy-user] Importing foreign images
In-Reply-To: <200212051406.PAA28503@dep.phys.rug.nl>
Message-ID: <Pine.LNX.4.33L2.0212051058250.11151-100000@oliphant.ee.byu.edu>

> Hallo Scipy-user,
>
> How can I import e.g.  *.tiff and *.jpg files for image processing?
> I think, I can do it also with python

Download and install the PIL.

Then scipy can use it to read and write these files (scipy/pilutil.py)

Try

>>> from scipy import *
>>> arr = imread(myfile.jpg)

If this works then you have PIL installed.  If it doesn't work, you need
to install PIL.


-Travis O.





From oliphant at ee.byu.edu  Thu Dec  5 13:04:39 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 5 Dec 2002 11:04:39 -0700 (MST)
Subject: [SciPy-user] Importing foreign images
In-Reply-To: <a05111b01ba15118e7581@[153.97.92.109]>
Message-ID: <Pine.LNX.4.33L2.0212051100560.11151-100000@oliphant.ee.byu.edu>

>
> >How can I import e.g.  *.tiff and *.jpg files for image processing?
> >I think, I can do it also with python
>
> One can use PIL (Python Image Library) for opening the images and
> then transforming the images to Numeric arrays. For that purpose you
> can use following functions:

NOTE:  Similar functions are already in scipy.

The following functions all require the PIL:

fromimage  --- convert PIL Image to Numeric array
toimage    --- convert Numeric array to PIL Image
imsave     --- save Numeric array to image file
imread     --- read image file as Numeric array


Note that for scipy images are either 2-D (grayscale) or 2-D x 3 (RGB)
arrays.  If the image has a palette stored then this is handled as a
separate array object (fromimage returns both the array and the palette)

-Travis O.






From lep at aber.ac.uk  Fri Dec  6 10:19:40 2002
From: lep at aber.ac.uk (Leighton Pritchard)
Date: Fri, 06 Dec 2002 15:19:40 +0000
Subject: [SciPy-user] (long) Weave installation problems on Linux
Message-ID: <5.1.0.14.0.20021206150254.05e71dc0@pophost.aber.ac.uk>

Hi,

Apologies first for the length of the posting, and the irrelevance to 
anyone who's happily using Weave and/or SciPy without any difficulty, but 
I'm stuck and could do with some help.

I've been attempting to install SciPy and Weave under Mandrake 8.2, and I'm 
having all sorts of niggly problems. I'm most interested in getting Weave 
to work  well first, so I'll begin there.

I've managed to get Weave working after a fashion. The simple test code I 
throw at it works OK, but the test suite that comes with it throws a bundle 
of errors. I'd greatly appreciate any guidance you could give me as to 
where I've gone wrong in the installation, or anthing else I may have 
overlooked/messed up. Apologies if it's a really stupid error.

Information to aid with a diagnosis is below:


I'm using the tarball from 
http://www.scipy.org/site_content/weave/weave-0.2.3.tar.gz.

$ uname -a
Linux louse 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i686 unknown

$ gcc --v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.0.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share/gcc-3.0.4 --enable-shared 
--enable-threads=posix --disable-checking --enable-long-long 
--enable-cstdio=stdio --enable-clocale=generic 
--enable-languages=c,c++,f77,objc,java --program-suffix=-3.0.4 
--enable-objc-gc --host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)

The Python version (in usr/local/bin, /usr/local/lib etc. is:
Python 2.2.1 (#1, Aug  8 2002, 17:45:24)
[GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2

Numeric is v21.3

After untarring/gunzipping I enter the expanded directory and use the usual 
(and documented) python setup.py install. Everything appears to go smoothly.

 >>> import weave

shows no errors

 >>> weave.test()

shows a bucketload. Stdout is:

=================================================================================

  creating test suite for: weave.ast_tools
No test suite found for  weave.base_info
No test suite found for  weave.base_spec
No test suite found for  weave.blitz_info
No test suite found for  weave.blitz_spec
  creating test suite for: weave.blitz_tools
  creating test suite for: weave.build_tools
  creating test suite for: weave.catalog
No test suite found for  weave.code_blocks
No test suite found for  weave.common_info
  creating test suite for: weave.common_spec
No test suite found for  weave.conversion_code
No test suite found for  weave.conversion_code_old
No test suite found for  weave.cxx_info
No test suite found for  weave.dumbdbm_patched
No test suite found for  weave.dumb_shelve
  creating test suite for: weave.ext_tools
building extensions here: /home/lep/.python22_compiled/164260
building extensions here: /home/lep/.python22_compiled/164261
No test suite found for  weave.inline_info
  creating test suite for: weave.inline_tools
No test suite found for  weave.lib2def
No test suite found for  weave.misc
No test suite found for  weave.scalar_info
  creating test suite for: weave.scalar_spec
  creating test suite for: weave.sequence_spec
  creating test suite for: weave.size_check
  creating test suite for: weave.slice_handler
No test suite found for  weave.standard_array_info
  creating test suite for: weave.standard_array_spec
No test suite found for  weave.swig_info
No test suite found for  weave.wx_info
No test suite found for  weave.wx_spec

Expression: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]+ 
b[1:-1,2:] + b[1:-1,:-2]) / 5.
Run: (10, 10) f
warning: specified build_dir '_bad_path_' does not exist or is or is not 
writable. Trying default locations
warning: specified build_dir '..' does not exist or is or is not writable. 
Trying default locations
warning: specified build_dir '_bad_path_' does not exist or is or is not 
writable. Trying default locations
warning: specified build_dir '..' does not exist or is or is not writable. 
Trying default locations

test printing a value:2

=================================================================================

Stderr is:

=================================================================================

...In file included from 
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/numinquire.h:60,
                  from 
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/array/expr.h:63,
                  from 
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/array.h:2469,
                  from 
/home/lep/.python22_compiled/164262/sc_5599df30197fe981824ad8ec934a784e0.cpp:3:
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:30: 
multiple
    definition of `enum std::float_round_style'
/usr/include/g++-v3/bits/std_limits.h:866: previous definition here
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:31: 
conflicting
    types for `round_indeterminate'
/usr/include/g++-v3/bits/std_limits.h:867: previous declaration as
    `std::float_round_style round_indeterminate'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:32: 
conflicting
    types for `round_toward_zero'
/usr/include/g++-v3/bits/std_limits.h:868: previous declaration as
    `std::float_round_style round_toward_zero'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:33: 
conflicting
    types for `round_to_nearest'
/usr/include/g++-v3/bits/std_limits.h:869: previous declaration as
    `std::float_round_style round_to_nearest'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:34: 
conflicting
    types for `round_toward_infinity'
/usr/include/g++-v3/bits/std_limits.h:870: previous declaration as
    `std::float_round_style round_toward_infinity'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:36: 
conflicting
    types for `round_toward_neg_infinity'
/usr/include/g++-v3/bits/std_limits.h:872: previous declaration as
    `std::float_round_style round_toward_neg_infinity'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:38: 
multiple
    definition of `enum std::float_denorm_style'
/usr/include/g++-v3/bits/std_limits.h:875: previous definition here
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:39: 
conflicting
    types for `denorm_indeterminate'
/usr/include/g++-v3/bits/std_limits.h:876: previous declaration as
    `std::float_denorm_style denorm_indeterminate'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:40: 
conflicting
    types for `denorm_absent'
/usr/include/g++-v3/bits/std_limits.h:877: previous declaration as
    `std::float_denorm_style denorm_absent'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:42: 
conflicting
    types for `denorm_present'
/usr/include/g++-v3/bits/std_limits.h:879: previous declaration as
    `std::float_denorm_style denorm_present'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:258: 
redefinition
    of `struct std::numeric_limits<_Tp>'
/usr/include/g++-v3/bits/std_limits.h:886: previous definition of `struct
    std::numeric_limits<_Tp>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:267: 
redefinition
    of `class std::numeric_limits<bool>'
/usr/include/g++-v3/bits/std_limits.h:1020: previous definition of `class
    std::numeric_limits<bool>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:274: 
redefinition
    of `class std::numeric_limits<char>'
/usr/include/g++-v3/bits/std_limits.h:1077: previous definition of `class
    std::numeric_limits<char>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:279: 
redefinition
    of `class std::numeric_limits<signed char>'
/usr/include/g++-v3/bits/std_limits.h:1135: previous definition of `class
    std::numeric_limits<signed char>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:284: 
redefinition
    of `class std::numeric_limits<unsigned char>'
/usr/include/g++-v3/bits/std_limits.h:1191: previous definition of `class
    std::numeric_limits<unsigned char>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:298: 
redefinition
    of `class std::numeric_limits<short int>'
/usr/include/g++-v3/bits/std_limits.h:1303: previous definition of `class
    std::numeric_limits<short int>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:303: 
redefinition
    of `class std::numeric_limits<short unsigned int>'
/usr/include/g++-v3/bits/std_limits.h:1359: previous definition of `class
    std::numeric_limits<short unsigned int>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:308: 
redefinition
    of `class std::numeric_limits<int>'
/usr/include/g++-v3/bits/std_limits.h:1414: previous definition of `class
    std::numeric_limits<int>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:313: 
redefinition
    of `class std::numeric_limits<unsigned int>'
/usr/include/g++-v3/bits/std_limits.h:1470: previous definition of `class
    std::numeric_limits<unsigned int>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:318: 
redefinition
    of `class std::numeric_limits<long int>'
/usr/include/g++-v3/bits/std_limits.h:1525: previous definition of `class
    std::numeric_limits<long int>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:323: 
redefinition
    of `class std::numeric_limits<long unsigned int>'
/usr/include/g++-v3/bits/std_limits.h:1581: previous definition of `class
    std::numeric_limits<long unsigned int>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:360: 
redefinition
    of `class std::numeric_limits<float>'
/usr/include/g++-v3/bits/std_limits.h:1747: previous definition of `class
    std::numeric_limits<float>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:382: 
redefinition
    of `class std::numeric_limits<double>'
/usr/include/g++-v3/bits/std_limits.h:1823: previous definition of `class
    std::numeric_limits<double>'
/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/limits-hack.h:404: 
redefinition
    of `class std::numeric_limits<long double>'
/usr/include/g++-v3/bits/std_limits.h:1902: previous definition of `class
    std::numeric_limits<long double>'
/home/lep/.python22_compiled/164262/sc_5599df30197fe981824ad8ec934a784e0.cpp:550:1: 
warning: "convert_to_numpy" redefined
/home/lep/.python22_compiled/164262/sc_5599df30197fe981824ad8ec934a784e0.cpp:549:1: 
warning: this is the location of the previous definition
E............................................./home/lep/.python22_compiled/164262/sc_9a25bc84add18fe6c75501f6b01bd84e1.cpp: 
In
    function `PyObject* compiled_func(PyObject*, PyObject*)':
/home/lep/.python22_compiled/164262/sc_9a25bc84add18fe6c75501f6b01bd84e1.cpp:535: 
no
    match for `Py::String& < int' operator
/usr/local/lib/python2.2/site-packages/weave/CXX/Objects.hxx:390: candidates
    are: bool Py::Object::operator<(const Py::Object&) const
/usr/local/lib/python2.2/site-packages/weave/CXX/Objects.hxx:1433: 

       bool Py::operator<(const Py::SeqBase<Py::Object>::const_iterator&, 
const
    Py::SeqBase<Py::Object>::const_iterator&)
/usr/local/lib/python2.2/site-packages/weave/CXX/Objects.hxx:1426: 

       bool Py::operator<(const Py::SeqBase<Py::Object>::iterator&, const
    Py::SeqBase<Py::Object>::iterator&)
............................................................................................................................................
======================================================================
ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py", 
line 154, in check_5point_avg_2d
     self.generic_2d(expr)
   File 
"/usr/local/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py", 
line 128, in generic_2d
     mod_location)
   File 
"/usr/local/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py", 
line 84, in generic_test
     blitz_tools.blitz(expr,arg_dict,{},verbose=0) #,
   File "/usr/local/lib/python2.2/site-packages/weave/blitz_tools.py", line 
99, in blitz
     type_factories = blitz_type_factories,
   File "/usr/local/lib/python2.2/site-packages/weave/inline_tools.py", 
line 426, in compile_function
     verbose=verbose, **kw)
   File "/usr/local/lib/python2.2/site-packages/weave/ext_tools.py", line 
349, in compile
     verbose = verbose, **kw)
   File "/usr/local/lib/python2.2/site-packages/weave/build_tools.py", line 
194, in build_extension
     setup(name = module_name, ext_modules = [ext],verbose=verb)
   File "/usr/local/lib/python2.2/distutils/core.py", line 157, in setup
     raise SystemExit, "error: " + str(msg)
CompileError: error: command 'gcc' failed with exit status 1

----------------------------------------------------------------------
Ran 189 tests in 150.327s

FAILED (errors=1)

=================================================================================

Test code taken from the tutorial seems to work. E.g. the example shown 
below works fine.

=================================================================================

import random
import time

def sortedDictValues3(adict):
         keys = adict.keys()
         keys.sort()
         return map(adict.get, keys)

def c_sort(adict):
         assert(type(adict) == type({}))
         code = """
         #line 21 "dict_sort.py"
         Py::List keys = adict.keys();
         Py::List items(keys.length()); keys.sort();
         PyObject* item = NULL;
         for(int i = 0;  i < keys.length();i++)
         {
             item = PyList_GET_ITEM(keys.ptr(),i);
             item = PyDict_GetItem(adict.ptr(),item);
             Py_XINCREF(item);
             PyList_SetItem(items.ptr(),i,item);
         }
         return_val = Py::new_reference_to(items);
         """
         return inline(code,['adict'],verbose=1)


alist = range(100)
random.shuffle(alist)
print alist
adict = {}
for a in alist:
     adict[a] = a
bdict = adict.copy()
b = sortedDictValues3(adict)
print b
c = c_sort(adict)
print c

=================================================================================




-- 
Dr Leighton Pritchard AMRSC
T44, Cledwyn Building
Institute of Biological Sciences
University of Wales, Aberystwyth, SY23 3DD
Tel 01970 622353    ext. 2353
PGP public key - http://www.keyserver.net (0x47B4A485)



From pearu at cens.ioc.ee  Fri Dec  6 11:07:48 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 6 Dec 2002 18:07:48 +0200 (EET)
Subject: [SciPy-user] (long) Weave installation problems on Linux
In-Reply-To: <5.1.0.14.0.20021206150254.05e71dc0@pophost.aber.ac.uk>
Message-ID: <Pine.LNX.4.21.0212061756580.16883-100000@cens.kybi>

On Fri, 6 Dec 2002, Leighton Pritchard wrote:

> $ gcc --v

> gcc version 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)

All errors that you saw from weave tests are due to using a
"wrong" compiler. I believe that the current weave fully supports gcc 2.95
compiler. When using gcc 3.x compilers, some weave test are known to fail.
You may try weave-3.0 from its CVS, it has less issues when using gcc
3.x compilers.

Pearu




From fgibbons at hms.harvard.edu  Fri Dec  6 16:59:25 2002
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Fri, 06 Dec 2002 16:59:25 -0500
Subject: [SciPy-user] interpolate package - scale-dependent?
Message-ID: <5.0.0.25.2.20021206165043.00ae6140@hms.harvard.edu>

I must confess I'm not much of an expert on interpolation. However, I was 
playing around with the interpolate package today, trying to figure out why 
the quality of the spline returned appears to vary with the scale of the 
data: some data (set of (x,y) pairs) that produce a good spline, when the 
y's are divided by a factor of 100, produce a really poor one.

Maybe there are some assumptions about scale inherent in the spline 
algorithm, perhaps relating to the stiffness of the curves. Still, I 
figured that should be user-adjustable. If it is, how do I do it? If not, 
shouldn't there be some documentation on the effective scales that will work?

Regarding docs for that package, they're very hard to read in their current 
form, because each argument's description runs into that of the one that 
follows it. But it turns out, if you put a blank line between the argument 
descriptions, then HappyDoc generates far more legible output. I don't know 
what the formatting rules for HappyDoc are, but wanted to share:

This will cause the output to be run together: "x -- first arg y -- second arg"
x -- first arg
y -- second arg

Putting a space between those lines generates:

x
         first arg
y
         second arg


Readable docs are important in my opinion. Is this a problem with other 
packages too? Perhaps we can come up with a script to fix it SciPy-wide.

-Frank Gibbons

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons



From oliphant at ee.byu.edu  Fri Dec  6 19:34:26 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 6 Dec 2002 17:34:26 -0700 (MST)
Subject: [SciPy-user] interpolate package - scale-dependent?
In-Reply-To: <5.0.0.25.2.20021206165043.00ae6140@hms.harvard.edu>
Message-ID: <Pine.LNX.4.33L2.0212061730250.10246-100000@oliphant.ee.byu.edu>

> I must confess I'm not much of an expert on interpolation. However, I was
> playing around with the interpolate package today, trying to figure out why
> the quality of the spline returned appears to vary with the scale of the
> data: some data (set of (x,y) pairs) that produce a good spline, when the
> y's are divided by a factor of 100, produce a really poor one.

Could you send an example of which commands you are using?


> Regarding docs for that package, they're very hard to read in their current
> form, because each argument's description runs into that of the one that
> follows it. But it turns out, if you put a blank line between the argument
> descriptions, then HappyDoc generates far more legible output. I don't know
> what the formatting rules for HappyDoc are, but wanted to share:
>

Can you use

>>> from scipy import *

>>> info(my command)

Info is a scipy-specific help function that can be expanded in the future
independent of what python's help does.  Currently it works very
similarly.


> This will cause the output to be run together: "x -- first arg y -- second arg"
> x -- first arg
> y -- second arg
>
> Putting a space between those lines generates:
>
> x
>          first arg
> y
>          second arg
>

This sure puts in a lot of whitespace into the docstrings.  But, I'm sure
that most documentation does not do this (a lot of it was written prior to
HappyDoc)


>
> Readable docs are important in my opinion. Is this a problem with other
> packages too? Perhaps we can come up with a script to fix it SciPy-wide.

I think everybody agrees with you.  But, I don't think everybody uses
HappyDoc and therefore doesn't see this problem.  It would be nice if
there were a pre-filter that could be used before HappyDoc so that the
docstrings don't actually have to be changed.


Which command are you trying to use and understand?

-Travis O.





From pearu at cens.ioc.ee  Sun Dec  8 12:21:55 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 8 Dec 2002 19:21:55 +0200 (EET)
Subject: [SciPy-user] ANN: F2PY - Fortran to Python Interface Generator - 6th Release
Message-ID: <Pine.LNX.4.21.0212081921200.20312-100000@cens.kybi>

F2PY - Fortran to Python Interface Generator, Version 2.32.225
---------------------------------------------------------------

I am pleased to announce the sixth public release of F2PY. The purpose of
the F2PY project is to provide a connection between Python and Fortran
programming languages. For more information, see

  http://cens.ioc.ee/projects/f2py2e/

Download source:

  http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz

What's new?
------------

It has been almost a year from the previous release of F2PY. This release
comes with a number of improvements, most important ones are listed as
follows:

- The issue with a Fortran and C multi-dimensional array storage ordering
  is finally resolved. F2PY generated wrappers automatically carry out all
  necessary transformations, trying hard to minimize any performance hits.
  As a result, the end users of F2PY generated wrappers need not to worry
  about this issue anymore, multi-dimensional arrays in Python and Fortran
  have now exactly the same signatures.

- Improved wrapping C functions with F2PY.

- F2PY Users Guide has been throughly revised to describe and illustrate
  all latest F2PY features such as wrapping Fortran 77 COMMON blocks,
  Fortran 90 module data, including Fortran 90 module ALLOCATABLE arrays,
  etc. The F2PY Users Guide is composed using the Python Docutils tool and
  is available here:

    http://cens.ioc.ee/projects/f2py2e/usersguide/

- F2PY has new site for unit testing.

- F2PY uses scipy_distutils from SciPy (www.scipy.org) project for
  compiling Fortran sources and building extension modules.
  Currently, the following Fortran 77/90 compilers are described by
  scipy_distutils:

    Absoft Sun SGI Intel Itanium NAG Compaq Digital Gnu VAST

- Finally, F2PY has been extensively used/tested for wrapping large
  Fortran/C libraries, such as, LAPACK, BLAS, ATLAS, FFTW, FFTPACK,
  etc. (see SciPy project for more information). This experience has been
  a very important source for ideas how to make binding Fortran/C codes to
  Python easier and more robust. 

Enjoy,
	Pearu Peterson

---------------
<P><A HREF="http://cens.ioc.ee/projects/f2py2e/">F2PY 2.32.225</A> - The
Fortran to Python Interface Generator (08-Dec-02)




From costasm at hotmail.com  Mon Dec  9 02:36:42 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Mon, 09 Dec 2002 07:36:42 +0000
Subject: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
Message-ID: <BAY1-F107tgFrYILoyg0000c2b8@hotmail.com>

I use SciPy, mostly for fun (check out my toy at memigo.com).  For a new 
project, I am looking for a way to do sparse matrix algebra in NumPy/SciPy. 
I notice that SciPy/sparse has been pretty much abandoned.  Is it 
functional? if not, are there alternatives?

A working win32 implementation would be a plus (linux required though).

Thanks in advance,

Costas

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail



From lep at aber.ac.uk  Mon Dec  9 04:38:34 2002
From: lep at aber.ac.uk (Leighton Pritchard)
Date: Mon, 09 Dec 2002 09:38:34 +0000
Subject: [SciPy-user] Re: (long) Weave installation problems on Linux
In-Reply-To: <20021206180002.3013.32235.Mailman@shaft>
Message-ID: <5.1.0.14.0.20021209093438.02849cc8@pophost.aber.ac.uk>

At 12:00 06/12/2002, you wrote:
>All errors that you saw from weave tests are due to using a
>"wrong" compiler. I believe that the current weave fully supports gcc 2.95
>compiler. When using gcc 3.x compilers, some weave test are known to fail.
>You may try weave-3.0 from its CVS, it has less issues when using gcc
>3.x compilers.

Thanks for the help. I've obtained weave from cvs using

cvs -d :pserver:anonymous at scipy.org:/home/cvsroot checkout weave

Is there another source for this, as I'm still getting errors of:

==================================================

/usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/ops.h:220: no
    match for `std::complex<float>& / double&' operator

===================================================

/home/lep/.python22_compiled/211372/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp: 
In
    function `PyObject* compiled_func(PyObject*, PyObject*)':
/home/lep/.python22_compiled/211372/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp:649: 
no
    match for `std::string& < int' operator
/home/lep/.python22_compiled/211372/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp:653: 
no
    match for `std::string& + int' operator
/usr/include/g++-v3/bits/stl_bvector.h:267: candidates are:
    std::_Bit_const_iterator std::operator+(int, const
    std::_Bit_const_iterator&)
/usr/include/g++-v3/bits/stl_bvector.h:208:                 std::_Bit_iterator
    std::operator+(int, const std::_Bit_iterator&)

=====================================================

ERROR: result[1:-1,1:-1] = (b[1:-1,1:-1] + b[2:,1:-1] + b[:-2,1:-1]
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py", 
line 150, in check_5point_avg_2d
     self.generic_2d(expr)
   File 
"/usr/local/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py", 
line 124, in generic_2d
     mod_location)
   File 
"/usr/local/lib/python2.2/site-packages/weave/tests/test_blitz_tools.py", 
line 80, in generic_test
     blitz_tools.blitz(expr,arg_dict,{},verbose=0) #,
   File "/usr/local/lib/python2.2/site-packages/weave/blitz_tools.py", line 
72, in blitz
     type_converters = converters.blitz,
   File "/usr/local/lib/python2.2/site-packages/weave/inline_tools.py", 
line 439, in compile_function
     verbose=verbose, **kw)
   File "/usr/local/lib/python2.2/site-packages/weave/ext_tools.py", line 
332, in compile
     verbose = verbose, **kw)
   File "/usr/local/lib/python2.2/site-packages/weave/build_tools.py", line 
221, in build_extension
     setup(name = module_name, ext_modules = [ext],verbose=verb)
   File "/usr/local/lib/python2.2/distutils/core.py", line 157, in setup
     raise SystemExit, "error: " + str(msg)
CompileError: error: command 'gcc' failed with exit status 1

==================================================

Or is this what you meant by 'less issues'? ;)


-- 
Dr Leighton Pritchard AMRSC
T44, Cledwyn Building
Institute of Biological Sciences
University of Wales, Aberystwyth, SY23 3DD
Tel 01970 622353    ext. 2353
PGP public key - http://www.keyserver.net (0x47B4A485)



From pearu at cens.ioc.ee  Mon Dec  9 05:18:11 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 9 Dec 2002 12:18:11 +0200 (EET)
Subject: [SciPy-user] Re: (long) Weave installation problems on Linux
In-Reply-To: <5.1.0.14.0.20021209093438.02849cc8@pophost.aber.ac.uk>
Message-ID: <Pine.LNX.4.21.0212091208010.13275-100000@cens.kybi>

On Mon, 9 Dec 2002, Leighton Pritchard wrote:

> Is there another source for this, as I'm still getting errors of:
> 
> ==================================================
> 
> /usr/local/lib/python2.2/site-packages/weave/blitz-20001213/blitz/ops.h:220: no
>     match for `std::complex<float>& / double&' operator
> 
> ===================================================
> 
> /home/lep/.python22_compiled/211372/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp: 
> In
>     function `PyObject* compiled_func(PyObject*, PyObject*)':
> /home/lep/.python22_compiled/211372/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp:649: 
> no
>     match for `std::string& < int' operator
> /home/lep/.python22_compiled/211372/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp:653: 
> no
>     match for `std::string& + int' operator
> /usr/include/g++-v3/bits/stl_bvector.h:267: candidates are:
>     std::_Bit_const_iterator std::operator+(int, const
>     std::_Bit_const_iterator&)
> /usr/include/g++-v3/bits/stl_bvector.h:208:                 std::_Bit_iterator
>     std::operator+(int, const std::_Bit_iterator&)
> 
> =====================================================

In my case, gcc 3.1.1, the first error is the same but in the second case
I only get the following messages:

=======================
/home/users/pearu/.python22_compiled/14033/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp: In
   function `PyObject* compiled_func(PyObject*, PyObject*)':
/home/users/pearu/.python22_compiled/14033/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp:649: no
   match for `std::string& < int' operator
/home/users/pearu/.python22_compiled/14033/sc_a6df888dc732b38ae7a4c5fa1063b4251.cpp:653: no
   match for `std::string& + int' operator
=======================

though weave.test(10) summary indicates only one error:

----------------------------------------------------------------------
Ran 184 tests in 499.753s

FAILED (errors=1)
<unittest.TextTestRunner instance at 0x84833a4>
>>>

> Or is this what you meant by 'less issues'? ;)

Yes, exactly ;)

Pearu



From fgibbons at hms.harvard.edu  Mon Dec  9 09:59:23 2002
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Mon, 09 Dec 2002 09:59:23 -0500
Subject: [SciPy-user] Interpolation/Documentation woes...
In-Reply-To: <20021207180003.25429.7118.Mailman@shaft>
Message-ID: <5.0.0.25.2.20021209094835.00ac7ab0@hms.harvard.edu>

Travis,

At 01:00 PM 12/7/2002, you wrote:

> > I must confess I'm not much of an expert on interpolation. However, I was
> > playing around with the interpolate package today, trying to figure out why
> > the quality of the spline returned appears to vary with the scale of the
> > data: some data (set of (x,y) pairs) that produce a good spline, when the
> > y's are divided by a factor of 100, produce a really poor one.
>
>Could you send an example of which commands you are using?

Just this:

             import scipy
             from scipy.interpolate import splrep, splev, splint
             tck = splrep(xvals, hvals)
             spline = [ splev(p, tck) for p in xvals]

> > Regarding docs for that package, they're very hard to read in their current
> > form, because each argument's description runs into that of the one that
> > follows it.
>
>
>
>Can you use
>
> >>> from scipy import *
>
> >>> info(my command)
>
>Info is a scipy-specific help function that can be expanded in the future
>independent of what python's help does.  Currently it works very
>similarly.

Well, I could. But I wanted to get an overview of the package, not just an 
individual command. This 'info' sounds useful, but I think a complete set 
of docs is just as important, since that's how newbies (like me) learn 
what's possible in broad terms. The 'info' command sounds more useful when 
you know what you want to do, you just need to be reminded of the arglist, 
or that optional parameter that you rarely use.


> > This will cause the output to be run together: "x -- first arg y -- 
> second arg"
> > x -- first arg
> > y -- second arg
> >
> > Putting a space between those lines generates:
> >
> > x
> >          first arg
> > y
> >          second arg
> >
>
>This sure puts in a lot of whitespace into the docstrings.  But, I'm sure
>that most documentation does not do this (a lot of it was written prior to
>HappyDoc)

I don't know about that - a single line to delineate arguments with 
distinct meanings doesn't sound too extreme to me. But 'info' probably just 
prints out the doc string, in which case I can see how that would seem like 
a lot of whitespace. I only assumed HappyDoc was the default because I 
think that's how the docs are provided in the tarball I downloaded. I'm not 
sure about that, I just remember I tried browsing them when I first 
downloaded about 6 weeks ago, but  gave up because they were too hard to 
read. Then in unrelated work, I came across HappyDoc, and realized that it 
looked just like SciPy's docs, so I went back and played around a little.

> > Readable docs are important in my opinion. Is this a problem with other
> > packages too? Perhaps we can come up with a script to fix it SciPy-wide.
>
>I think everybody agrees with you.  But, I don't think everybody uses
>HappyDoc and therefore doesn't see this problem.  It would be nice if
>there were a pre-filter that could be used before HappyDoc so that the
>docstrings don't actually have to be changed.

I'm still learning about HappyDoc, so I'm not in a position right now to 
suggest how to deal with this problem. Does SciPy have a standard for 
documentation? (Perhaps 'info' is it?)

I was just trying to do some interpolation, and noticed that performance 
was really poor for small (~0.01 or smaller) y-values, but really good for 
large ones (~10 or more). I'll get back with more precise details once I 
understand better what's going on....

Thanks for your response.

-Frank

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons



From pearu at cens.ioc.ee  Mon Dec  9 10:32:12 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 9 Dec 2002 17:32:12 +0200 (EET)
Subject: [SciPy-user] Interpolation/Documentation woes...
In-Reply-To: <5.0.0.25.2.20021209094835.00ac7ab0@hms.harvard.edu>
Message-ID: <Pine.LNX.4.21.0212091704410.13275-100000@cens.kybi>

On Mon, 9 Dec 2002, Frank Gibbons wrote:

> > > Readable docs are important in my opinion. Is this a problem with other
> > > packages too? Perhaps we can come up with a script to fix it SciPy-wide.
> >
> >I think everybody agrees with you.  But, I don't think everybody uses
> >HappyDoc and therefore doesn't see this problem.  It would be nice if
> >there were a pre-filter that could be used before HappyDoc so that the
> >docstrings don't actually have to be changed.
> 
> I'm still learning about HappyDoc, so I'm not in a position right now to 
> suggest how to deal with this problem. Does SciPy have a standard for 
> documentation? (Perhaps 'info' is it?)

The problem is that even Python does not have a standard for
documentation, though is about to be fixed by the Python Docutils
project. 

Currently, Docutils is very much usable for writing Tutorial type of
documentations and producing HTML output, probably also some form of PDF
and Latex (see docutils sandbox).
But Docutils does not generate any documentation from Python sources 
yet. David Goodger seems to be working on that feature these days, though.

So, I think we should not fix any standard for documentation strings at
this moment. Instead, we should try to document as much as possible, and
later on, when Docutils will be able to scan Python files for docs and
provides some recommendation for formatting, then reformat documentation
strings in SciPy accordingly.

For any other documentation bits like README files, Tutorials, etc. we
should start using Docutils already.

Docutils: 
  http://docutils.sourceforge.net/

Regards,
	Pearu



From perry at stsci.edu  Mon Dec  9 10:37:02 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 9 Dec 2002 10:37:02 -0500
Subject: [SciPy-user] numarray equality testing
Message-ID: <NEBBIJKBMLDBLNCEEFOCIEPLCOAA.perry@stsci.edu>

This is a Numeric/numarray compatibility question.

Numeric currently allows the equals ufunc to compare 
arrays of unequal sizes and returns a scalar 0 in such
cases. When arrays have consistent shapes, an array of
ints is returned. We argue that this is inconsistent with
normal ufunc behavior and that it should generate an
exception as do all non-equality ufuncs. (numarray currently
does not allow comparison of shape-inconsistent arrays
including for equality). 

Instead we propose a function whose purpose is to determine
if two arrays are shape consistent (i.e., can be broadcast
against each other) and have all values equal to each other.

>>> array_equal(arange(2), arange(4))
0
>>> array_equal(array([1,2,3]), array([1,2,0]))
0
>>> array_equal( arange(2), None )
0
>>> array_equal( arange(2), not_an_ndarray_instance)
0
>>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3]))
1

Comments?

Perry Greenfield



From perry at stsci.edu  Mon Dec  9 10:37:31 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 9 Dec 2002 10:37:31 -0500
Subject: [SciPy-user] numarray complex comparisons
Message-ID: <NEBBIJKBMLDBLNCEEFOCMEPLCOAA.perry@stsci.edu>

The questions just keep coming...

We need to decide whether or not complex comparisons work.
They do not work for Python scalars. Consistency would argue
for them not working for numarray arrays. However some argue:

1) not allowing them defeats more generic programming. We agreed
until we found that IDL doesn't support them either, and we never
noticed. We are skeptical of this claim and would like to see
real-life examples.

2) it is useful to allow comparisons since that would result in
repeatable, sorting of values (e.g., to find duplicate values)
for ordering purposes. Cannot this just be handled by the sort
routines themselves? Why must this result in comparison operators
working?

In the absence of good examples for 1) or good arguments for 2)
we propose to make complex comparisons generate exceptions.

Perry Greenfield



From perry at stsci.edu  Mon Dec  9 10:37:51 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 9 Dec 2002 10:37:51 -0500
Subject: [SciPy-user] numarray rank-0 array issues
Message-ID: <NEBBIJKBMLDBLNCEEFOCAEPMCOAA.perry@stsci.edu>

A little while ago we tackled the issue of whether indexing numarray
arrays should return Python scalars or rank-0 arrays. For reasons
gone into at great length previously on this list we decided to
always return Python scalars when no precision is lost by conversion to
Python scalars (Float128 may be an exception to this rule, but we'll
deal with that later). We consider this issue closed. But there
are some loose ends.

There was an opinion that reduction operations (e.g., add.reduce)
should always return arrays. However, some desired that the rank-0
arrays returned when reducing a rank-1 array should be indexable
and have a length. In particular:

>>> x = arange(10)
>>> v = add.reduce(x)
>>> print v
55
>>> v
array(55)
>>> len(v)
1
>>> v[0]
55

The great majority objected to len(rank-0) being allowed
as well as rank-0[0] working. We agree.

We propose that at least one version of the reduction operations
always return arrays, but that the array "end-point" always
be a rank-1 len-1 array instead of a rank-0 array. This is because
a rank-1 len-1 array 

1) has a len() = 1
2) can be indexed.
3) because of broadcasting, behaves like a scalar in expressions
   with arrays (i.e., as was intended for rank-0 arrays)

Thus, if one repeatedly reduces an N-dimensional array, one
eventually gets a rank-1 len-1 array, and reducing a rank-1
len-1 array  simply generates a new rank-1 len-1 array with the
same value.

>>> x = arange(10)
>>> v = add.areduce(x)
>>> v
array([55])
>>> add.areduce(v)
array([55])

Is there any reason why this behavior would not serve the purposes
of those that wanted rank-0 arrays returned from reduction operations?

Likewise, we could provide a function to wrap scalars as rank-1 len-1
arrays (much like array(5) produces a rank-0 array) for the purposes
of more generic functions and routines so that checks for scalars
do not need to be made. This function would convert scalars to arrays,
but simply return the arrays themselves if passed as arguments.

One possibility is that we eliminate rank-0 arrays and use rank-1 len-1
arrays in their place (e.g., array(5) returns a rank-1 len-1 array).
The problem is that there may be some who already dependon rank-0
properties and this probably will break existing code. Any opinions?

Finally, the default reduction operation (i.e., add.reduce) could 
be given the behavior described above. We are inclined to leave it
as is, i.e., to return scalars when reducing 1-d arrays and provide
a different operator method (areduce) to always return arrays. Any
disagreements?

Perry Greenfield


From s.mogck at phys.rug.nl  Mon Dec  9 10:43:56 2002
From: s.mogck at phys.rug.nl (Stefan Mogck)
Date: Mon, 9 Dec 2002 16:43:56 +0100
Subject: [SciPy-user] Building VTK from source
Message-ID: <200212091532.QAA07780@dep.phys.rug.nl>

Hallo scipy users!

I'd like to install MayaVi under linux. For that I have to install VTK first. 
I have problems to get the Python bindings into VTK. I hope I configured 
cmake correctly to bind tk, tcl and python. After the configuration I started 
make and I got the following error message:

mk39:/home/stefan/pythonsource/VTK # make
cmake.depends is up-to-date
/home/stefan/pythonsource/VTK/Wrapping: building default_target
/usr/bin/cmake -S/home/stefan/pythonsource/VTK/Wrapping 
-O/home/stefan/pythonsource/VTK/Wrapping -H/home/stefan/pythonsource/VTK 
-B/home/stefan/pythonsource/VTK
CMake Error: Invalid escape sequence \I
in argument 
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.2\InstallPath]/include
make[3]: *** [cmake.depends] Error 255
make[2]: *** [default_target] Error 2
make[1]: *** [default_target_Wrapping] Error 2
make: *** [default_target] Error 2

Has anybody an idea what I have to modify. Probably in FindPythonLibs.cmake?
(I am using python2.2 under linux Suse 7.3)

Thanks, Stefan Mogck


From pearu at cens.ioc.ee  Mon Dec  9 11:01:18 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 9 Dec 2002 18:01:18 +0200 (EET)
Subject: [SciPy-user] Building VTK from source
In-Reply-To: <200212091532.QAA07780@dep.phys.rug.nl>
Message-ID: <Pine.LNX.4.21.0212091757330.6643-100000@cens.kybi>

On Mon, 9 Dec 2002, Stefan Mogck wrote:

> Hallo scipy users!
> 
> I'd like to install MayaVi under linux. For that I have to install VTK first. 

This is OT for scipy mailing lists. Try
  mayavi-users at lists.sourceforge.net
or
  vtkusers at public.kitware.com
instead.

Pearu



From tim.hochberg at ieee.org  Mon Dec  9 11:06:43 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Mon, 9 Dec 2002 09:06:43 -0700
Subject: [SciPy-user] numarray equality testing
References: <NEBBIJKBMLDBLNCEEFOCIEPLCOAA.perry@stsci.edu>
Message-ID: <004101c29f9c$f7d5e560$391e6244@cx781526b>


> This is a Numeric/numarray compatibility question.
>
> Numeric currently allows the equals ufunc to compare
> arrays of unequal sizes and returns a scalar 0 in such
> cases. When arrays have consistent shapes, an array of
> ints is returned. We argue that this is inconsistent with
> normal ufunc behavior and that it should generate an
> exception as do all non-equality ufuncs. (numarray currently
> does not allow comparison of shape-inconsistent arrays
> including for equality).
>
> Instead we propose a function whose purpose is to determine
> if two arrays are shape consistent (i.e., can be broadcast
> against each other) and have all values equal to each other.
>
> >>> array_equal(arange(2), arange(4))
> 0
> >>> array_equal(array([1,2,3]), array([1,2,0]))
> 0
> >>> array_equal( arange(2), None )
> 0
> >>> array_equal( arange(2), not_an_ndarray_instance)
> 0
> >>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3]))
> 1
>
> Comments?

This seems like a good plan. I'm not enthralled by the name though:
array_equal seems equally likely to describethe  behaviour of the unfunc
equal as it does the behaviour above. Maybe array_identical or array_same or
equal_arrays or some such (although none of those are great).

-tim



> Perry Greenfield
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>




From pearu at cens.ioc.ee  Mon Dec  9 11:11:24 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 9 Dec 2002 18:11:24 +0200 (EET)
Subject: [SciPy-user] numarray equality testing
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCIEPLCOAA.perry@stsci.edu>
Message-ID: <Pine.LNX.4.21.0212091801410.6643-100000@cens.kybi>

On Mon, 9 Dec 2002, Perry Greenfield wrote:

> >>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3]))
> 1

Hmm, I would have expected 0. 
What's the rationale for 1?

May be you meant

>>> array_equal(array([[1,2,3]]), array([1,2,3]))
1

which I would agree. Also

>>> array_equal(array([[1],[2],[3]]), array([1,2,3]))
1

but I am not sure about

>>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3,1,2,3]))
1

Pearu




From perry at stsci.edu  Mon Dec  9 11:21:21 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 9 Dec 2002 11:21:21 -0500
Subject: [SciPy-user] RE: numarray equality testing
In-Reply-To: <Pine.LNX.4.21.0212091801410.6643-100000@cens.kybi>
Message-ID: <NEBBIJKBMLDBLNCEEFOCEEPMCOAA.perry@stsci.edu>

Pearu Peterson write:

> On Mon, 9 Dec 2002, Perry Greenfield wrote:
> 
> > >>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3]))
> > 1
> 
> Hmm, I would have expected 0. 
> What's the rationale for 1?
> 
Because the arrays can be broadcast into a consistent 
array. In other words

equals(array([[1,2,3],[1,2,3]]), array([1,2,3])

returns

array([[1,1,1],[1,1,1]])

But I take your meaning. There may be those that wish
to ensure that two arrays are really identical in shape
and have all equal values. Should these be two different
functions? One function with different options.
By the way, I'm open to better function names as Tim Hochberg
suggests.

> May be you meant
> 
> >>> array_equal(array([[1,2,3]]), array([1,2,3]))
> 1
> 
> which I would agree. Also
> 
> >>> array_equal(array([[1],[2],[3]]), array([1,2,3]))
> 1
> 
> but I am not sure about
> 
> >>> array_equal(array([[1,2,3],[1,2,3]]), array([1,2,3,1,2,3]))
> 1
> 
> Pearu

Perry 


From hinsen at cnrs-orleans.fr  Mon Dec  9 12:02:43 2002
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: 09 Dec 2002 18:02:43 +0100
Subject: [SciPy-user] Re: [Numpy-discussion] numarray equality testing
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCIEPLCOAA.perry@stsci.edu>
References: <NEBBIJKBMLDBLNCEEFOCIEPLCOAA.perry@stsci.edu>
Message-ID: <m3lm2z9lcc.fsf@chinon.cnrs-orleans.fr>

"Perry Greenfield" <perry at stsci.edu> writes:

> Instead we propose a function whose purpose is to determine
> if two arrays are shape consistent (i.e., can be broadcast
> against each other) and have all values equal to each other.

So there would be that operation, plus one that checks identity
of shape and all elements? That should cover all needs I can think of.

Konrad.


From hinsen at cnrs-orleans.fr  Mon Dec  9 12:05:22 2002
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: 09 Dec 2002 18:05:22 +0100
Subject: [SciPy-user] Re: [Numpy-discussion] numarray rank-0 array issues
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCAEPMCOAA.perry@stsci.edu>
References: <NEBBIJKBMLDBLNCEEFOCAEPMCOAA.perry@stsci.edu>
Message-ID: <m3fzt79l7x.fsf@chinon.cnrs-orleans.fr>

"Perry Greenfield" <perry at stsci.edu> writes:

> Finally, the default reduction operation (i.e., add.reduce) could 
> be given the behavior described above. We are inclined to leave it
> as is, i.e., to return scalars when reducing 1-d arrays and provide

Please do! There is no point in breaking code without any gain in return.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From oliphant.travis at ieee.org  Mon Dec  9 14:02:02 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 09 Dec 2002 12:02:02 -0700
Subject: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
In-Reply-To: <BAY1-F107tgFrYILoyg0000c2b8@hotmail.com>
References: <BAY1-F107tgFrYILoyg0000c2b8@hotmail.com>
Message-ID: <1039460524.26908.1.camel@travis.local.net>

On Mon, 2002-12-09 at 00:36, Costas Malamas wrote:
> I use SciPy, mostly for fun (check out my toy at memigo.com).  For a new 
> project, I am looking for a way to do sparse matrix algebra in NumPy/SciPy. 
> I notice that SciPy/sparse has been pretty much abandoned.  Is it 
> functional? if not, are there alternatives?

It's not been abandoned.  It's there and compiles for me.  It has not
been extensively tested.  It's fairly complete and is built on top of
other well tested libraries.

Getting it to work on win32 has not been tested entirely.

-Travis O.




From j_r_fonseca at yahoo.co.uk  Mon Dec  9 19:41:48 2002
From: j_r_fonseca at yahoo.co.uk (=?iso-8859-15?Q?Jos=E9?= Fonseca)
Date: Tue, 10 Dec 2002 00:41:48 +0000
Subject: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
In-Reply-To: <BAY1-F107tgFrYILoyg0000c2b8@hotmail.com>
References: <BAY1-F107tgFrYILoyg0000c2b8@hotmail.com>
Message-ID: <20021210004148.GB13985@localhost.localdomain>

On Mon, Dec 09, 2002 at 07:36:42AM +0000, Costas Malamas wrote:
> I use SciPy, mostly for fun (check out my toy at memigo.com).  For a new 
> project, I am looking for a way to do sparse matrix algebra in NumPy/SciPy. 
> I notice that SciPy/sparse has been pretty much abandoned.  Is it 
> functional? if not, are there alternatives?
> 
> A working win32 implementation would be a plus (linux required though).

There is at least one besides SciPY/sparse, which is sparsemodule,
available at http://arctrix.com/nas/python/sparsemodule/

I too wanted some sparse matrix support for some FE structural modal
analysis I ported from Matlab to Numeric Python, so a I made an
exaustive search of everything I could find. In the end, as I mainly
needed to determine the eigenvalues/eigenvectors (which wasn't supported
in any of the sparse modules) I made an ARPACK binding and a very thin
"sparse matrix" wrapper class around it (basically it just allows you to
multiply a matrix by a vector, and to add matrices with the same
sparsity structure, and all matrices have to be preallocated - which
suites perfectly the operation needed for efficient FE analysis).

Jos? Fonseca
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


From kern at caltech.edu  Mon Dec  9 19:46:45 2002
From: kern at caltech.edu (Robert Kern)
Date: Mon, 9 Dec 2002 16:46:45 -0800
Subject: [SciPy-user] numarray equality testing
In-Reply-To: <004101c29f9c$f7d5e560$391e6244@cx781526b>
References: <NEBBIJKBMLDBLNCEEFOCIEPLCOAA.perry@stsci.edu> <004101c29f9c$f7d5e560$391e6244@cx781526b>
Message-ID: <20021210004645.GA3033@taliesen.caltech.edu>

On Mon, Dec 09, 2002 at 09:06:43AM -0700, Tim Hochberg wrote:

[snip]

> This seems like a good plan. I'm not enthralled by the name though:
> array_equal seems equally likely to describethe  behaviour of the unfunc
> equal as it does the behaviour above. Maybe array_identical or array_same or
> equal_arrays or some such (although none of those are great).

I'd put in my vote for array_equiv, equiv, or equivalent since I think
"equivalence" best expresses the relationship tested here, not
"equality."

> -tim

-- 
Robert Kern
Ruddock House President
kern at caltech.edu

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


From oliphant at ee.byu.edu  Mon Dec  9 19:58:43 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Mon, 9 Dec 2002 17:58:43 -0700 (MST)
Subject: [SciPy-user] Interpolation/Documentation woes...
In-Reply-To: <5.0.0.25.2.20021209094835.00ac7ab0@hms.harvard.edu>
Message-ID: <Pine.LNX.4.33L2.0212091754110.10093-100000@oliphant.ee.byu.edu>

> Just this:
>
>              import scipy
>              from scipy.interpolate import splrep, splev, splint
>              tck = splrep(xvals, hvals)
>              spline = [ splev(p, tck) for p in xvals]
>

Note, that splev should accept xvals (i.e. you shouldn't have to do the
list comprehension)

spline = splev(xvals, tck)

should work fine.

Try

info(interpolate)

to get an overview of the interpolate package.

Try

info(scipy)

to get an overview of scipy


In other words, you can use the interactive help to get started with the
package.  Yes docs are important, but there are ways to get help with self
documenting code.

Another command you may find useful is source.

This will list the Python source code of a method or function.

>
> Well, I could. But I wanted to get an overview of the package, not just an
> individual command. This 'info' sounds useful, but I think a complete set
> of docs is just as important, since that's how newbies (like me) learn
> what's possible in broad terms. The 'info' command sounds more useful when
> you know what you want to do, you just need to be reminded of the arglist,
> or that optional parameter that you rarely use.

Again, try using info on a module for more uses.

> > > Readable docs are important in my opinion. Is this a problem with other
> > > packages too? Perhaps we can come up with a script to fix it SciPy-wide.
> >
> >I think everybody agrees with you.  But, I don't think everybody uses
> >HappyDoc and therefore doesn't see this problem.  It would be nice if
> >there were a pre-filter that could be used before HappyDoc so that the
> >docstrings don't actually have to be changed.
>
> I'm still learning about HappyDoc, so I'm not in a position right now to
> suggest how to deal with this problem. Does SciPy have a standard for
> documentation? (Perhaps 'info' is it?)
>
> I was just trying to do some interpolation, and noticed that performance
> was really poor for small (~0.01 or smaller) y-values, but really good for
> large ones (~10 or more). I'll get back with more precise details once I
> understand better what's going on....
>

You are getting the performance of FITPACK here.  I have not heard
complaints like this before.  Make sure you are using it correctly.


-Travis O.



From nwagner at mecha.uni-stuttgart.de  Tue Dec 10 04:38:33 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 10 Dec 2002 10:38:33 +0100
Subject: [SciPy-user] gplt.plot ?
Message-ID: <3DF5B619.6FD81599@mecha.uni-stuttgart.de>

Hi all,

Is it possible to plot y versus x by points which are n o t connected by
a line ?
y and x are arrays
>>> x
array([  1.00000000e+00,   9.91444861e-01,   9.65925826e-01,  
9.23879533e-01,
              8.66025404e-01,   7.93353340e-01,   7.07106781e-01,  
6.08761429e-01,
              5.00000000e-01,   3.82683432e-01,   2.58819045e-01,  
1.30526192e-01,
              6.12303177e-17,  -1.30526192e-01,  -2.58819045e-01, 
-3.82683432e-01,
             -5.00000000e-01,  -6.08761429e-01,  -7.07106781e-01, 
-7.93353340e-01,
             -8.66025404e-01,  -9.23879533e-01,  -9.65925826e-01, 
-9.91444861e-01,
             -1.00000000e+00,  -9.91444861e-01,  -9.65925826e-01, 
-9.23879533e-01,
             -8.66025404e-01,  -7.93353340e-01,  -7.07106781e-01, 
-6.08761429e-01,
             -5.00000000e-01,  -3.82683432e-01,  -2.58819045e-01, 
-1.30526192e-01,
             -1.83690953e-16,   1.30526192e-01,   2.58819045e-01,  
3.82683432e-01,
              5.00000000e-01,   6.08761429e-01,   7.07106781e-01,  
7.93353340e-01,
              8.66025404e-01,   9.23879533e-01,   9.65925826e-01,  
9.91444861e-01])
>>> y
array([  0.00000000e+00,   1.30526192e-01,   2.58819045e-01,  
3.82683432e-01,
              5.00000000e-01,   6.08761429e-01,   7.07106781e-01,  
7.93353340e-01,
              8.66025404e-01,   9.23879533e-01,   9.65925826e-01,  
9.91444861e-01,
              1.00000000e+00,   9.91444861e-01,   9.65925826e-01,  
9.23879533e-01,
              8.66025404e-01,   7.93353340e-01,   7.07106781e-01,  
6.08761429e-01,
              5.00000000e-01,   3.82683432e-01,   2.58819045e-01,  
1.30526192e-01,
              1.22460635e-16,  -1.30526192e-01,  -2.58819045e-01, 
-3.82683432e-01,
             -5.00000000e-01,  -6.08761429e-01,  -7.07106781e-01, 
-7.93353340e-01,
             -8.66025404e-01,  -9.23879533e-01,  -9.65925826e-01, 
-9.91444861e-01,
             -1.00000000e+00,  -9.91444861e-01,  -9.65925826e-01, 
-9.23879533e-01,
             -8.66025404e-01,  -7.93353340e-01,  -7.07106781e-01, 
-6.08761429e-01,
             -5.00000000e-01,  -3.82683432e-01,  -2.58819045e-01, 
-1.30526192e-01])
>>>
Nils


From fgibbons at hms.harvard.edu  Tue Dec 10 14:57:58 2002
From: fgibbons at hms.harvard.edu (Frank Gibbons)
Date: Tue, 10 Dec 2002 14:57:58 -0500
Subject: [SciPy-user] Interpolation
In-Reply-To: <20021210180002.25945.40771.Mailman@shaft>
Message-ID: <5.0.0.25.2.20021210145019.00b0f858@hms.harvard.edu>

Travis,

Thanks for the pointers. I'll try this, and see if I can figure out what's 
going wrong.

In the meantime, and in response to Pearu Peterson's message yesterday 
about Python not having a standard for documentation processing. I don't 
know about you guys, but one of the first things I do with a new package, 
even before I install it, is check out the docs, to get an idea of what it 
does, and how it does it. 'info' is fine, once you've got the system 
installed (and this is not trivial for scipy, what with ATLAS, LAPACK and 
BLAS), but it is of no help to those who don't have it installed. 
Furthermore, I find it handy to have printed documentation. Not only can I 
find things more easily and quickly than most online help systems, but it 
allows me to work in my SciPy interactive window, and still keep the 
documentation in front of me. Without something written, I have to keep 
interrupting my typing with "info(this)" and "info(that)".

For those who know SciPy from the inside out, info is probably all you'll 
ever need. But for those coming from the outside, I think something more is 
necessary, and I think the sooner SciPy has this (well formatted online 
HTML/PDF docs, and something printable, both viewable without having to 
install), the better for it.

I offer this not as a criticism, simply as a user observation. Thanks again 
for the tips.

-Frank


At 01:00 PM 12/10/2002, you wrote:
>Note, that splev should accept xvals (i.e. you shouldn't have to do the
>list comprehension)
>
>spline = splev(xvals, tck)
>
>should work fine.
>
>Try
>
>info(interpolate)
>
>to get an overview of the interpolate package.
>
>Try
>
>info(scipy)
>
>to get an overview of scipy

PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons



From bazell at comcast.net  Tue Dec 10 15:25:21 2002
From: bazell at comcast.net (Dave Bazell)
Date: Tue, 10 Dec 2002 15:25:21 -0500
Subject: [SciPy-user] scipy installation problem
Message-ID: <002501c2a08a$43709d60$6401a8c0@DB>

I installed Numeric20 and solved some of the problems I was having with
Numeric20.  Now, when I import Numeric, I don't get any errors.

However, when import scipy (.1 not .2) I get the following messages.

Is this a problem with the distribution or with my installation?

Any pointers would be appreciated.

Dave


Python 2.2.2 (#1, Oct 21 2002, 12:22:55)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 42,
in ?
    from misc import *
  File "/usr/local/lib/python2.2/site-packages/scipy/misc.py", line 21, in ?
    import scipy.stats
  File "/usr/local/lib/python2.2/site-packages/scipy/stats/__init__.py",
line 4, in ?
    from stats import *
  File "/usr/local/lib/python2.2/site-packages/scipy/stats/stats.py", line
204, in ?
    import math, string, sys, pstat, copy
  File "/usr/local/lib/python2.2/site-packages/scipy/stats/pstat.py", line
176
    exec execstring
SyntaxError: unqualified exec is not allowed in function 'colex' it contains
a nested function with free variables
>>>
>>>





From stephen.walton at csun.edu  Tue Dec 10 15:47:01 2002
From: stephen.walton at csun.edu (Stephen Walton)
Date: 10 Dec 2002 12:47:01 -0800
Subject: [SciPy-user] FW: Vector orientation (pedantry?)
In-Reply-To: <yfsel999zzg.fsf@black132.ex.ac.uk>
References: <JFEGLNDJEDNOMPPHDEJFOEHOEBAA.perry@stsci.edu>
	<yfsu1i9s19e.fsf@black132.ex.ac.uk> <1038244487.28319.66.camel@hector> 
	<yfsel999zzg.fsf@black132.ex.ac.uk>
Message-ID: <1039553222.1314.7.camel@hector>

I'm replying to a long-ago message by Alexander here.  I do understand
the difference between rank and dimensionality, if I've used the right
terms here, and I'm now persuaded that Numarray/Numeric is more
mathematically correct than MATLAB, where as Alexander points out, 1,
[1] and [[1]] are all the same thing, namely a 1-by-1 matrix.

But I want to strongly encourage Alexander to release his matrix
package.  I really like the ideas which I've kept below from his reply. 
More to the point, it would help me wean users from MATLAB and IDL to
SciPy if they could use his more compact notation.

Thanks for listening,
Steve Walton

On Mon, 2002-11-25 at 12:05, Alexander Schmolck wrote:

>  >>> from Numeric import dot, array
>  >>> dot(array([[1],[2],[0.00003]]), array([[1,2,3]]))
> array([[  1.00000000e+00,   2.00000000e+00,   3.00000000e+00],
>        [  2.00000000e+00,   4.00000000e+00,   6.00000000e+00],
>        [  3.00000000e-05,   6.00000000e-05,   9.00000000e-05]])
> 
> 
> would become:
> 
>  >>> from nummat import matrix as mat
>  >>> mat('1;2;0.00003') ._* mat('1,2,3')
> 
>  matrix('''
>   1.00000   2.00000   3.00000
>   2.00000   4.00000   6.00000
>   0.00003   0.00006   0.00009
>  ''')
> 
> 
> I like to think that both input and output are markedly preferable in the
> second case (and much more so for complicated expressions) :)
-- 
Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State
Northridge
stephen.walton at csun.edu



From stephen.walton at csun.edu  Tue Dec 10 15:53:31 2002
From: stephen.walton at csun.edu (Stephen Walton)
Date: 10 Dec 2002 12:53:31 -0800
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCMEPLCOAA.perry@stsci.edu>
References: <NEBBIJKBMLDBLNCEEFOCMEPLCOAA.perry@stsci.edu>
Message-ID: <1039553611.1119.13.camel@hector>

I'm guessing that the lack of screams here means most people are OK with
Perry's decision to have complex comparisons generate exceptions?  It is
fine by me. FWIW, I just did a little experiment in Fortran,.  The
Absoft Linux compiler (version 4.6) considers (a .lt. b) to be
equivalent to (real(a) .lt. real(b)).  g77 throws a compile time
exception on the same code.  So I doubt there is any legacy code which
does anything useful with complex compares and Perry's idea is fine.

Steve

On Mon, 2002-12-09 at 07:37, Perry Greenfield wrote:
> The questions just keep coming...
> 
> We need to decide whether or not complex comparisons work.
> They do not work for Python scalars. Consistency would argue
> for them not working for numarray arrays. However some argue:
> 
> 1) not allowing them defeats more generic programming. We agreed
> until we found that IDL doesn't support them either, and we never
> noticed. We are skeptical of this claim and would like to see
> real-life examples.
> 
> 2) it is useful to allow comparisons since that would result in
> repeatable, sorting of values (e.g., to find duplicate values)
> for ordering purposes. Cannot this just be handled by the sort
> routines themselves? Why must this result in comparison operators
> working?
> 
> In the absence of good examples for 1) or good arguments for 2)
> we propose to make complex comparisons generate exceptions.
> 
> Perry Greenfield
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
-- 
Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State
Northridge
stephen.walton at csun.edu



From oliphant at ee.byu.edu  Tue Dec 10 16:19:08 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 10 Dec 2002 14:19:08 -0700 (MST)
Subject: [SciPy-user] Interpolation
In-Reply-To: <5.0.0.25.2.20021210145019.00b0f858@hms.harvard.edu>
Message-ID: <Pine.LNX.4.33L2.0212101416220.6573-100000@oliphant.ee.byu.edu>

> In the meantime, and in response to Pearu Peterson's message yesterday
> about Python not having a standard for documentation processing. I don't
> know about you guys, but one of the first things I do with a new package,
> even before I install it, is check out the docs, to get an idea of what it
> does, and how it does it. 'info' is fine, once you've got the system
> installed (and this is not trivial for scipy, what with ATLAS, LAPACK and
> BLAS), but it is of no help to those who don't have it installed.
> Furthermore, I find it handy to have printed documentation. Not only can I
> find things more easily and quickly than most online help systems, but it
> allows me to work in my SciPy interactive window, and still keep the
> documentation in front of me. Without something written, I have to keep
> interrupting my typing with "info(this)" and "info(that)".
>
> For those who know SciPy from the inside out, info is probably all you'll
> ever need. But for those coming from the outside, I think something more is
> necessary, and I think the sooner SciPy has this (well formatted online
> HTML/PDF docs, and something printable, both viewable without having to
> install), the better for it.

Again, nobody is disagreeing with you.  Documentation has started but it
is typically not a favorite item for developers to spend valuable time
working on.

We are always anxious for people to contribute documentation.  One of the
difficulties has been deciding on what form that documentation should be
in.  An "automatic" users guide generated from the docstrings is a good
start and we should have something like that available with the package.

>
> I offer this not as a criticism, simply as a user observation. Thanks again
> for the tips.

It wasn't taken that way, and again we'd love any help we could get by way
of documentation....

Thanks,

-Travis O.




From oliphant at ee.byu.edu  Tue Dec 10 16:21:35 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 10 Dec 2002 14:21:35 -0700 (MST)
Subject: [SciPy-user] scipy installation problem
In-Reply-To: <002501c2a08a$43709d60$6401a8c0@DB>
Message-ID: <Pine.LNX.4.33L2.0212101419290.6573-100000@oliphant.ee.byu.edu>

> I installed Numeric20 and solved some of the problems I was having with
> Numeric20.  Now, when I import Numeric, I don't get any errors.
>
> However, when import scipy (.1 not .2) I get the following messages.
>
> Is this a problem with the distribution or with my installation?
>
> Any pointers would be appreciated.
>
> Dave
>
>
> Python 2.2.2 (#1, Oct 21 2002, 12:22:55)
> [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import scipy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 42,
> in ?
>     from misc import *
>   File "/usr/local/lib/python2.2/site-packages/scipy/misc.py", line 21, in ?
>     import scipy.stats
>   File "/usr/local/lib/python2.2/site-packages/scipy/stats/__init__.py",
> line 4, in ?
>     from stats import *
>   File "/usr/local/lib/python2.2/site-packages/scipy/stats/stats.py", line
> 204, in ?
>     import math, string, sys, pstat, copy
>   File "/usr/local/lib/python2.2/site-packages/scipy/stats/pstat.py", line
> 176
>     exec execstring
> SyntaxError: unqualified exec is not allowed in function 'colex' it contains
> a nested function with free variables

An error from an old stats package caused by the change to Python 2.2.

It can be fixed in many ways.

1) Get a new version of SciPy
2) Change your scipy/__init__.py file to not import the stats package if
you don't need it.
3) Fix the offending line in pstat.py yourself or comment out the function
it is in.

Good luck,

-Travis O.




From oliphant at ee.byu.edu  Tue Dec 10 16:32:21 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 10 Dec 2002 14:32:21 -0700 (MST)
Subject: [SciPy-user] FW: Vector orientation (pedantry?)
In-Reply-To: <1039553222.1314.7.camel@hector>
Message-ID: <Pine.LNX.4.33L2.0212101421540.6573-100000@oliphant.ee.byu.edu>

> I'm replying to a long-ago message by Alexander here.  I do understand
> the difference between rank and dimensionality, if I've used the right
> terms here, and I'm now persuaded that Numarray/Numeric is more
> mathematically correct than MATLAB, where as Alexander points out, 1,
> [1] and [[1]] are all the same thing, namely a 1-by-1 matrix.
>
> But I want to strongly encourage Alexander to release his matrix
> package.  I really like the ideas which I've kept below from his reply.
> More to the point, it would help me wean users from MATLAB and IDL to
> SciPy if they could use his more compact notation.

Note, SciPy has matrix functionality already included (borrowed from
Numeric actually).

Contributions from Alexander should really start from that base.

The simple command mat() (a SciPy reference to Matrix.Matrix() from
Numeric) will return a matrix object

Note you can also define a matrix using MATLAB-like syntax if you enclose
it in quotes first.

>>> a = mat('[1,2,3;4,5,6]')
>>> print a
Matrix([[1,2,3],
       [4,5,6]])

a.T  is the transpose of the matrix
a.H  is the Hermitian transpose
a.I  is the inverse
a.A  is the array equivalent of the Matrix

and

a*b is matrix multiplication.
a**k  is matrix power (using an efficient algorithm).


I find it a little amusing that everyone is constantly re-inventing the
wheel here.  Syntax and implementation can always be discussed, but we
should discuss it from what is already present.

Best regards,

-Travis





From eric at enthought.com  Tue Dec 10 16:46:17 2002
From: eric at enthought.com (eric jones)
Date: Tue, 10 Dec 2002 15:46:17 -0600
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <1039553611.1119.13.camel@hector>
Message-ID: <003501c2a095$94f2b320$8901a8c0@ERICDESKTOP>

I haven't commented because there are a lot of other things going on,
and Perry already knows my opinion on the subject.  There are multiple
generic code examples where this has bitten me, and I think I've even
provided demos during these discussions.  The errors only popped up a
year after the code was used in production because an end user passed in
complex values.  It can be argued that not throwing an exception will
result in even worse errors.  I simply disagree based on my experience.

I would prefer numarray to choose to allow complex comparison.  Matlab
is a counter point to IDL and has perhaps at least a 10x user base --
perhaps 100x.  This is the largest user base that we really want to be
comfortable in SciPy.  Also, I almost always choose a solution that
allows generic array code when presented the option. 

SciPy allows the comparison of complex values.  It almost guaranteed
that it will continue to in the future.  Just like with Numeric, it
looks like there will be some slight differences in the behaviors of the
library.  I guess this will be like the difference in Absoft and g77
compilers.  From all the discussions, we have found that Numarray is
really tied to a particular implementation by the legacy of Numeric
unless there is almost a unanimous chorus to change it.  SciPy isn't so
bound and will take liberties.  The potential for differences used to
really bug me, but I'm comfortable with it now -- there are just too
many opinions (and legacy code) to get agreement.  

Off the top of my head, allowing complex comparison and the default
value for the 'axis' keyword will likely be different in SciPy.  I think
Perry came up with a good solution for array reductions that (used to)
return scalars, so that one will be the same across libraries.  There
may be others, but I can't think of any.  All in all, there are very few
differences.  SciPy and Numarray will be much closer in implementation
than SciPy and Numeric.


Regards,
Eric

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Stephen Walton
> Sent: Tuesday, December 10, 2002 2:54 PM
> To: scipy-user at scipy.net
> Subject: Re: [SciPy-user] numarray complex comparisons
> 
> I'm guessing that the lack of screams here means most people are OK
with
> Perry's decision to have complex comparisons generate exceptions?  It
is
> fine by me. FWIW, I just did a little experiment in Fortran,.  The
> Absoft Linux compiler (version 4.6) considers (a .lt. b) to be
> equivalent to (real(a) .lt. real(b)).  g77 throws a compile time
> exception on the same code.  So I doubt there is any legacy code which
> does anything useful with complex compares and Perry's idea is fine.
> 
> Steve
> 
> On Mon, 2002-12-09 at 07:37, Perry Greenfield wrote:
> > The questions just keep coming...
> >
> > We need to decide whether or not complex comparisons work.
> > They do not work for Python scalars. Consistency would argue
> > for them not working for numarray arrays. However some argue:
> >
> > 1) not allowing them defeats more generic programming. We agreed
> > until we found that IDL doesn't support them either, and we never
> > noticed. We are skeptical of this claim and would like to see
> > real-life examples.
> >
> > 2) it is useful to allow comparisons since that would result in
> > repeatable, sorting of values (e.g., to find duplicate values)
> > for ordering purposes. Cannot this just be handled by the sort
> > routines themselves? Why must this result in comparison operators
> > working?
> >
> > In the absence of good examples for 1) or good arguments for 2)
> > we propose to make complex comparisons generate exceptions.
> >
> > Perry Greenfield
> >
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
> --
> Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State
> Northridge
> stephen.walton at csun.edu
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user





From oliphant at ee.byu.edu  Tue Dec 10 17:05:57 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 10 Dec 2002 15:05:57 -0700 (MST)
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <003501c2a095$94f2b320$8901a8c0@ERICDESKTOP>
Message-ID: <Pine.LNX.4.33L2.0212101452590.6827-100000@oliphant.ee.byu.edu>

> I haven't commented because there are a lot of other things going on,
> and Perry already knows my opinion on the subject.  There are multiple
> generic code examples where this has bitten me, and I think I've even
> provided demos during these discussions.  The errors only popped up a
> year after the code was used in production because an end user passed in
> complex values.  It can be argued that not throwing an exception will
> result in even worse errors.  I simply disagree based on my experience.
>

I concur with Eric.

Let complex comparisons just assume the user meant the real part only
rather than throwing an error.

> Off the top of my head, allowing complex comparison and the default
> value for the 'axis' keyword will likely be different in SciPy.

Not to sound like Eric's parrot (we do disagree on some things :-)), but I
have to again agree.

Best,

Travis O.





From pearu at cens.ioc.ee  Tue Dec 10 17:08:31 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 11 Dec 2002 00:08:31 +0200 (EET)
Subject: [SciPy-user] scipy installation problem
In-Reply-To: <002501c2a08a$43709d60$6401a8c0@DB>
Message-ID: <Pine.LNX.4.21.0212102359190.20968-100000@cens.kybi>

On Tue, 10 Dec 2002, Dave Bazell wrote:

> I installed Numeric20 and solved some of the problems I was having with
> Numeric20.  Now, when I import Numeric, I don't get any errors.
  ^^^^^^^^^

You meant Numeric22 here, right? If Numeric20 now works then the problems
that you experienced before with Numeric22 indicate that Numeric22 was not
properly installed due to some installation bugs in either Numeric or
distutils. Removing the old version of Numeric completely (including
its include files) and re-installing Numeric22 should have solved the
problems.

> However, when import scipy (.1 not .2) I get the following messages.
> 
> Is this a problem with the distribution or with my installation?
> 
> Any pointers would be appreciated.

Use SciPy 2 from CVS, it is much more stable than SciPy 1.

Pearu



From tim.hochberg at ieee.org  Tue Dec 10 17:19:37 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Tue, 10 Dec 2002 15:19:37 -0700
Subject: [SciPy-user] numarray complex comparisons
References: <Pine.LNX.4.33L2.0212101452590.6827-100000@oliphant.ee.byu.edu>
Message-ID: <010901c2a09a$3a601ba0$391e6244@cx781526b>

[eric]
> > I haven't commented because there are a lot of other things going on,
> > and Perry already knows my opinion on the subject.  There are multiple
> > generic code examples where this has bitten me, and I think I've even
> > provided demos during these discussions.  The errors only popped up a
> > year after the code was used in production because an end user passed in
> > complex values.  It can be argued that not throwing an exception will
> > result in even worse errors.  I simply disagree based on my experience.
[travis]
> I concur with Eric.
>
> Let complex comparisons just assume the user meant the real part only
> rather than throwing an error.

Please don't. I'm ocassionally in the business of comparing complex numbers
and this is what I want only about half the time. The other half the time I
compare |z| not real(z). This just gives me and everyone in my shoes more
rope to shoot ourselves in the foot.

If you insist on making SciPy differ in this way, please make it easy to
turn off!

If this must happen, it seems that the "the best thing" is to "crush
your..." no ummm... the best thing would by for the function used to map
complex numbers to floats for comparisons be settable in Numarray. Then
numarray could continue to do it the right way for it (throw an exception)
while SciPy could easily plug in it's own comparison function. For instance.

numarray.set_complex_comp_map(lambda V : V.real) # Do it Travis's way
numarray.set_complex_comp_map(lambda V : abs(V)) # Do it my way (although
I'd never actually do this)
numarray.set_complex_comp_map(None) # Turn it off (the way it should be ;)

> > Off the top of my head, allowing complex comparison and the default
> > value for the 'axis' keyword will likely be different in SciPy.
>
> Not to sound like Eric's parrot (we do disagree on some things :-)), but I
> have to again agree.

How is the axis keyword going to differ?

-tim




From stephen.walton at csun.edu  Tue Dec 10 17:40:49 2002
From: stephen.walton at csun.edu (Stephen Walton)
Date: 10 Dec 2002 14:40:49 -0800
Subject: [SciPy-user] FW: Vector orientation (pedantry?)
In-Reply-To: <Pine.LNX.4.33L2.0212101421540.6573-100000@oliphant.ee.byu.edu>
References: <Pine.LNX.4.33L2.0212101421540.6573-100000@oliphant.ee.byu.edu>
Message-ID: <1039560050.1314.139.camel@hector>

On Tue, 2002-12-10 at 13:32, Travis Oliphant wrote:

> I find it a little amusing that everyone is constantly re-inventing the
> wheel here.  Syntax and implementation can always be discussed, but we
> should discuss it from what is already present.

Point taken.  I'll go away and read some docs now :-) .

-- 
Stephen Walton, Professor, Dept. of Physics & Astronomy, Cal State
Northridge
stephen.walton at csun.edu



From perry at stsci.edu  Tue Dec 10 17:44:22 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Tue, 10 Dec 2002 17:44:22 -0500
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <010901c2a09a$3a601ba0$391e6244@cx781526b>
Message-ID: <JFEGLNDJEDNOMPPHDEJFCEKJEBAA.perry@stsci.edu>

Tim Hochberg writes:

> numarray.set_complex_comp_map(lambda V : V.real) # Do it Travis's way
> numarray.set_complex_comp_map(lambda V : abs(V)) # Do it my way (although
> I'd never actually do this)
> numarray.set_complex_comp_map(None) # Turn it off (the way it should be ;)
>
I'm ambivalent about such solutions since if the person that uses them
isn't careful about resetting the behavior, it could lead to
odd problems occurring in other modules that normally work.
Imagine dealing with a bug report with a problem that you can't
replicate. Customization has been talked about with regard to a number
of things (elementwise vs matrix ops, coercion rules, ...) and
this is always a problem. It cuts both ways, yes more convenient
for specialized uses but harder to integrate with other code which
uses other options.

> > > Off the top of my head, allowing complex comparison and the default
> > > value for the 'axis' keyword will likely be different in SciPy.
> >
> > Not to sound like Eric's parrot (we do disagree on some things
> :-)), but I
> > have to again agree.
>
> How is the axis keyword going to differ?
>
Which axis Numeric defaults to using in a multi-dimensional array
for functions or operations that only operate on one dimension
depends on the kind of operation. Reduction-like operations operate
on axis=0, but processing or time-series-like operations operate
on the last axis (axis=-1). Scipy has adopted a simpler rule of always
using axis=-1 as the default. Each has its adherents. See the
numpy-discussion
list archives in June of this year for some example discussion ("default
axis for numarray"). Particularly look at Konrad Hinsen (pro status quo)
and Eric's message (pro scipy behavior).

Perry



From ferrell at diablotech.com  Tue Dec 10 18:04:30 2002
From: ferrell at diablotech.com (ferrell at diablotech.com)
Date: Tue, 10 Dec 2002 16:04:30 -0700
Subject: [SciPy-user] Trouble w/ fastumath
Message-ID: <15862.29438.680500.297768@CHURCHILL.lanl.gov>

I'm having trouble with scipy on my windows2k box running Cygwin.  I
installed the latest version of Numeric (22.0).  I then installed the
latest Cygwin binaries (SciPy-0.2.0_alpha_145.4426.cygwin_py.tar).  By
"install" I mean I untarred them into site-packages, as per the
web-site installation instructions.

Everything seemed to go fine, but when I try to import scipy I get an
exception raised when it's it tries to import fastumath.

Any suggestions of what I might have done wrong?  I looked through the
archives and saw a number of messages about fastumath.  However, I
couldn't make any connection between those messages and the trouble
I'm running into.

thanks
-robert

=> python
Python 2.2.1 (#1, Jun 25 2002, 10:55:46) 
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Numeric
>>> Numeric.__version__
'22.0'
>>> import scipy
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 36, in ?
    from scipy_base import *
  File "/usr/lib/python2.2/site-packages/scipy_base/__init__.py", line 110, in ?
    raise ImportError,mess
ImportError: dlopen: Win32 error 126
>



From pearu at cens.ioc.ee  Tue Dec 10 18:28:48 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 11 Dec 2002 01:28:48 +0200 (EET)
Subject: [SciPy-user] Trouble w/ fastumath
In-Reply-To: <15862.29438.680500.297768@CHURCHILL.lanl.gov>
Message-ID: <Pine.LNX.4.21.0212110125590.20968-100000@cens.kybi>

On Tue, 10 Dec 2002 ferrell at diablotech.com wrote:

> Any suggestions of what I might have done wrong?  I looked through the
> archives and saw a number of messages about fastumath.  However, I
> couldn't make any connection between those messages and the trouble
> I'm running into.

<snip>

> >>> import scipy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 36, in ?
>     from scipy_base import *
>   File "/usr/lib/python2.2/site-packages/scipy_base/__init__.py", line 110, in ?
>     raise ImportError,mess
> ImportError: dlopen: Win32 error 126
> >

Google gives some ideas. See for example

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=20021108105815.24402.qmail%40community10.interfree.it&rnum=4&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%26q%3Ddlopen%253A%2BWin32%2Berror%2B126%2Bpython

HTH,
	Pearu




From ferrell at diablotech.com  Tue Dec 10 18:53:31 2002
From: ferrell at diablotech.com (ferrell at diablotech.com)
Date: Tue, 10 Dec 2002 16:53:31 -0700
Subject: [SciPy-user] Trouble w/ fastumath
In-Reply-To: <Pine.LNX.4.21.0212110125590.20968-100000@cens.kybi>
References: <15862.29438.680500.297768@CHURCHILL.lanl.gov>
	<Pine.LNX.4.21.0212110125590.20968-100000@cens.kybi>
Message-ID: <15862.32379.985375.688647@CHURCHILL.lanl.gov>

Pearu Peterson writes:
 > 
 > On Tue, 10 Dec 2002 ferrell at diablotech.com wrote:
 > 
 > > Any suggestions of what I might have done wrong?  I looked through the
 > > archives and saw a number of messages about fastumath.  However, I
 > > couldn't make any connection between those messages and the trouble
 > > I'm running into.
 > 
 > <snip>
 > 
 > > >>> import scipy
 > > Traceback (most recent call last):
 > >   File "<stdin>", line 1, in ?
 > >   File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 36, in ?
 > >     from scipy_base import *
 > >   File "/usr/lib/python2.2/site-packages/scipy_base/__init__.py", line 110, in ?
 > >     raise ImportError,mess
 > > ImportError: dlopen: Win32 error 126
 > > >
 > 
 > Google gives some ideas. See for example
 > 
 > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=20021108105815.24402.qmail%40community10.interfree.it&rnum=4&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%26q%3Ddlopen%253A%2BWin32%2Berror%2B126%2Bpython
 > 
 > HTH,

Yup.  I didn't know about cygcheck.  That told me that fastumath is
looking for libpython2.1.dll.  I'm running python 2.2.  So I guess
that's the problem.  The download page does say that the cygwin binary
was built for 2.1, but I hadn't thought to look at that.

So, now I know what's wrong, but I'm not sure what to do about it.  I
may try to build from source.

Thanks for the help.

-robert



From prabhu at aero.iitm.ernet.in  Wed Dec 11 00:48:31 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Wed, 11 Dec 2002 11:18:31 +0530
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <003501c2a095$94f2b320$8901a8c0@ERICDESKTOP>
References: <1039553611.1119.13.camel@hector>
	<003501c2a095$94f2b320$8901a8c0@ERICDESKTOP>
Message-ID: <15862.53679.542883.298781@monster.linux.in>

Hi,

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    EJ> I haven't commented because there are a lot of other things
    EJ> going on, and Perry already knows my opinion on the subject.
    EJ> There are multiple generic code examples where this has bitten
    EJ> me, and I think I've even provided demos during these
    EJ> discussions.  The errors only popped up a year after the code
    EJ> was used in production because an end user passed in complex
    EJ> values.  It can be argued that not throwing an exception will
    EJ> result in even worse errors.  I simply disagree based on my
    EJ> experience.

Well, I'm pretty bothered by this decision.  Here are a few things to
think about.

 1. Defining an order for complex numbers is ambiguous.  There is no
 way you can do it right.  Pick one and something else breaks.  So why
 pick anything?  Generating an exception seems the "right" thing to
 do.  I think doing it right is more important than more features or
 whatever.  Compromises tend to make you pay heavily later.

 2. Numeric does a lot of nice things magically (broadcasting etc.)
 and it works because Numeric defined it that way and people are used
 to it.  Treating complex numbers the same way as treating arrays is
 not right.  Complex numbers came first and people are trained to
 think in certain ways about them.  So doing something that would go
 against what is known (or commonly believed) is not the right
 direction to take.

 3. IIRC the problem Eric had was that the users thought the data was
 real, which it really was but for some small imaginary noise.  To me
 it seems that adding an order to complex numbers is the wrong kind of
 fix.  If the user thought the result of some procedure was supposed
 to be real and it is not then the user has a problem and must deal
 with it.  Why should the library try to imagine the right thing to do
 by itself?  Especially when something is potentially wrong and could
 later lead to funny problems.

 4. Most Python developers seem to like the philosphy "explicit is
 better than implicit".  This has worked very well for them.  Why go
 againt it?

 5. Even if you do decide to go ahead and define comparisons between
 complex numbers it would lead to nasty situations.

  Lets say you define '<' and '>' such that it applies to the real
  part of the number.  Then how do you define equality?  If you define
  it as requiring both the real and imaginary to be equal then you
  have an inconsistent order relation.  You can find many numbers that
  are "equal" and yet not identical.  If you use |z| as the
  determining parameter then again you are in for trouble.

So, I think that you should simply raise an exception if you expected
a real number and got a complex number instead.  If this is way too
painful to have to deal with then make some assumption and print it
clearly each time you make that assumption so that the user knows
exactly what is going on and where.  I think this is the cleanest
solution that I'll be confortable with.  Anything else makes me
uncomfortable.  Maybe its because I am not used to this, I dont know.

Thanks for listening.

cheers,
prabhu

p.s. shouldnt this discussion be on scipy-dev?


From nwagner at mecha.uni-stuttgart.de  Wed Dec 11 11:22:41 2002
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 11 Dec 2002 17:22:41 +0100
Subject: [SciPy-user] `linewidth` and `pointsize` options in gplt
Message-ID: <3DF76651.AD450A83@mecha.uni-stuttgart.de>

Hi all,

Is it possible to use the options `linewidth` and `pointsize` in
gplt.plot/gplt.output ?

Nils


From eric at enthought.com  Wed Dec 11 14:07:17 2002
From: eric at enthought.com (eric jones)
Date: Wed, 11 Dec 2002 13:07:17 -0600
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <15862.53679.542883.298781@monster.linux.in>
Message-ID: <004f01c2a148$88d5deb0$8901a8c0@ERICDESKTOP>

Sigh.  I am weary of this topic.  I've discussed it on multiple
occasions with many people -- both by email and face-to-face.  Some
people don't care -- give them a rule and they'll adapt.  The remainder
is about 50% split.  I guess this mirrors other numeric computing
communities.  Some Fortran compilers use one approach, some use the
other.  Matlab uses one approach, IDL uses the other.  Seems like people
either argue from the "moral high ground" (as Prabhu does here) that it
just ain't right to compare complex values, or they argue pragmatically
(as Travis O. and I do) that it breaks generic array code that uses
comparisons.  

I'm happy for others to discuss it, but I doubt I spend any more time on
it after this.  My experience has been that this is a "Mac is better
than Windows" argument.  Everyone has a nice argument and then goes home
with the same opinion and not believing how stupid the other side was
not to "get it."

I'll state the case on last time:

One of the beauties of array math is that algorithms are clear and
concise without a lot of control gunk to obscure what is going on.  If
exceptions are thrown, every comparison in a "generic algorithm" in
SciPy will have to be wrapped with a try/except clause or have a lot of
pre-test code to check for complex values.  The same is true for minimum
and maximum calculations.  As a quick example:

def clip(a,low,hi):
    a = asarray(a) # allows lists or scalars as input
    res = where(a < low,low,a)
    res = where(res > hi,hi,res)
    return res
   
def clip2(a,low,hi):
    a = asarray(a)
    if a.typecode() in ['F','D']:
        reals = a.real
    else:
        reals = a
    if low is complex:
        rlow = low.real
    else:
        rlow = low
    if hi is complex:
        rhi = hi.real
    else:
        rhi = hi
              
    res = where(reals < low,low,reals)
    res = where(res > hi,hi,res)
    return res.astype(a.typecode()) 

I like the first one better.  It does *something* with an array no
matter what its type is.  clip2() does to, but causes all code to run
slower and is a lot more to write and test.  It is even more problematic
on larger functions where the comparisons are buried within multiple
computations.

The third option is to keep the first version of clip() and just have it
fail with an exception.  All I can say is "I don't like that solution."
To which you respond "I do."  

By the way, the choice to use real is useful in many cases.  There are
algorithms that return complex arrays with very small imaginary parts do
to round-off error.  In this case ignoring the imaginary part is often
what you want to do.

If you say "it isn't what I want to do," fine.  You were going to have
to write extra code to handle the case with the exception behavior.  You
can also write your own code now.

As far as the argument that the "comparing reals" is an unexpected
behavior, I agree that it is possible.  On the other hand, if it isn't
if it is the declared behavior, you'll get used to it.  Also, many
people are used to the behavior because it is used in so many other
packages.  

A final argument is if we ever make it possible to have Matlab scripts
run on top of the Python byte code interpreter, this decision makes that
eaiser.  Getting this to work would bring a lot of algorithms into the
fold.  This is a long way out, but I believe it is possible.

> 
> >>>>> "EJ" == eric jones <eric at enthought.com> writes:
> 
>     EJ> I haven't commented because there are a lot of other things
>     EJ> going on, and Perry already knows my opinion on the subject.
>     EJ> There are multiple generic code examples where this has bitten
>     EJ> me, and I think I've even provided demos during these
>     EJ> discussions.  The errors only popped up a year after the code
>     EJ> was used in production because an end user passed in complex
>     EJ> values.  It can be argued that not throwing an exception will
>     EJ> result in even worse errors.  I simply disagree based on my
>     EJ> experience.
> 
> Well, I'm pretty bothered by this decision.  

Funny.  I'm bothered by the other one. :-)

> Here are a few things to think about.
> 
>  1. Defining an order for complex numbers is ambiguous.  There is no
>  way you can do it right.  Pick one and something else breaks.  
>  So why pick anything?  

Because it allows for writing generic array algorithms.

>  Generating an exception seems the "right" thing to
>  do.  I think doing it right is more important than more features or
>  whatever.  Compromises tend to make you pay heavily later.

In this case, "right" is in the eyes of the beholder.

> 
>  2. Numeric does a lot of nice things magically (broadcasting etc.)
>  and it works because Numeric defined it that way and people are used
>  to it.  Treating complex numbers the same way as treating arrays is
>  not right.  Complex numbers came first and people are trained to
>  think in certain ways about them.  So doing something that would go
>  against what is known (or commonly believed) is not the right
>  direction to take.

As I said, many people are comfortable with systems that use this
convention. (Matlab, Absoft Fortran, etc.)  So this argument just
doesn't hold water in my opinion.

> 
>  3. IIRC the problem Eric had was that the users thought the data was
>  real, which it really was but for some small imaginary noise.  To me
>  it seems that adding an order to complex numbers is the wrong kind of
>  fix.  

When possible, I'd like to fix the algorithms (I believe this came up in
eigen values and Pearu fixed the algorithm).

>  If the user thought the result of some procedure was supposed
>  to be real and it is not then the user has a problem and must deal
>  with it.  Why should the library try to imagine the right thing to do
>  by itself?  Especially when something is potentially wrong and could
>  later lead to funny problems.

The rule applied is deterministic -- it doesn't try to "imagine" a right
solution.  It specifies the behavior of the algorithm.  If used wrong,
it will give wrong results.  

> 
>  4. Most Python developers seem to like the philosphy "explicit is
>  better than implicit".  This has worked very well for them.  Why go
>  againt it?

Because, in the case of array math, it breaks the ability to write
generic algorithms without special casing complex numbers.

>  5. Even if you do decide to go ahead and define comparisons between
>  complex numbers it would lead to nasty situations.
> 
>   Lets say you define '<' and '>' such that it applies to the real
>   part of the number.  Then how do you define equality?  If you define
>   it as requiring both the real and imaginary to be equal then you
>   have an inconsistent order relation.  You can find many numbers that
>   are "equal" and yet not identical.  If you use |z| as the
>   determining parameter then again you are in for trouble.

Matlab chooses to treat equality as comparing real and imag parts.  So
equal test if values are identical.  Inequalities use only the real
part.  This is "inconsistent", but works well in practice.

Sorting will to handle complex values differently.  Matlab uses the
following because it is often the desired behavior:

  SORT(X,DIM) sorts along the dimension DIM. 

  When X is complex, the elements are sorted by ABS(X).  Complex
  matches are further sorted by ANGLE(X). 

> 
> So, I think that you should simply raise an exception if you expected
> a real number and got a complex number instead.  If this is way too
> painful to have to deal with then make some assumption and print it
> clearly each time you make that assumption so that the user knows
> exactly what is going on and where.  I think this is the cleanest
> solution that I'll be confortable with.  Anything else makes me
> uncomfortable.  Maybe its because I am not used to this, I dont know.

Printing it out is an option -- although I'm not sure I like it because
it might become *very* noisy in some cases.  This is worth some thought.

> 
> Thanks for listening.

I don't really expect this to convince anyone that comparing reals is
better.  It merely states my rationale and gives the precedence for
comparing reals.  Those fearful of all out calamity should take solace
in the fact that the most used numeric scripting language on the planet
uses the same approach and has proven to be very useful indeed. 

> p.s. shouldnt this discussion be on scipy-dev?

The code is already in SciPy (has been for a while), so it really isn't
a dev question.  I think Perry was most interested in getting the widest
audience for the question as he will use the input to decide how
numarray handles things.

Regards,
eric




From prabhu at aero.iitm.ernet.in  Wed Dec 11 15:03:16 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 12 Dec 2002 01:33:16 +0530
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <004f01c2a148$88d5deb0$8901a8c0@ERICDESKTOP>
References: <15862.53679.542883.298781@monster.linux.in>
	<004f01c2a148$88d5deb0$8901a8c0@ERICDESKTOP>
Message-ID: <15863.39428.435607.268362@monster.linux.in>

Hi,

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    EJ> Sigh.  I am weary of this topic.  I've discussed it on
    EJ> multiple occasions with many people -- both by email and
    EJ> face-to-face.  Some people don't care -- give them a rule and
    EJ> they'll adapt.  The remainder is about 50% split.  I guess

Sure, I agree, folks will get used to whatever assumptions that are
made.

    EJ> this mirrors other numeric computing communities.  Some
    EJ> Fortran compilers use one approach, some use the other.
    EJ> Matlab uses one approach, IDL uses the other.  Seems like
    EJ> people either argue from the "moral high ground" (as Prabhu
    EJ> does here) that it just ain't right to compare complex values,
    EJ> or they argue pragmatically (as Travis O. and I do) that it
    EJ> breaks generic array code that uses comparisons.

Its not really a "moral high ground".  I was trying to give an
alternative argument.  I've only seen "pragmatic" views this far so
thought a different point of view would be good.  Also, I was trying
to make a generic design/philosophy argument.

    EJ> I'm happy for others to discuss it, but I doubt I spend any
    EJ> more time on it after this.  My experience has been that this
    EJ> is a "Mac is better than Windows" argument.  Everyone has a
    EJ> nice argument and then goes home with the same opinion and not
    EJ> believing how stupid the other side was not to "get it."

Well, just to get it straight I never said anyone was stupid in my
email and I did not even venture to think that.  In fact I said what I
did because we were asked.  What I am comfortable with or not does not
make others who disagree stupid and what I am comfortable may well
change in time.

[snip]

    EJ> By the way, the choice to use real is useful in many cases.
    EJ> There are algorithms that return complex arrays with very
    EJ> small imaginary parts do to round-off error.  In this case
    EJ> ignoring the imaginary part is often what you want to do.

Ok, so this is a democratic decision then and you seem to have
evidence that this is the case.  Fine.

[snip]

    >>  So, I think that you should simply raise an exception if you
    >> expected a real number and got a complex number instead.  If
    >> this is way too painful to have to deal with then make some
    >> assumption and print it clearly each time you make that
    >> assumption so that the user knows exactly what is going on and
    >> where.  I think this is the cleanest solution that I'll be
    >> confortable with.  Anything else makes me uncomfortable.  Maybe
    >> its because I am not used to this, I dont know.

    EJ> Printing it out is an option -- although I'm not sure I like
    EJ> it because it might become *very* noisy in some cases.  This
    EJ> is worth some thought.

OK, then atleast something useful came out of my efforts. :)

    EJ> I don't really expect this to convince anyone that comparing
    EJ> reals is better.  It merely states my rationale and gives the
    EJ> precedence for comparing reals.  Those fearful of all out
    EJ> calamity should take solace in the fact that the most used
    EJ> numeric scripting language on the planet uses the same
    EJ> approach and has proven to be very useful indeed.

My concern was simple.  By making an assumption on how to order
complex numbers will we affect results of someones computations?  I
dont know and was thinking of a worst case scenario (which if you ask
me is not a bad thing to do).  I cant argue with Matlab's
experience. :)

cheers,
prabhu


From eric at enthought.com  Wed Dec 11 15:15:26 2002
From: eric at enthought.com (eric jones)
Date: Wed, 11 Dec 2002 14:15:26 -0600
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <15863.39428.435607.268362@monster.linux.in>
Message-ID: <005301c2a152$0e5b9b70$8901a8c0@ERICDESKTOP>

> Prahbu:
> Well, just to get it straight I never said anyone was stupid in my
> email and I did not even venture to think that.  In fact I said what I
> did because we were asked.  What I am comfortable with or not does not
> make others who disagree stupid and what I am comfortable may well
> change in time.

People arguing for the Mac definitely consider everyone else stupid (and
they are right -- although I don't use one). :-)  I was taking a little
"artisitic license" there with the comparison -- Such things rarely
translate to email well I guess.  Prabhu, we've had enough conversations
(and on different sides of the argument) that I know you don't think
people who disagree with you are stupid.  Wrong maybe, but not stupid.
:-)

See ya,
eric 




From perry at stsci.edu  Wed Dec 11 15:24:15 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 11 Dec 2002 15:24:15 -0500
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <004f01c2a148$88d5deb0$8901a8c0@ERICDESKTOP>
Message-ID: <NEBBIJKBMLDBLNCEEFOCAEAKCPAA.perry@stsci.edu>

> def clip(a,low,hi):
>     a = asarray(a) # allows lists or scalars as input
>     res = where(a < low,low,a)
>     res = where(res > hi,hi,res)
>     return res
>    
> def clip2(a,low,hi):
>     a = asarray(a)
>     if a.typecode() in ['F','D']:
>         reals = a.real
>     else:
>         reals = a
>     if low is complex:
>         rlow = low.real
>     else:
>         rlow = low
>     if hi is complex:
>         rhi = hi.real
>     else:
>         rhi = hi
>               
>     res = where(reals < low,low,reals)
>     res = where(res > hi,hi,res)
>     return res.astype(a.typecode()) 
> 
How about a third approach?

def clip3(a,low, hi):
	a = asarray(a)
	res = where(a.real < low, low, a)
	res = where(res.real > hi, hi, res)
	return res

This is as simple as clip, is explicit about the
comparison behavior, and handles complex arrays
in the manner desired. It's true that .real doesn't
currently work on non-complex arrays, but it could,
or we could add a real function that just returns all
non-complex arrays as is and returns the real part of
complex arrays. 

Perry


From pearu at cens.ioc.ee  Wed Dec 11 15:37:07 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 11 Dec 2002 22:37:07 +0200 (EET)
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCAEAKCPAA.perry@stsci.edu>
Message-ID: <Pine.LNX.4.21.0212112225520.19308-100000@cens.kybi>

On Wed, 11 Dec 2002, Perry Greenfield wrote:

<snip>
> This is as simple as clip, is explicit about the
> comparison behavior, and handles complex arrays
> in the manner desired. It's true that .real doesn't
> currently work on non-complex arrays, but it could,
> or we could add a real function that just returns all
> non-complex arrays as is and returns the real part of
> complex arrays. 

+1 for .real and .imag attributes be available for non-complex arrays. It
would be a very useful addition also to current Numeric.

+0.5 for functions real() and imag().

Pearu



From tim.hochberg at ieee.org  Wed Dec 11 15:37:30 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Wed, 11 Dec 2002 13:37:30 -0700
Subject: [SciPy-user] numarray complex comparisons
References: <004f01c2a148$88d5deb0$8901a8c0@ERICDESKTOP>
Message-ID: <00f201c2a155$2f4701f0$391e6244@cx781526b>

[Eric]
[Some stuff elided
> I'll state the case on last time:
>
> One of the beauties of array math is that algorithms are clear and
> concise without a lot of control gunk to obscure what is going on.  If
> exceptions are thrown, every comparison in a "generic algorithm" in
> SciPy will have to be wrapped with a try/except clause or have a lot of
> pre-test code to check for complex values.  The same is true for minimum
> and maximum calculations.  As a quick example:
>
> def clip(a,low,hi):
>     a = asarray(a) # allows lists or scalars as input
>     res = where(a < low,low,a)
>     res = where(res > hi,hi,res)
>     return res
>
> def clip2(a,low,hi):
>     a = asarray(a)
>     if a.typecode() in ['F','D']:
>         reals = a.real
>     else:
>         reals = a
>     if low is complex:
>         rlow = low.real
>     else:
>         rlow = low
>     if hi is complex:
>         rhi = hi.real
>     else:
>         rhi = hi
>
>     res = where(reals < low,low,reals)
>     res = where(res > hi,hi,res)
>     return res.astype(a.typecode())
>
> I like the first one better.  It does *something* with an array no
> matter what its type is.  clip2() does to, but causes all code to run
> slower and is a lot more to write and test.  It is even more problematic
> on larger functions where the comparisons are buried within multiple
> computations.

I think you are drawing the wrong lesson here (but then I would). The second
problem does reveal a real deficiency in Numeric, but it's not the one you
think it is. It's the lack of support for generic access to the real and
imaginary parts of all arrays whether real or complex. This is easily coded,
but it's something that should really be in the Numeric core. I would write
the above functions as:

def clip_by_real(a, low, hi):
     a = asarray(a)
     real_a = real(a)
     res = where(real_a < low, low, a)
     res = where(real_a > hi , hi,  res)

This should have the same effect as clip on complex numbers where complex
comparisons are allowed. It has slightly different effects than clip2 which
always nukes the complex part of a number (probably not the correct
behaviour).

Of course real() and imag() don't currently exist, but they would be easy to
implement. In python a versions would be

def real(a):
     a = asarray(a)
     if a.typecode() in ['F','D']:
         return a.real
     else:
         return a

def imag(a):
     a = asarray(a)
     if a.typecode() in ['F','D']:
         return a.imag
     else:
         return np.zeros(a.shape, a.typecode())

Although it's possible efficiency could be improved, and if coded in C it
could certainly be improved.

-tim




From prabhu at aero.iitm.ernet.in  Wed Dec 11 15:47:04 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 12 Dec 2002 02:17:04 +0530
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCAEAKCPAA.perry@stsci.edu>
References: <004f01c2a148$88d5deb0$8901a8c0@ERICDESKTOP>
	<NEBBIJKBMLDBLNCEEFOCAEAKCPAA.perry@stsci.edu>
Message-ID: <15863.42056.374026.712040@monster.linux.in>

>>>>> "PG" == Perry Greenfield <perry at stsci.edu> writes:

    PG> How about a third approach?

    PG> This is as simple as clip, is explicit about the comparison
    PG> behavior, and handles complex arrays in the manner
    PG> desired. It's true that .real doesn't currently work on
    PG> non-complex arrays, but it could, or we could add a real
    PG> function that just returns all non-complex arrays as is and
    PG> returns the real part of complex arrays.

Nice!  This means treating everything as complex.  I'm sure some might
object.  However, this is nice and along with abs and imag should be
good enough for most?  I think this would also be useful outside the
scope of choosing the right order.

cheers,
prabhu


From tim.hochberg at ieee.org  Wed Dec 11 15:46:22 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Wed, 11 Dec 2002 13:46:22 -0700
Subject: [SciPy-user] numarray complex comparisons
References: <Pine.LNX.4.21.0212112225520.19308-100000@cens.kybi>
Message-ID: <011201c2a156$5d4e30e0$391e6244@cx781526b>

[Pearu]
> On Wed, 11 Dec 2002, Perry Greenfield wrote:
>
> <snip>
> > This is as simple as clip, is explicit about the
> > comparison behavior, and handles complex arrays
> > in the manner desired. It's true that .real doesn't
> > currently work on non-complex arrays, but it could,
> > or we could add a real function that just returns all
> > non-complex arrays as is and returns the real part of
> > complex arrays.
>
> +1 for .real and .imag attributes be available for non-complex arrays. It
> would be a very useful addition also to current Numeric.

I like this idea in abstract, and it would be easy to do for the real
attrib, but I have a hard time seeing how it would work for the imaginary
attribute? For instance:

>>> a = array([1, 2, 3+1j])
>>> a.imag[0] = 5
>>> a
array([ 1.+5.j,  2.+0.j,  3.+1.j])
>>> b = array([1,2,3])
>>> b.imag # OK, this could work -- it could dynamically create an array of
zeros and return them
array([0., 0., 0.])  # Float or int? I dunno
>>> b.imag[0] = 5 # But what the heck is this supposed to? Change b from int
to complex? Do nothing? Spooky!
????

So, I'm +0.5 on always providing '.real', but not '.imag' (-1 until shown it
can work reasonably).

> +0.5 for functions real() and imag().
+1 here.

-tim




From tim.hochberg at ieee.org  Wed Dec 11 16:00:06 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Wed, 11 Dec 2002 14:00:06 -0700
Subject: [SciPy-user] numarray complex comparisons
References: <Pine.LNX.4.21.0212112225520.19308-100000@cens.kybi> <011201c2a156$5d4e30e0$391e6244@cx781526b>
Message-ID: <013001c2a158$4916cc20$391e6244@cx781526b>

I wrote:
[Tim H]
[...]
> So, I'm +0.5 on always providing '.real', but not '.imag' (-1 until shown
it
> can work reasonably).
>
> > +0.5 for functions real() and imag().
> +1 here.

I just realized that imag() suffers from the same problem as ".imag" unless
both real and imag always provide a copy (inefficient) or we can make imag()
return a read only array somehow. (I'm opposed to sometimes returning a copy
and sometimes not -- that's evil).

So now I'm +1 for real(), imag() with imag(a) returning something read only
when a is not complex. And +0.5 for .real, .imag with a.imag returning
something read-only when a is not complex.

-tim




From perry at stsci.edu  Wed Dec 11 16:05:12 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 11 Dec 2002 16:05:12 -0500
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <011201c2a156$5d4e30e0$391e6244@cx781526b>
Message-ID: <NEBBIJKBMLDBLNCEEFOCEEALCPAA.perry@stsci.edu>

Tim Hochberg writes: 
  Pearu Peterson writes:
> > +1 for .real and .imag attributes be available for non-complex 
> arrays. It
> > would be a very useful addition also to current Numeric.
> 
> I like this idea in abstract, and it would be easy to do for the real
> attrib, but I have a hard time seeing how it would work for the imaginary
> attribute? For instance:
> 
> >>> a = array([1, 2, 3+1j])
> >>> a.imag[0] = 5
> >>> a
> array([ 1.+5.j,  2.+0.j,  3.+1.j])
> >>> b = array([1,2,3])
> >>> b.imag # OK, this could work -- it could dynamically create 
> an array of
> zeros and return them
> array([0., 0., 0.])  # Float or int? I dunno
> >>> b.imag[0] = 5 # But what the heck is this supposed to? Change 
> b from int
> to complex? Do nothing? Spooky!
> ????
> 
> So, I'm +0.5 on always providing '.real', but not '.imag' (-1 
> until shown it
> can work reasonably).
> 
I'd agree with Tim that having an .imag attribute for all types
doesn't appear to make sense since there is no data that
really corresponds to it. This could lead to unexpected behavior.
By the way, there is a misleading aspect of .real in that if applied
to an Int array, I would return a reference to the Int array. There 
may be some that think that .real would return a Float type.

Perry



From pearu at cens.ioc.ee  Wed Dec 11 16:11:05 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 11 Dec 2002 23:11:05 +0200 (EET)
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <011201c2a156$5d4e30e0$391e6244@cx781526b>
Message-ID: <Pine.LNX.4.21.0212112257250.19308-100000@cens.kybi>

On Wed, 11 Dec 2002, Tim Hochberg wrote:

> [Pearu]
> > On Wed, 11 Dec 2002, Perry Greenfield wrote:
> >
> > <snip>
> > > This is as simple as clip, is explicit about the
> > > comparison behavior, and handles complex arrays
> > > in the manner desired. It's true that .real doesn't
> > > currently work on non-complex arrays, but it could,
> > > or we could add a real function that just returns all
> > > non-complex arrays as is and returns the real part of
> > > complex arrays.
> >
> > +1 for .real and .imag attributes be available for non-complex arrays. It
> > would be a very useful addition also to current Numeric.
> 
> I like this idea in abstract, and it would be easy to do for the real
> attrib, but I have a hard time seeing how it would work for the imaginary
> attribute? For instance:
> 
> >>> a = array([1, 2, 3+1j])
> >>> a.imag[0] = 5
> >>> a
> array([ 1.+5.j,  2.+0.j,  3.+1.j])
> >>> b = array([1,2,3])
> >>> b.imag # OK, this could work -- it could dynamically create an array of
> zeros and return them
> array([0., 0., 0.])  # Float or int? I dunno

int

> >>> b.imag[0] = 5 # But what the heck is this supposed to? Change b from int
> to complex? Do nothing? Spooky!
> ????

Ok, you got me ;-) Though ...

> So, I'm +0.5 on always providing '.real', but not '.imag' (-1 until
> shown it can work reasonably).

>>> b.imag[0] = 5

should raise exception but

>>> b.imag[0] = 5j

could be reasonable, that is, be equivalent to

>>> b.real[0] = -5

Anyway, I'll change my +1 to +0 for .imag.

Pearu




From costasm at hotmail.com  Wed Dec 11 17:45:25 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Wed, 11 Dec 2002 22:45:25 +0000
Subject: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
Message-ID: <BAY1-F210GFhw7EQtmk0000f8b5@hotmail.com>

Well, it's not in the auto-build.  I downloaded the CVS tree, but my C is 
years behind me.  Is it compilable on win32 (VC++)?  will I have better luck 
with cygwin?  Any tips, or howtos (even general ones) that can be of help?

Thanks,

Costas



>From: Travis Oliphant <oliphant.travis at ieee.org>
>Reply-To: scipy-user at scipy.net
>To: scipy-user at scipy.net
>Subject: Re: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
>Date: 09 Dec 2002 12:02:02 -0700
>
>On Mon, 2002-12-09 at 00:36, Costas Malamas wrote:
> > I use SciPy, mostly for fun (check out my toy at memigo.com).  For a new
> > project, I am looking for a way to do sparse matrix algebra in 
>NumPy/SciPy.
> > I notice that SciPy/sparse has been pretty much abandoned.  Is it
> > functional? if not, are there alternatives?
>
>It's not been abandoned.  It's there and compiles for me.  It has not
>been extensively tested.  It's fairly complete and is built on top of
>other well tested libraries.
>
>Getting it to work on win32 has not been tested entirely.
>
>-Travis O.
>
>
>_______________________________________________
>SciPy-user mailing list
>SciPy-user at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-user

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



From tim.hochberg at ieee.org  Wed Dec 11 18:24:37 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Wed, 11 Dec 2002 16:24:37 -0700
Subject: [SciPy-user] real/imag for non complex numbers [was numarray complex comparisons]
References: <Pine.LNX.4.21.0212112257250.19308-100000@cens.kybi>
Message-ID: <003101c2a16c$7901dba0$391e6244@cx781526b>

Here's my latest thinking on this. I'll put this in the form of a proposal
so that it's easier to comment on. Please comment on part I and part II
separately.

I. Attributes real and imag/imaginary[1]

All numeric array types (i.e., excluding character and object arrays) would
have both a real and imag/imaginary attribute. For complex types ('F', 'D')
this would behave just as it does now. For non-complex types ('i', 'f', 'd',
etc.), the real attribute would return the object itself, while the
imaginary attribute would return a ReadOnlyZeroArray [2] of the correct
shape and typecode. I think that this would provide behaviour consistent
with the current real and imag attributes on complex arrays without
introducing and spooky corner cases (that statement is asking for trouble!).
Examples:

>>> a = array([1,2,3])
>>> a.real[0] = 99
>>> a.real
array([99, 2, 3])
>>> a.imag
array([0,0,0])
>>> a.imag[0] = 99
TypeError: object is read only.

II. Functions real and imag

Two functions real and imag (or imaginary or both) would be provided. The
would behave as if they were defined as shown below, even if item I. is not
adopted.

def real(a):
    return asarray(a).real

def imag(a):
    return asarray(a).imag


Comments?

I'm currently +0 on I. and +1 on II.

-tim



[1] Numeric arrays haveboth imag and imaginary attributes, but they are
identical. I'm not sure what Numarray's plans are in this regard.

[2] A ReadOnlyZeroArray(shape, typecode) would behave like an array of zeros
with the given shape and typecode for all non mutating operations. For
mutation operations (a[x] = b, a += c, etc.) it would raise an exception.
This object does not actually allocate any space, so creation is fast and
memory efficient. Implementing this might be the hardest part of the
proposal.




From eric at enthought.com  Wed Dec 11 18:31:11 2002
From: eric at enthought.com (eric jones)
Date: Wed, 11 Dec 2002 17:31:11 -0600
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCAEAKCPAA.perry@stsci.edu>
Message-ID: <006201c2a16d$665fb250$8901a8c0@ERICDESKTOP>

> Perry Greenfield:
> How about a third approach?
> 
> def clip3(a,low, hi):
> 	a = asarray(a)
> 	res = where(a.real < low, low, a)
> 	res = where(res.real > hi, hi, res)
> 	return res
> 
> This is as simple as clip, is explicit about the
> comparison behavior, and handles complex arrays
> in the manner desired. It's true that .real doesn't
> currently work on non-complex arrays, but it could,
> or we could add a real function that just returns all
> non-complex arrays as is and returns the real part of
> complex arrays.

Sold to the man with the Hubble Telescope (and Tim Hochberg who had a
similar solution)!  Or maybe it is sold to me (the man with a humble
telescope).  

Anyway, I'll buy this solution.  While I continue to prefer the other,
this has very reasonable semantics and the overhead is (probably)
minimal.  So, it is a worthy compromise.  

Hmmm. I still have a gripe though -- what if low or hi is a complex?  It
still throws an exception.  Something like the following will solve this
problem:

 def clip3(a,low, hi):
 	a = asarray(a)
 	res = where(a.real < real(low), low, a)
 	res = where(res.real > real(hi), hi, res)
 	return res

Explicit people should love this (I do not)!  Anyway, I'm still willing
to go with it.  So, version 0.2 of SciPy will keep its current behavior.
If the .real and .imag stuff are added to Numeric (which is desirable),
we can remove complex comparison from SciPy in 0.3.  

The general rule for code added to SciPy will be that functions have
defined behavior for complex array types.  This means code like above
will be used in maximum, minimum, and inequalities.

I guess the discussion was worth one last round...  Thanks Perry for
another workable solution.  SciPy will mirror numarray on complex
comparison.

(Somehow I still have a nagging feeling I'm going to regret this one...)

regards,
eric




From eric at enthought.com  Wed Dec 11 18:37:16 2002
From: eric at enthought.com (eric jones)
Date: Wed, 11 Dec 2002 17:37:16 -0600
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCEEALCPAA.perry@stsci.edu>
Message-ID: <006301c2a16e$404678f0$8901a8c0@ERICDESKTOP>

> Tim Hochberg writes:
>   Pearu Peterson writes:
> > > +1 for .real and .imag attributes be available for non-complex
> > arrays. It
> > > would be a very useful addition also to current Numeric.
> >
> > I like this idea in abstract, and it would be easy to do for the
real
> > attrib, but I have a hard time seeing how it would work for the
> imaginary
> > attribute? For instance:
> >
> > >>> a = array([1, 2, 3+1j])
> > >>> a.imag[0] = 5
> > >>> a
> > array([ 1.+5.j,  2.+0.j,  3.+1.j])
> > >>> b = array([1,2,3])
> > >>> b.imag # OK, this could work -- it could dynamically create
> > an array of
> > zeros and return them
> > array([0., 0., 0.])  # Float or int? I dunno
> > >>> b.imag[0] = 5 # But what the heck is this supposed to? Change
> > b from int
> > to complex? Do nothing? Spooky!
> > ????
> >
> > So, I'm +0.5 on always providing '.real', but not '.imag' (-1
> > until shown it
> > can work reasonably).
> >
> I'd agree with Tim that having an .imag attribute for all types
> doesn't appear to make sense since there is no data that
> really corresponds to it. This could lead to unexpected behavior.
> By the way, there is a misleading aspect of .real in that if applied
> to an Int array, I would return a reference to the Int array. There
> may be some that think that .real would return a Float type.

+1 for .real and .imag and real() and imag() working on all arrays
(based on the same generic programming arguments I've used before).

Can't we make .imag readonly somehow?  The following is caught:

>>> from Numeric import *
>>> a = array((1,2,3),Int32)
>>> a[1] = 1+3j
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: can't convert complex to int; use e.g. int(abs(z))

Numarray could definitely catch an assignment on non-complex arrays
through ___setattr__ or the new(2.2) properties mechanism or whatever
(right?):

>>> a = array((1,2,3),Int32)
>>> a.imag = 1

This following one requires a new array type that is readonly... right?

>>> a.imag[0] = 1

Is defining this sort of thing easy in numarray?  I'm guessing you just
have to derive from numarray.ndarray.NDArray and override the
__setitem__ and __setslice__ method to always throw an exception?

eric

p.s:

It bugs me that the above example (assigning complex into an int array
element) is caught in Numeric but this is not:

>>> a = array((1,2,3))
>>> a = array((1,2,3),Int32)
>>> a[1] = 3.2
>>> a
array([1, 3, 3])

This is a downcast also.  Either both should truncate or both should
throw a type exception.




From perry at stsci.edu  Wed Dec 11 19:55:59 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 11 Dec 2002 19:55:59 -0500
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <006301c2a16e$404678f0$8901a8c0@ERICDESKTOP>
Message-ID: <NEBBIJKBMLDBLNCEEFOCCEANCPAA.perry@stsci.edu>

> +1 for .real and .imag and real() and imag() working on all arrays
> (based on the same generic programming arguments I've used before).
> 
> Can't we make .imag readonly somehow?  The following is caught:
> 
> >>> from Numeric import *
> >>> a = array((1,2,3),Int32)
> >>> a[1] = 1+3j
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> TypeError: can't convert complex to int; use e.g. int(abs(z))
> 
> Numarray could definitely catch an assignment on non-complex arrays
> through ___setattr__ or the new(2.2) properties mechanism or whatever
> (right?):
> 
I think there is more to it than that (how does one prevent general
functions from modifying an array in place; those accesses don't
use slicing or setitem. However, I believe the tools are in place
for numarray to handle read-only arrays.

> >>> a = array((1,2,3),Int32)
> >>> a.imag = 1
> 
> This following one requires a new array type that is readonly... right?
> 
> >>> a.imag[0] = 1
> 
> Is defining this sort of thing easy in numarray?  I'm guessing you just
> have to derive from numarray.ndarray.NDArray and override the
> __setitem__ and __setslice__ method to always throw an exception?
> 
Yes, we should be able to prevent this.

> eric
> 
> p.s:
> 
> It bugs me that the above example (assigning complex into an int array
> element) is caught in Numeric but this is not:
> 
> >>> a = array((1,2,3))
> >>> a = array((1,2,3),Int32)
> >>> a[1] = 3.2
> >>> a
> array([1, 3, 3])
> 
> This is a downcast also.  Either both should truncate or both should
> throw a type exception.
>
I could be done, but I imagine this is a big backward compatibility issue
with Numeric. I'm afraid to ask.

Perry 



From tim.hochberg at ieee.org  Wed Dec 11 19:57:12 2002
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Wed, 11 Dec 2002 17:57:12 -0700
Subject: [SciPy-user] numarray complex comparisons
References: <NEBBIJKBMLDBLNCEEFOCCEANCPAA.perry@stsci.edu>
Message-ID: <009c01c2a179$684e6c80$391e6244@cx781526b>


[eric[
> > It bugs me that the above example (assigning complex into an int array
> > element) is caught in Numeric but this is not:
> >
> > >>> a = array((1,2,3))
> > >>> a = array((1,2,3),Int32)
> > >>> a[1] = 3.2
> > >>> a
> > array([1, 3, 3])
> >
> > This is a downcast also.  Either both should truncate or both should
> > throw a type exception.
[perry]
> I could be done, but I imagine this is a big backward compatibility issue
> with Numeric. I'm afraid to ask.

I think it was just a mistake. You should fix it for NumArray. Want me to
ask on the NumPy list so that people yell at me instead?

-tim




From perry at stsci.edu  Wed Dec 11 20:05:45 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 11 Dec 2002 20:05:45 -0500
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <006201c2a16d$665fb250$8901a8c0@ERICDESKTOP>
Message-ID: <NEBBIJKBMLDBLNCEEFOCKEANCPAA.perry@stsci.edu>


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]On
> Behalf Of eric jones
> Sent: Wednesday, December 11, 2002 6:31 PM
> To: scipy-user at scipy.net
> Subject: RE: [SciPy-user] numarray complex comparisons
 
> Hmmm. I still have a gripe though -- what if low or hi is a complex?  It
> still throws an exception.  Something like the following will solve this
> problem:
> 
>  def clip3(a,low, hi):
>  	a = asarray(a)
>  	res = where(a.real < real(low), low, a)
>  	res = where(res.real > real(hi), hi, res)
>  	return res
> 
> Explicit people should love this (I do not)!  Anyway, I'm still willing
> to go with it.  So, version 0.2 of SciPy will keep its current behavior.
> If the .real and .imag stuff are added to Numeric (which is desirable),
> we can remove complex comparison from SciPy in 0.3.  
>
But this example does raise a genericity issue along a slightly 
different line. One could argue that the function should take
arrays for low and hi also in which case all the arguments should
be wrapped with asarray(), and at least in that instance the
notation would be symmetric (a.real < low.real).

Sure, it is a bit more of a pain, but if we design functions that
are supposed to be generic, issues like this should get some thought.
Should it work with complex numbers? If so, what assumptions should
be applied to comparisons and sorting? I can see that there may be
a number of classes of functions. For some it should just plain be
an error to give them complex arguments. For others, not. I don't
think any automatic scheme will work for all intents. But we should
strive to make those that handle complex numbers as clean to write
as possible in the sense that conditional logic is not required
(but hidden in standard functions like real(), abs(), etc.)

Perry 



From perry at stsci.edu  Wed Dec 11 20:07:53 2002
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 11 Dec 2002 20:07:53 -0500
Subject: [SciPy-user] numarray complex comparisons
In-Reply-To: <009c01c2a179$684e6c80$391e6244@cx781526b>
Message-ID: <NEBBIJKBMLDBLNCEEFOCOEANCPAA.perry@stsci.edu>


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]On
> Behalf Of Tim Hochberg
> Sent: Wednesday, December 11, 2002 7:57 PM
> To: scipy-user at scipy.net
> Subject: Re: [SciPy-user] numarray complex comparisons
>
>
>
>
> [eric[
> > > It bugs me that the above example (assigning complex into an int array
> > > element) is caught in Numeric but this is not:
> > >
> > > >>> a = array((1,2,3))
> > > >>> a = array((1,2,3),Int32)
> > > >>> a[1] = 3.2
> > > >>> a
> > > array([1, 3, 3])
> > >
> > > This is a downcast also.  Either both should truncate or both should
> > > throw a type exception.
> [perry]
> > I could be done, but I imagine this is a big backward
> compatibility issue
> > with Numeric. I'm afraid to ask.
>
> I think it was just a mistake. You should fix it for NumArray. Want me to
> ask on the NumPy list so that people yell at me instead?
>
> -tim
>
Yes, we should ask. I was just wanting to take a breather from
controversial issues. If you'd like to raise the question, please
do. It's a good issue to ask about. And we may hear good arguments
for the current behavior as well.

Perry






From oliphant.travis at ieee.org  Thu Dec 12 15:37:53 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 12 Dec 2002 13:37:53 -0700
Subject: [SciPy-user] real/imag for non complex numbers [was numarray complex comparisons]
In-Reply-To: <003101c2a16c$7901dba0$391e6244@cx781526b>
References: <Pine.LNX.4.21.0212112257250.19308-100000@cens.kybi> 
	<003101c2a16c$7901dba0$391e6244@cx781526b>
Message-ID: <1039725475.2227.13.camel@travis.local.net>

In investigating, why Numeric does not allow a.real for non-complex
arrays which many have argued that it should, I think I uncovered an old
bug in Numeric.

In looking at the code, it appears that the intention was to have a.real
just return a new array (pointing to the same data as a but having a new
header) whenever a was not a complex array.  Unfortunately, the code had
a bug and did not actually return the newly created array.  As a result,
the default behavior of raising an "Attribute not found" exception
occurred.  But, before this happened, the array the reference count on
the array occurred, thereby springing a memory leak. 

Try this out.

a = ones((10,10))

print sys.getrefcount(a)

a.real   # will generate an exception

print sys.getrefcount(a)

a.real  

print sys.getrefcount(a)

Notice that each time a.real is called the reference count for a goes up
by one even though no object is returned.


I have fixed the bug in Numeric CVS by returning the created object for
a.real.

The end result is that a.real works for all arrays (not just
complex-valued ones). 

-Travis O.



On Wed, 2002-12-11 at 16:24, Tim Hochberg wrote:
> 
> Here's my latest thinking on this. I'll put this in the form of a proposal
> so that it's easier to comment on. Please comment on part I and part II
> separately.
> 
> I. Attributes real and imag/imaginary[1]
> 
> All numeric array types (i.e., excluding character and object arrays) would
> have both a real and imag/imaginary attribute. For complex types ('F', 'D')
> this would behave just as it does now. For non-complex types ('i', 'f', 'd',
> etc.), the real attribute would return the object itself, while the
> imaginary attribute would return a ReadOnlyZeroArray [2] of the correct
> shape and typecode. I think that this would provide behaviour consistent
> with the current real and imag attributes on complex arrays without
> introducing and spooky corner cases (that statement is asking for trouble!).
> Examples:
> 
> >>> a = array([1,2,3])
> >>> a.real[0] = 99
> >>> a.real
> array([99, 2, 3])
> >>> a.imag
> array([0,0,0])
> >>> a.imag[0] = 99
> TypeError: object is read only.
> 
> II. Functions real and imag
> 
> Two functions real and imag (or imaginary or both) would be provided. The
> would behave as if they were defined as shown below, even if item I. is not
> adopted.
> 
> def real(a):
>     return asarray(a).real
> 
> def imag(a):
>     return asarray(a).imag
> 
> 
> Comments?
> 
> I'm currently +0 on I. and +1 on II.
> 
> -tim
> 
> 
> 
> [1] Numeric arrays haveboth imag and imaginary attributes, but they are
> identical. I'm not sure what Numarray's plans are in this regard.
> 
> [2] A ReadOnlyZeroArray(shape, typecode) would behave like an array of zeros
> with the given shape and typecode for all non mutating operations. For
> mutation operations (a[x] = b, a += c, etc.) it would raise an exception.
> This object does not actually allocate any space, so creation is fast and
> memory efficient. Implementing this might be the hardest part of the
> proposal.
> 
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From eric at enthought.com  Thu Dec 12 18:12:53 2002
From: eric at enthought.com (eric jones)
Date: Thu, 12 Dec 2002 17:12:53 -0600
Subject: [SciPy-user] real/imag for non complex numbers [was numarray complex comparisons]
In-Reply-To: <1039725475.2227.13.camel@travis.local.net>
Message-ID: <00a101c2a234$02b0de60$8901a8c0@ERICDESKTOP>

> 
> The end result is that a.real works for all arrays (not just
> complex-valued ones).

Nice.  That was a quick fix that shouldn't ruffle any feathers.

Thanks,
eric




From eric at enthought.com  Thu Dec 12 18:44:36 2002
From: eric at enthought.com (eric jones)
Date: Thu, 12 Dec 2002 17:44:36 -0600
Subject: [SciPy-user] "New" bug tracker for SciPy/Weave/Chaco
Message-ID: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>

Hey group,

We've had a Roundup bug tracker for a while now, but haven't really
announced it as we were working out the hitches in it.  I believe it is
in good enough shape now for us to start using it.

Please start submitting bugs to the bugtracker.  

    http://www.scipy.net/roundup/scipy/index

Roundup handles its own login management, so unfortunately it doesn't
integrate seamlessly with the scipy.org site yet (any volunteers?).
You'll have to register as a Roundup user if you want to benefit from
its email system of keeping the bug submitter informed of progress.
Sorry about this, but please do take the time to do this.  It'll help
with communication.  It is also possible to submit bugs anonymously.

There will likely be some bugs in the actual bugtracker.:-|  Let us know
when you see something that needs to be fixed, and we'll try and
accommodate.  We really could use a Roundup/Zope expert from the
community to pitch in on this.

Joe:

Is there a link to point people at for a quick tutorial?  If so, could
you place it on the bugtracker side bar.  If not, could you write up a
quick-start guide.

Thanks,
eric

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 






From DavidA at ActiveState.com  Thu Dec 12 19:51:36 2002
From: DavidA at ActiveState.com (David Ascher)
Date: Thu, 12 Dec 2002 16:51:36 -0800
Subject: [SciPy-user] Re: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco
In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>
References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>
Message-ID: <3DF92F18.3020402@ActiveState.com>

eric jones wrote:

> There will likely be some bugs in the actual bugtracker.:-|  Let us know
> when you see something that needs to be fixed, and we'll try and
> accommodate.  We really could use a Roundup/Zope expert from the
> community to pitch in on this.

Feature requests:

1) make the summary field in a page like 
http://www.scipy.net/roundup/scipy/issue19

bigger -- it currently takes two clicks to get from the bug index to a 
full-enough view of a bug, which is one click too many IMO =).

2) The CSS is weird -- visited links have underlines, not-visited ones don't.

Is this in CVS?  I can fix some of these myself if you want.

--david

PS: What's with "scipy.net" vs. "scipy.org"?





From joe at enthought.com  Fri Dec 13 13:20:54 2002
From: joe at enthought.com (Joe Cooper)
Date: Fri, 13 Dec 2002 12:20:54 -0600
Subject: [SciPy-user] "New" bug tracker for SciPy/Weave/Chaco
In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>
References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>
Message-ID: <3DFA2506.7050007@enthought.com>

eric jones wrote:

> Joe:
> 
> Is there a link to point people at for a quick tutorial?  If so, could
> you place it on the bugtracker side bar.  If not, could you write up a
> quick-start guide.

The general Roundup Users Guide is not bad, and can be found here:

http://roundup.sourceforge.net/doc-0.5/user_guide.html

Little enough of our tracker has been changed that the docs apply 
directly.  We provide access via all of the methods documented (web, 
email, and command line).

If you're familiar with other bug trackers it should be pretty 
self-explanatory.  The biggest question I had (and I think everyone at 
Enthought asked about it at least once) was "What does 'done-cbb' 
mean?", the answer being "Done, Could Be Better".

I'll add a link to the users guide right now, and I'll write up 
something specific to our site today.

If anyone has questions or problems, let me know.
-- 
Joe Cooper <joe at enthought.com>



From joe at enthought.com  Fri Dec 13 13:20:54 2002
From: joe at enthought.com (Joe Cooper)
Date: Fri, 13 Dec 2002 12:20:54 -0600
Subject: [SciPy-user] "New" bug tracker for SciPy/Weave/Chaco
In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>
References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP>
Message-ID: <3DFA2506.7050007@enthought.com>

eric jones wrote:

> Joe:
> 
> Is there a link to point people at for a quick tutorial?  If so, could
> you place it on the bugtracker side bar.  If not, could you write up a
> quick-start guide.

The general Roundup Users Guide is not bad, and can be found here:

http://roundup.sourceforge.net/doc-0.5/user_guide.html

Little enough of our tracker has been changed that the docs apply 
directly.  We provide access via all of the methods documented (web, 
email, and command line).

If you're familiar with other bug trackers it should be pretty 
self-explanatory.  The biggest question I had (and I think everyone at 
Enthought asked about it at least once) was "What does 'done-cbb' 
mean?", the answer being "Done, Could Be Better".

I'll add a link to the users guide right now, and I'll write up 
something specific to our site today.

If anyone has questions or problems, let me know.
-- 
Joe Cooper <joe at enthought.com>



From joe at enthought.com  Fri Dec 13 13:30:33 2002
From: joe at enthought.com (Joe Cooper)
Date: Fri, 13 Dec 2002 12:30:33 -0600
Subject: [SciPy-user] Re: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco
In-Reply-To: <3DF92F18.3020402@ActiveState.com>
References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> <3DF92F18.3020402@ActiveState.com>
Message-ID: <3DFA2749.4080305@enthought.com>

David Ascher wrote:

> PS: What's with "scipy.net" vs. "scipy.org"?

Just one of those things...  ;-)

Easy to change, but there hasn't been an impetus to do so.  scipy.org 
redirects into the zope server that runs the scipy community site, while 
scipy.net is a direct Apache instance.  It's just the way it has always 
been on the scipy.org/scipy.net/enthought.com webserver.

I'll alter it so that either address works when I've got 5 minutes to spare.
-- 
Joe Cooper <joe at enthought.com>



From joe at enthought.com  Fri Dec 13 13:32:25 2002
From: joe at enthought.com (Joe Cooper)
Date: Fri, 13 Dec 2002 12:32:25 -0600
Subject: [SciPy-user] Re: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco
In-Reply-To: <3DFA2749.4080305@enthought.com>
References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> <3DF92F18.3020402@ActiveState.com> <3DFA2749.4080305@enthought.com>
Message-ID: <3DFA27B9.5000507@enthought.com>

Joe Cooper wrote:
> David Ascher wrote:
> 
>> PS: What's with "scipy.net" vs. "scipy.org"?
> 
> 
> Just one of those things...  ;-)
> 
> Easy to change, but there hasn't been an impetus to do so.  scipy.org 
> redirects into the zope server that runs the scipy community site, while 
> scipy.net is a direct Apache instance.  It's just the way it has always 
> been on the scipy.org/scipy.net/enthought.com webserver.
> 
> I'll alter it so that either address works when I've got 5 minutes to 
> spare.

And now I realize Travis already answered this with more knowledge than 
I have on the subject (answering the question "why has it always been 
that way?").
-- 
Joe Cooper <joe at enthought.com>



From eric at enthought.com  Fri Dec 13 16:10:45 2002
From: eric at enthought.com (eric jones)
Date: Fri, 13 Dec 2002 15:10:45 -0600
Subject: [SciPy-user] "New" bug tracker for SciPy/Weave/Chaco
In-Reply-To: <3DFA2506.7050007@enthought.com>
Message-ID: <00c801c2a2ec$1ffea980$8901a8c0@ERICDESKTOP>

Thanks Joe!

eric

> 
> eric jones wrote:
> 
> > Joe:
> >
> > Is there a link to point people at for a quick tutorial?  If so,
could
> > you place it on the bugtracker side bar.  If not, could you write up
a
> > quick-start guide.
> 
> The general Roundup Users Guide is not bad, and can be found here:
> 
> http://roundup.sourceforge.net/doc-0.5/user_guide.html
> 
> Little enough of our tracker has been changed that the docs apply
> directly.  We provide access via all of the methods documented (web,
> email, and command line).
> 
> If you're familiar with other bug trackers it should be pretty
> self-explanatory.  The biggest question I had (and I think everyone at
> Enthought asked about it at least once) was "What does 'done-cbb'
> mean?", the answer being "Done, Could Be Better".
> 
> I'll add a link to the users guide right now, and I'll write up
> something specific to our site today.
> 
> If anyone has questions or problems, let me know.






From costasm at hotmail.com  Sun Dec 15 10:54:06 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Sun, 15 Dec 2002 15:54:06 +0000
Subject: [SciPy-user] Problems compiling scipy/sparse
Message-ID: <BAY1-F181jfhGbfULCd0001360f@hotmail.com>

After my recent inquiry into scipy/sparse, I bit the bullet, downloaded 
SciPy CVS and started compiling everything to get scipy/sparse working.  I 
got through ATLAS, LAPACK, f2py, NumPy and most of sparsekit itself fine, 
but then run into two really bizarre issues:

a) Scipy/sparse/Makefile requires the target _sparsemodule.so (and .o).  
Yet, such a module is not compiled by any component in the directory (the 
closest is _sparsekit.pyf). What gives?

b) After taking out the _sparsemodule.so target from the Makefile, I am 
getting this error which I can't explain (disclaimer: my C is very rusty):
gcc -c -I/usr/include/python2.2 -I./SuperLU/SRC -fpic -O2 _zsuperlumodule.c
cc1: warning: -fpic ignored for target (all code is position independent)
In file included from SuperLU/SRC/zsp_defs.h:23,
                 from _zsuperlumodule.c:26:
SuperLU/SRC/supermatrix.h:19: parse error before numeric constant
SuperLU/SRC/supermatrix.h:21: parse error before numeric constant
make: *** [_zsuperlumodule.o] Error 1

All this is compiled on cygwin, gcc 3.2.  Ideas?

Thanks in advance,

Costas




_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus



From costasm at hotmail.com  Sun Dec 15 12:14:54 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Sun, 15 Dec 2002 17:14:54 +0000
Subject: [SciPy-user] Problems compiling scipy/sparse (more)
Message-ID: <BAY1-F21dVzDpubxcbz00013596@hotmail.com>

Also, I forgot: I run scipy/sparse/setup_sparse.py, with the following 
traceback:

building 'sparse._zsuperlu' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT 
-I/usr/include/py
hon2.2 -c /d/Projects/scipy/scipy/sparse/_zsuperlumodule.c -o 
build/temp.cygwin
1.3.17-i686-2.2/_zsuperlumodule.o
In file included from 
/d/Projects/scipy/scipy/sparse/SuperLU/SRC/zsp_defs.h:23,
                 from /d/Projects/scipy/scipy/sparse/_zsuperlumodule.c:26:
/d/Projects/scipy/scipy/sparse/SuperLU/SRC/supermatrix.h:19: parse error 
before
numeric constant
/d/Projects/scipy/scipy/sparse/SuperLU/SRC/supermatrix.h:21: parse error 
before
numeric constant
In file included from /d/Projects/scipy/scipy/sparse/_zsuperlumodule.c:27:
/d/Projects/scipy/scipy/sparse/SuperLU/SRC/util.h:95: warning: function 
declara
ion isn't a prototype
/d/Projects/scipy/scipy/sparse/SuperLU/SRC/util.h:101: warning: function 
declar
tion isn't a prototype
/d/Projects/scipy/scipy/sparse/_zsuperlumodule.c: In function 
`NRFormat_from_sp
atrix':
/d/Projects/scipy/scipy/sparse/_zsuperlumodule.c:46: warning: implicit 
declarat
on of function `zCreate_CompRow_Matrix'
/d/Projects/scipy/scipy/sparse/_zsuperlumodule.c: In function `Py_zgssv':
/d/Projects/scipy/scipy/sparse/_zsuperlumodule.c:163: warning: implicit 
declara
ion of function `superlu_delete_allkeys'
/d/Projects/scipy/scipy/sparse/_zsuperlumodule.c: At top level:
/d/Projects/scipy/scipy/sparse/_zsuperlumodule.c:190: warning: function 
declara
ion isn't a prototype
error: command 'gcc' failed with exit status 1








>From: "Costas Malamas" <costasm at hotmail.com>
>Reply-To: scipy-user at scipy.net
>To: scipy-user at scipy.net
>Subject: [SciPy-user] Problems compiling scipy/sparse
>Date: Sun, 15 Dec 2002 15:54:06 +0000
>
>After my recent inquiry into scipy/sparse, I bit the bullet, downloaded 
>SciPy CVS and started compiling everything to get scipy/sparse working.  I 
>got through ATLAS, LAPACK, f2py, NumPy and most of sparsekit itself fine, 
>but then run into two really bizarre issues:
>
>a) Scipy/sparse/Makefile requires the target _sparsemodule.so (and .o).  
>Yet, such a module is not compiled by any component in the directory (the 
>closest is _sparsekit.pyf). What gives?
>
>b) After taking out the _sparsemodule.so target from the Makefile, I am 
>getting this error which I can't explain (disclaimer: my C is very rusty):
>gcc -c -I/usr/include/python2.2 -I./SuperLU/SRC -fpic -O2 _zsuperlumodule.c
>cc1: warning: -fpic ignored for target (all code is position independent)
>In file included from SuperLU/SRC/zsp_defs.h:23,
>                 from _zsuperlumodule.c:26:
>SuperLU/SRC/supermatrix.h:19: parse error before numeric constant
>SuperLU/SRC/supermatrix.h:21: parse error before numeric constant
>make: *** [_zsuperlumodule.o] Error 1
>
>All this is compiled on cygwin, gcc 3.2.  Ideas?
>
>Thanks in advance,
>
>Costas
>
>
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE* 
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>SciPy-user mailing list
>SciPy-user at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-user


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail



From oscar at iit.upco.es  Mon Dec 16 03:10:20 2002
From: oscar at iit.upco.es (=?ISO-8859-15?Q?Oscar_L=F3pez?=)
Date: Mon, 16 Dec 2002 09:10:20 +0100
Subject: [SciPy-user] fastumath import error
Message-ID: <3DFD8A6C.2080602@iit.upco.es>

Dear all

I am newbie to python and scipy so perhaps this is a common problem but 
I have checked the archives and despite there exist some similar problem 
reports i wasn't able to find out a proper workaround.

After i installed the scipy from cvs i got:

neptuno:~$ python
Python 2.1.1 (#1, Aug 30 2001, 17:36:05)
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386
Type "copyright", "credits" or "license" for more information.
 >>> import scipy
__file__= scipy/scipy_base/__init__.pyc
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "scipy/__init__.py", line 36, in ?
     from scipy_base import *
   File "/usr/lib/python2.1/site-packages/PIL/__init__.py", line 107, in ?
     # ;-)
ImportError: No module named fastumath
   scipy cannot be imported from its source directory.
   Change to another directory and try again.
 >>>


therefore i changed to:
% cd /usr/lib/python2.1/site-packages/scipy_base
% python
 >>> import scipy
 >>>
I guess that it meant the scipy was imported.
Thus, I tried to add this path to PYTHONPATH in my .bashrc

MYPYTHON=/usr/lib/python2.1/site-packages
export PYTHONPATH=$PYTHONPATH:$MYPYTHON/scipy_base:$MYPYTHON/scipy

and now I got stuck with
Python 2.1.1 (#1, Aug 30 2001, 17:36:05)
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386
Type "copyright", "credits" or "license" for more information.
 >>> import scipy
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "scipy/__init__.py", line 36, in ?
     from scipy_base import *
   File "/usr/lib/python2.1/site-packages/scipy_base/__init__.py", line 
111, in ?    import limits
   File "scipy/scipy_base/limits.py", line 10, in ?
     import scipy_base.fastumath
   File "/usr/lib/python2.1/site-packages/scipy_base/__init__.py", line 
111, in ?    import limits
   File "/usr/lib/python2.1/site-packages/scipy_base/limits.py", line 
11, in ?
     reload(scipy_base.fastumath)
ImportError: reload(): module fastumath not in sys.modules
 >>>

It seems to me that there exist a problem in the environment variables
Please how could i setup the environment variables to import properly 
scipy from elsewhere ? Am i missing something important? Any help is 
really appreciated

Thanks a lot for your help
Best wishes
-- 
http://www.iit.upco.es/~oscar
I tell ya, I was an ugly kid.  I was so ugly that my dad kept the kid's
picture that came with the wallet he bought.
		-- Rodney Dangerfield



From pearu at cens.ioc.ee  Mon Dec 16 04:59:07 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 16 Dec 2002 11:59:07 +0200 (EET)
Subject: [SciPy-user] fastumath import error
In-Reply-To: <3DFD8A6C.2080602@iit.upco.es>
Message-ID: <Pine.LNX.4.21.0212161139440.23014-100000@cens.kybi>

On Mon, 16 Dec 2002, [ISO-8859-15] Oscar L?pez wrote:

> I am newbie to python and scipy so perhaps this is a common problem but 
> I have checked the archives and despite there exist some similar problem 
> reports i wasn't able to find out a proper workaround.
> 
> After i installed the scipy from cvs i got:
> 
> neptuno:~$ python
> Python 2.1.1 (#1, Aug 30 2001, 17:36:05)
> [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386
> Type "copyright", "credits" or "license" for more information.
>  >>> import scipy
> __file__= scipy/scipy_base/__init__.pyc
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "scipy/__init__.py", line 36, in ?
>      from scipy_base import *
>    File "/usr/lib/python2.1/site-packages/PIL/__init__.py", line 107, in ?
>      # ;-)
> ImportError: No module named fastumath
>    scipy cannot be imported from its source directory.
>    Change to another directory and try again.
>  >>>
> 
> 
> therefore i changed to:
> % cd /usr/lib/python2.1/site-packages/scipy_base

That's a rather unexpected choice of "another directory". 
I am not sure that scipy should deal/warn about such misusages. Any
suggestions?

> Thus, I tried to add this path to PYTHONPATH in my .bashrc
> 
> MYPYTHON=/usr/lib/python2.1/site-packages
> export PYTHONPATH=$PYTHONPATH:$MYPYTHON/scipy_base:$MYPYTHON/scipy

No need for that,

> and now I got stuck with
> Python 2.1.1 (#1, Aug 30 2001, 17:36:05)
> [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386
> Type "copyright", "credits" or "license" for more information.
>  >>> import scipy

<snip>

> ImportError: reload(): module fastumath not in sys.modules
>  >>>

> It seems to me that there exist a problem in the environment variables
> Please how could i setup the environment variables to import properly 
> scipy from elsewhere ? Am i missing something important? Any help is 
> really appreciated

You should not define any additinonal  environment variables if scipy is
installed to standard python path (that usually is 
/path/to/site-packages/).
So, undo your changes in PYTHONPATH (acctually, your changes may have
caused the second import error).

Run python somewhere from your home directory and then import scipy.

Pearu



From oscar at iit.upco.es  Mon Dec 16 05:27:18 2002
From: oscar at iit.upco.es (=?ISO-8859-1?Q?Oscar_L=F3pez?=)
Date: Mon, 16 Dec 2002 11:27:18 +0100
Subject: [SciPy-user] fastumath import error
References: <Pine.LNX.4.21.0212161139440.23014-100000@cens.kybi>
Message-ID: <3DFDAA86.9010906@iit.upco.es>

Pearu Peterson wrote:
> On Mon, 16 Dec 2002, [ISO-8859-15] Oscar L?pez wrote:
> 
> 

Thanks Pearu from your promptly answer.

>>therefore i changed to:
>>% cd /usr/lib/python2.1/site-packages/scipy_base
> 
> 
> That's a rather unexpected choice of "another directory". 
> I am not sure that scipy should deal/warn about such misusages. Any
> suggestions?

In fact I choose this directory because in a previously reported similar 
problem

http://www.scipy.org/site_content/remap?rmurl=http%3A//66.106.86.196/pipermail/scipy-user/2002-April/000301.html

you suggested to cd to this directory, so I thought that I should set 
PYTHONPATH to this directory in order to fix permanently the problem

> 
> You should not define any additinonal  environment variables if scipy is
> installed to standard python path (that usually is 
> /path/to/site-packages/).

Yes, scipy is installed at:
/usr/lib/python2.1/site-packages/scipy_base
/usr/lib/python2.1/site-packages/scipy

> So, undo your changes in PYTHONPATH (acctually, your changes may have
> caused the second import error).

I do not follow you here, if I undo the changes in PYTHONPATH i get the 
first reported message. Only if I run python from the directory

/usr/lib/python2.1/site-packages/scipy_base

import scipy works. But if i run python from my home I get the first 
error message.

> 
> Run python somewhere from your home directory and then import scipy.

That was i did ! and I always get the:
 >>ImportError: No module named fastumath

So, what could I do?

Thanks a lot for your help.
Best wishes

-- 
http://www.iit.upco.es/~oscar
Serfs up!
		-- Spartacus



From oscar at iit.upco.es  Mon Dec 16 05:37:43 2002
From: oscar at iit.upco.es (=?ISO-8859-1?Q?Oscar_L=F3pez?=)
Date: Mon, 16 Dec 2002 11:37:43 +0100
Subject: [SciPy-user] fastumath import error
References: <Pine.LNX.4.21.0212161139440.23014-100000@cens.kybi> <3DFDAA86.9010906@iit.upco.es>
Message-ID: <3DFDACF7.3040908@iit.upco.es>

>>
>> Run python somewhere from your home directory and then import scipy.
> 

That is quite strange, If I move to $HOME
% cd $HOME
%python
 >>> import scipy
__file__= scipy/scipy_base/__init__.pyc
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "scipy/__init__.py", line 36, in ?
     from scipy_base import *
   File "/usr/lib/python2.1/site-packages/PIL/__init__.py", line 107
     # ;-)
ImportError: No module named fastumath
   scipy cannot be imported from its source directory.
   Change to another directory and try again.
 >>>

Now If I move to $HOME/tmp and
%python
 >>> import scipy
 >>>


How is it possible? The only difference is that cvs directory scipy is 
at $HOME. So i must run python at a directory that is not the parent of 
the directory of the scipy cvs directory, mustn't I? Please could you 
enlighten me in the resason for this behaviour?

Thanks for your help. Please, I apologize for bother you. I understand a 
little bit better how it works.

-- 
http://www.iit.upco.es/~oscar
You are fairminded, just and loving.



From pearu at cens.ioc.ee  Mon Dec 16 06:37:38 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 16 Dec 2002 13:37:38 +0200 (EET)
Subject: [SciPy-user] fastumath import error
In-Reply-To: <3DFDACF7.3040908@iit.upco.es>
Message-ID: <Pine.LNX.4.21.0212161327520.25582-100000@cens.kybi>

On Mon, 16 Dec 2002, Oscar L?pez wrote:

> >>
> >> Run python somewhere from your home directory and then import scipy.
> > 
> 
> That is quite strange, If I move to $HOME
> % cd $HOME
> %python
>  >>> import scipy
> __file__= scipy/scipy_base/__init__.pyc
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "scipy/__init__.py", line 36, in ?
>      from scipy_base import *
>    File "/usr/lib/python2.1/site-packages/PIL/__init__.py", line 107
>      # ;-)
> ImportError: No module named fastumath
>    scipy cannot be imported from its source directory.
>    Change to another directory and try again.
>  >>>
> 
> Now If I move to $HOME/tmp and
> %python
>  >>> import scipy
>  >>>
> 
> 
> How is it possible? The only difference is that cvs directory scipy is 
> at $HOME. So i must run python at a directory that is not the parent of 
> the directory of the scipy cvs directory, mustn't I?

That's right.

> Please could you enlighten me in the resason for this behaviour?

When you run python from $HOME that also contains scipy cvs source tree,
then importing scipy will pick up scipy source instead of the installed
scipy. I suggest that you make a directory cvs and move scipy source
directory there:

cd $HOME
mkdir cvs
mv scipy cvs

Then you can use scipy also from your home directory.

Regards,
	Pearu



From costasm at hotmail.com  Mon Dec 16 12:55:47 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Mon, 16 Dec 2002 17:55:47 +0000
Subject: [SciPy-user] fastumath import error
Message-ID: <BAY1-F126205Sr0dV4o000145c8@hotmail.com>

I've run into the same exact problem on Cygwin (Linux for all intends and 
purposes).  I am an old hand at Python but new at SciPy. Here's what fixed 
it (and I cannot still figure out why, for the life of me).

I cd'ed into site-packages/scipy_base, fired up python.  At the prompt, I 
did:
import fastumath

Then, I went into site-packages, fired up python and run:
from scipy_base import fastumath

Neither gave me an importing error and since "from scipy import *" has 
worked everywhere.   Which of course makes no sense (unless, it needed some 
.pyc file or something).

C.


>From: Pearu Peterson <pearu at cens.ioc.ee>
>Reply-To: scipy-user at scipy.net
>To: scipy-user at scipy.net
>Subject: Re: [SciPy-user] fastumath import error
>Date: Mon, 16 Dec 2002 13:37:38 +0200 (EET)
>
>
>On Mon, 16 Dec 2002, Oscar L?pez wrote:
>
> > >>
> > >> Run python somewhere from your home directory and then import scipy.
> > >
> >
> > That is quite strange, If I move to $HOME
> > % cd $HOME
> > %python
> >  >>> import scipy
> > __file__= scipy/scipy_base/__init__.pyc
> > Traceback (most recent call last):
> >    File "<stdin>", line 1, in ?
> >    File "scipy/__init__.py", line 36, in ?
> >      from scipy_base import *
> >    File "/usr/lib/python2.1/site-packages/PIL/__init__.py", line 107
> >      # ;-)
> > ImportError: No module named fastumath
> >    scipy cannot be imported from its source directory.
> >    Change to another directory and try again.
> >  >>>
> >
> > Now If I move to $HOME/tmp and
> > %python
> >  >>> import scipy
> >  >>>
> >
> >
> > How is it possible? The only difference is that cvs directory scipy is
> > at $HOME. So i must run python at a directory that is not the parent of
> > the directory of the scipy cvs directory, mustn't I?
>
>That's right.
>
> > Please could you enlighten me in the resason for this behaviour?
>
>When you run python from $HOME that also contains scipy cvs source tree,
>then importing scipy will pick up scipy source instead of the installed
>scipy. I suggest that you make a directory cvs and move scipy source
>directory there:
>
>cd $HOME
>mkdir cvs
>mv scipy cvs
>
>Then you can use scipy also from your home directory.
>
>Regards,
>	Pearu
>
>_______________________________________________
>SciPy-user mailing list
>SciPy-user at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-user


_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail



From bazell at comcast.net  Mon Dec 16 15:09:10 2002
From: bazell at comcast.net (Dave Bazell)
Date: Mon, 16 Dec 2002 15:09:10 -0500
Subject: [SciPy-user] Accessing modules in packages
Message-ID: <001301c2a53f$02423010$6401a8c0@DB>

I am trying to use scipy.cluster.vq.kmeans.  I have imported scipy:

> import scipy

and tried cluster.vq.kmeans(..) but I get an error "no module vq in cluster"
or something like that.

I have tried

from scipy import *
from scipy.cluster import *

and

from scipy.cluster.vq import *

but none of these allow me to access cluster.vq.kmeans.

If I copy the vq.py file to my working directory and do

import vq

then I can access it.

What am I doing wrong?  I am sure this is a simple thing to answer and
displays my current (but decreasing) ignorance of python.

Thanks,

Dave Bazell





From eric at enthought.com  Mon Dec 16 18:25:39 2002
From: eric at enthought.com (eric jones)
Date: Mon, 16 Dec 2002 17:25:39 -0600
Subject: [SciPy-user] Accessing modules in packages
In-Reply-To: <001301c2a53f$02423010$6401a8c0@DB>
Message-ID: <014701c2a55a$74c6a3d0$8901a8c0@ERICDESKTOP>

Hey Dave,

I'm not sure what is going on.  The following works for me:

H:\tmp>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy.cluster.vq import *
>>> kmeans
<function kmeans at 0x01BF36E8>

as does:

H:\tmp>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy.cluster import vq
>>> vq.kmeans
<function kmeans at 0x01BF3FC0>

Do these same commands fail for you?

Regards,
eric

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Dave Bazell
> Sent: Monday, December 16, 2002 2:09 PM
> To: scipy-user at scipy.net
> Subject: [SciPy-user] Accessing modules in packages
> 
> I am trying to use scipy.cluster.vq.kmeans.  I have imported scipy:
> 
> > import scipy
> 
> and tried cluster.vq.kmeans(..) but I get an error "no module vq in
> cluster"
> or something like that.
> 
> I have tried
> 
> from scipy import *
> from scipy.cluster import *
> 
> and
> 
> from scipy.cluster.vq import *
> 
> but none of these allow me to access cluster.vq.kmeans.
> 
> If I copy the vq.py file to my working directory and do
> 
> import vq
> 
> then I can access it.
> 
> What am I doing wrong?  I am sure this is a simple thing to answer and
> displays my current (but decreasing) ignorance of python.
> 
> Thanks,
> 
> Dave Bazell
> 
> 
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user





From fperez at pizero.colorado.edu  Mon Dec 16 19:20:08 2002
From: fperez at pizero.colorado.edu (Fernando Perez)
Date: Mon, 16 Dec 2002 17:20:08 -0700 (MST)
Subject: [SciPy-user] Undefined symbol problems (flapack/min and clapack/clapack_sgetri)
Message-ID: <Pine.LNX.4.44.0212161715170.2619-100000@datamat.colorado.edu>

Hi all,

I'm trying to install the SciPy-0.2.0_alpha_144.4350_src.tar.gz to bring 
my scipy installation up to date. I successfully installed it but I'm 
getting two import errors:

In [1]: import scipy.linalg.flapack
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call 
last)

?

ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/flapack.so: 
undefined symbol: min

In [2]: import scipy.linalg.clapack
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call 
last)

?

ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: 
undefined symbol: clapack_sgetri

Any ideas?

For the second problem, I read the instructions in INSTALL.txt and
followed the suggested steps:

Using ATLAS 3.2.1
-----------------
If import clapack fails with the following error

  ImportError: .../clapack.so : undefined symbol: clapack_sgetri

then you most probably have ATLAS 3.2.1 but linalg module was built
for newer versions of ATLAS.
Fix:
  1) Remove scipy/linalg/clapack.pyf
  2) Rebuild/reinstall scipy.


But this doesn't seem to fix anything (the clapack.pyf file is 
automatically recreated and the problem persists).

I have ATLAS installed, this is the full output of system_info:

root[scipy_distutils]# python system_info.py
atlas_info:
  FOUND:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/lib/atlas']
    include_dirs = ['/usr/local/include/atlas']

blas_info:
  NOT AVAILABLE

blas_src_info:
  NOT AVAILABLE

dfftw_info:
  NOT AVAILABLE

dfftw_threads_info:
  NOT AVAILABLE

djbfft_info:
  NOT AVAILABLE

fftw_info:
  NOT AVAILABLE

fftw_threads_info:
  NOT AVAILABLE

lapack_info:
  NOT AVAILABLE

lapack_src_info:
  NOT AVAILABLE

sfftw_info:
  NOT AVAILABLE

sfftw_threads_info:
  NOT AVAILABLE

x11_info:
  FOUND:
    libraries = ['X11']
    library_dirs = ['/usr/X11R6/lib']
    include_dirs = ['/usr/X11R6/include']


My system is a Mandrake 8.2 box. Any help would be greatly appreciated.

Cheers,

f.



From s.mogck at phys.rug.nl  Tue Dec 17 02:53:15 2002
From: s.mogck at phys.rug.nl (Stefan Mogck)
Date: Tue, 17 Dec 2002 08:53:15 +0100
Subject: [SciPy-user] Undefined symbol problems (flapack/min and clapack/clapack_sgetri)
In-Reply-To: <Pine.LNX.4.44.0212161715170.2619-100000@datamat.colorado.edu>
References: <Pine.LNX.4.44.0212161715170.2619-100000@datamat.colorado.edu>
Message-ID: <200212170739.IAA11244@dep.phys.rug.nl>

On Tuesday 17 December 2002 01:20, you wrote:

Hi Fernando,

1. You have to complete the lapack library under /usr/local/lib/atlas. I 
think in this directory liblapack.a  has a size of about 3MB. It should be 
around 6MB.  The best is to install the original lapack library from 
netlib.org. I think the lapack package from your linux distribution may be is 
also good.

2. Now you have to complete the atlas lapack library with the original lapack 
library. See instruction under 

http://math-atlas.sourceforge.net/errata.html#completelp

3. I had the same problem like you. I just modify setup.py in the Numeric 
package and say 'Numeric' where your lapack, blas and g2c libraries are and 
rebuild it.

for instance:
      libraries = ['lapack',blas,'g2c']
      libraries_dirs=                 
['/usr/lib',/usr/local/lib','/usr/local/lib/atlas',/usr/lib/gcc-lib/i486-suse-linux/2.95.3']



I hope this helps you a little bit

Greetings, Stefan

>

> Hi all,
>
> I'm trying to install the SciPy-0.2.0_alpha_144.4350_src.tar.gz to bring
> my scipy installation up to date. I successfully installed it but I'm
> getting two import errors:
>
> In [1]: import scipy.linalg.flapack
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call
> last)
>
> ?
>
> ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/flapack.so:
> undefined symbol: min
>
> In [2]: import scipy.linalg.clapack
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call
> last)
>
> ?
>
> ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so:
> undefined symbol: clapack_sgetri
>
> Any ideas?
>
> For the second problem, I read the instructions in INSTALL.txt and
> followed the suggested steps:
>
> Using ATLAS 3.2.1
> -----------------
> If import clapack fails with the following error
>
>   ImportError: .../clapack.so : undefined symbol: clapack_sgetri
>
> then you most probably have ATLAS 3.2.1 but linalg module was built
> for newer versions of ATLAS.
> Fix:
>   1) Remove scipy/linalg/clapack.pyf
>   2) Rebuild/reinstall scipy.
>
>
> But this doesn't seem to fix anything (the clapack.pyf file is
> automatically recreated and the problem persists).
>
> I have ATLAS installed, this is the full output of system_info:
>
> root[scipy_distutils]# python system_info.py
> atlas_info:
>   FOUND:
>     libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
>     library_dirs = ['/usr/local/lib/atlas']
>     include_dirs = ['/usr/local/include/atlas']
>
> blas_info:
>   NOT AVAILABLE
>
> blas_src_info:
>   NOT AVAILABLE
>
> dfftw_info:
>   NOT AVAILABLE
>
> dfftw_threads_info:
>   NOT AVAILABLE
>
> djbfft_info:
>   NOT AVAILABLE
>
> fftw_info:
>   NOT AVAILABLE
>
> fftw_threads_info:
>   NOT AVAILABLE
>
> lapack_info:
>   NOT AVAILABLE
>
> lapack_src_info:
>   NOT AVAILABLE
>
> sfftw_info:
>   NOT AVAILABLE
>
> sfftw_threads_info:
>   NOT AVAILABLE
>
> x11_info:
>   FOUND:
>     libraries = ['X11']
>     library_dirs = ['/usr/X11R6/lib']
>     include_dirs = ['/usr/X11R6/include']
>
>
> My system is a Mandrake 8.2 box. Any help would be greatly appreciated.
>
> Cheers,
>
> f.
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user



From gvermeul at grenoble.cnrs.fr  Tue Dec 17 04:19:28 2002
From: gvermeul at grenoble.cnrs.fr (Gerard Vermeulen)
Date: Tue, 17 Dec 2002 10:19:28 +0100
Subject: [SciPy-user] PyQwt upgrade
Message-ID: <20021217091928.GA3077@venus.grenoble.cnrs.fr>

Announcing PyQwt-3.5

PyQwt = FAST and EASY data plotting for Python, Numeric and Qt!

PyQwt is a set of Python bindings for the Qwt C++ class library.
The Qwt library extends the Qt framework with widgets for
Scientific and Engineering applications.

PyQwt requires and extends PyQt, a set of Python bindings for Qt.

PyQwt requires Numeric.  Numeric extends the Python language
with new data types that make Python an ideal language for
numerical computing and experimentation.    

PyQwt runs on Windows and Unix/Linux.

The home page of PyQwt is http://gerard.vermeulen.free.fr


New in PyQwt-3.5:

1. Upgraded to PyQt-3.5/sip-3.5 and Qt-3.1.0.

2. Builds by default with Qwt-2002-08-07 or optionally with Qwt-2002-10-13. 

3. setup.py installs now also the documentation for the Qwt library.

4. The LATEST change in version numbering scheme :-) From now on I will track
   the PyQt/sip version numbers with a possible extra a, b, c, ... for bugfix
   releases.

Gerard Vermeulen


From bazell at comcast.net  Tue Dec 17 07:43:52 2002
From: bazell at comcast.net (Dave Bazell)
Date: Tue, 17 Dec 2002 07:43:52 -0500
Subject: [SciPy-user] Accessing modules in packages
References: <014701c2a55a$74c6a3d0$8901a8c0@ERICDESKTOP>
Message-ID: <000701c2a5c9$f65b3fe0$6401a8c0@DB>

OK, I got it.  I have been doing:

>>> from scipy.cluster import *
>>> vq.kmeans
        traceback...
        vq not defines...

There is no __all__ list defined in cluster/__init__.py so my statement does
not import vq.  I can import * from the vq package or explicitly import vq
from the cluster package and get to kmeans.

Thanks,

Dave
----- Original Message -----
From: "eric jones" <eric at enthought.com>
To: <scipy-user at scipy.net>
Sent: Monday, December 16, 2002 6:25 PM
Subject: RE: [SciPy-user] Accessing modules in packages


> Hey Dave,
>
> I'm not sure what is going on.  The following works for me:
>
> H:\tmp>python
> Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from scipy.cluster.vq import *
> >>> kmeans
> <function kmeans at 0x01BF36E8>
>
> as does:
>
> H:\tmp>python
> Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from scipy.cluster import vq
> >>> vq.kmeans
> <function kmeans at 0x01BF3FC0>
>
> Do these same commands fail for you?
>
> Regards,
> eric
>
> ----------------------------------------------
> eric jones                    515 Congress Ave
> www.enthought.com             Suite 1614
> 512 536-1057                  Austin, Tx 78701
>
>
> > -----Original Message-----
> > From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
> On
> > Behalf Of Dave Bazell
> > Sent: Monday, December 16, 2002 2:09 PM
> > To: scipy-user at scipy.net
> > Subject: [SciPy-user] Accessing modules in packages
> >
> > I am trying to use scipy.cluster.vq.kmeans.  I have imported scipy:
> >
> > > import scipy
> >
> > and tried cluster.vq.kmeans(..) but I get an error "no module vq in
> > cluster"
> > or something like that.
> >
> > I have tried
> >
> > from scipy import *
> > from scipy.cluster import *
> >
> > and
> >
> > from scipy.cluster.vq import *
> >
> > but none of these allow me to access cluster.vq.kmeans.
> >
> > If I copy the vq.py file to my working directory and do
> >
> > import vq
> >
> > then I can access it.
> >
> > What am I doing wrong?  I am sure this is a simple thing to answer and
> > displays my current (but decreasing) ignorance of python.
> >
> > Thanks,
> >
> > Dave Bazell
> >
> >
> >
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
>
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user




From staelin at exch.hpl.hp.com  Tue Dec 17 07:53:22 2002
From: staelin at exch.hpl.hp.com (Staelin, Carl)
Date: Tue, 17 Dec 2002 04:53:22 -0800
Subject: [SciPy-user] buglets in stats/morestats.py
Message-ID: <40700B4C02ABD5119F00009027876644045C1751@hplex1.hpl.hp.com>

There are a number of buglets in stats/morestats.py
which make the routine wilcoxon unusable.  I have
attached a patch, which can be integrated by:
	cd scipy/stats
	patch < morestats.diff

If you have any questions or concerns, please do not
hesitate to contact me.

Cheers,

Carl

 <<morestats.diff>> 

_________________________________________________
[(hp)]	Carl Staelin
	Senior Research Scientist
	Hewlett-Packard Laboratories
	Technion City
	Haifa, 32000
	ISRAEL
	+972(4)823-1237x221	+972(4)822-0407 fax
	staelin at hpl.hp.com
_______http://www.hpl.hp.com/personal/Carl_Staelin_______

-------------- next part --------------
A non-text attachment was scrubbed...
Name: morestats.diff
Type: application/octet-stream
Size: 845 bytes
Desc: not available
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20021217/88bcb0fd/attachment.obj>

From pearu at cens.ioc.ee  Tue Dec 17 08:20:58 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 17 Dec 2002 15:20:58 +0200 (EET)
Subject: [SciPy-user] Undefined symbol problems (flapack/min and
 clapack/clapack_sgetri)
In-Reply-To: <Pine.LNX.4.44.0212161715170.2619-100000@datamat.colorado.edu>
Message-ID: <Pine.LNX.4.21.0212171514550.30697-100000@cens.kybi>

On Mon, 16 Dec 2002, Fernando Perez wrote:

> Hi all,
> 
> I'm trying to install the SciPy-0.2.0_alpha_144.4350_src.tar.gz to bring 
> my scipy installation up to date. I successfully installed it but I'm 
> getting two import errors:
> 
> In [1]: import scipy.linalg.flapack
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call 
> last)
> 
> ?
> 
> ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/flapack.so: 
> undefined symbol: min

I recently fixed this one in SciPy CVS.
See

http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin/viewcvsx.cgi/scipy/linalg/generic_flapack.pyf.diff%3Fr1%3D1.4%26r2%3D1.5

for diff.

> In [2]: import scipy.linalg.clapack
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call 
> last)
> 
> ?
> 
> ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: 
> undefined symbol: clapack_sgetri
> 
> Any ideas?

Try ldd on clapack.so, see if it picks up the right atlas libraries.

Pearu



From Ralf_Ahlbrink at web.de  Tue Dec 17 10:51:44 2002
From: Ralf_Ahlbrink at web.de (RA)
Date: Tue, 17 Dec 2002 16:51:44 +0100
Subject: [SciPy-user] new Mandrake Source RPMs
Message-ID: <200212171651.44524.Ralf_Ahlbrink@web.de>

I've updated some files linked on
<http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/index_html/view>
(see list below).

Now, weave is included as a seperate package (it depends on 
python-scipy-core). I've only added the date of the cvs version,
because I couldn't find any related version number like in 
scipy/__cvs__version_.py. Please give me a hint or change 
setup_weave.py ...

Chako has remained as a ToDo.

Ralf.


###

http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-f2py-2.32.225.1419-1ra.src.rpm
http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-weave-0.3.0.alpha021212-1ra.src.rpm
http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-scipy-core-0.2.0_alpha_4.265-1ra.src.rpm
http://www.scipy.org/Members/RalfA/packages/Mandrake-9.0-RPM/python-scipy-0.2.0_alpha_152.4462-1ra.src.rpm



From eric at enthought.com  Tue Dec 17 11:29:06 2002
From: eric at enthought.com (eric jones)
Date: Tue, 17 Dec 2002 10:29:06 -0600
Subject: [SciPy-user] Accessing modules in packages
In-Reply-To: <000701c2a5c9$f65b3fe0$6401a8c0@DB>
Message-ID: <015a01c2a5e9$6e05ebc0$8901a8c0@ERICDESKTOP>

We should add the __all__ statement -- I'll do it.

Also, I'd be interested in feedback on the vq stuff.  As far as I know,
I'm the only one who has used it much -- and only for one application.
Ideas about how to make it more flexible for other people's problems are
welcome.


Thanks,
eric

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of Dave Bazell
> Sent: Tuesday, December 17, 2002 6:44 AM
> To: scipy-user at scipy.net
> Subject: Re: [SciPy-user] Accessing modules in packages
> 
> OK, I got it.  I have been doing:
> 
> >>> from scipy.cluster import *
> >>> vq.kmeans
>         traceback...
>         vq not defines...
> 
> There is no __all__ list defined in cluster/__init__.py so my
statement
> does
> not import vq.  I can import * from the vq package or explicitly
import vq
> from the cluster package and get to kmeans.
> 
> Thanks,
> 
> Dave
> ----- Original Message -----
> From: "eric jones" <eric at enthought.com>
> To: <scipy-user at scipy.net>
> Sent: Monday, December 16, 2002 6:25 PM
> Subject: RE: [SciPy-user] Accessing modules in packages
> 
> 
> > Hey Dave,
> >
> > I'm not sure what is going on.  The following works for me:
> >
> > H:\tmp>python
> > Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on
win32
> > Type "help", "copyright", "credits" or "license" for more
information.
> > >>> from scipy.cluster.vq import *
> > >>> kmeans
> > <function kmeans at 0x01BF36E8>
> >
> > as does:
> >
> > H:\tmp>python
> > Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on
win32
> > Type "help", "copyright", "credits" or "license" for more
information.
> > >>> from scipy.cluster import vq
> > >>> vq.kmeans
> > <function kmeans at 0x01BF3FC0>
> >
> > Do these same commands fail for you?
> >
> > Regards,
> > eric
> >
> > ----------------------------------------------
> > eric jones                    515 Congress Ave
> > www.enthought.com             Suite 1614
> > 512 536-1057                  Austin, Tx 78701
> >
> >
> > > -----Original Message-----
> > > From: scipy-user-admin at scipy.net
[mailto:scipy-user-admin at scipy.net]
> > On
> > > Behalf Of Dave Bazell
> > > Sent: Monday, December 16, 2002 2:09 PM
> > > To: scipy-user at scipy.net
> > > Subject: [SciPy-user] Accessing modules in packages
> > >
> > > I am trying to use scipy.cluster.vq.kmeans.  I have imported
scipy:
> > >
> > > > import scipy
> > >
> > > and tried cluster.vq.kmeans(..) but I get an error "no module vq
in
> > > cluster"
> > > or something like that.
> > >
> > > I have tried
> > >
> > > from scipy import *
> > > from scipy.cluster import *
> > >
> > > and
> > >
> > > from scipy.cluster.vq import *
> > >
> > > but none of these allow me to access cluster.vq.kmeans.
> > >
> > > If I copy the vq.py file to my working directory and do
> > >
> > > import vq
> > >
> > > then I can access it.
> > >
> > > What am I doing wrong?  I am sure this is a simple thing to answer
and
> > > displays my current (but decreasing) ignorance of python.
> > >
> > > Thanks,
> > >
> > > Dave Bazell
> > >
> > >
> > >
> > > _______________________________________________
> > > SciPy-user mailing list
> > > SciPy-user at scipy.net
> > > http://www.scipy.net/mailman/listinfo/scipy-user
> >
> >
> >
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
> 
> 
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user





From oliphant at ee.byu.edu  Tue Dec 17 12:15:33 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 17 Dec 2002 10:15:33 -0700 (MST)
Subject: [SciPy-user] buglets in stats/morestats.py
In-Reply-To: <40700B4C02ABD5119F00009027876644045C1751@hplex1.hpl.hp.com>
Message-ID: <Pine.LNX.4.33L2.0212171014510.25954-100000@oliphant.ee.byu.edu>

> There are a number of buglets in stats/morestats.py
> which make the routine wilcoxon unusable.  I have
> attached a patch, which can be integrated by:

Thank you for your help.  This module has not been well tested and your
assistance is greatly appreciated.

-Travis O.



Assistant Professor
459 CB
Electrical and Computer Engineering
Brigham Young University
Provo, UT 84602
Tel: (801) 422-3108
oliphant.travis at ieee.org



From bazell at comcast.net  Tue Dec 17 12:29:08 2002
From: bazell at comcast.net (Dave Bazell)
Date: Tue, 17 Dec 2002 12:29:08 -0500
Subject: [SciPy-user] Accessing modules in packages
References: <015a01c2a5e9$6e05ebc0$8901a8c0@ERICDESKTOP>
Message-ID: <000701c2a5f1$ce255650$6401a8c0@DB>


> We should add the __all__ statement -- I'll do it.
OK, sounds reasonable.

>
> Also, I'd be interested in feedback on the vq stuff.  As far as I know,
> I'm the only one who has used it much -- and only for one application.
> Ideas about how to make it more flexible for other people's problems are
> welcome.
>
I am working on a project involving clustering of astronomical data.  I will
test it out over the next few weeks.  I also plan to add some additional
functionality to the clustering for my own project.  I assume this can be
incorporated into scipy if it meets the standards, which are published on
the scipy website.

>
> Thanks,
> eric
Thank you,
Dave




From eric at enthought.com  Tue Dec 17 12:35:47 2002
From: eric at enthought.com (eric jones)
Date: Tue, 17 Dec 2002 11:35:47 -0600
Subject: [SciPy-user] Accessing modules in packages
In-Reply-To: <000701c2a5f1$ce255650$6401a8c0@DB>
Message-ID: <016e01c2a5f2$bed2cd30$8901a8c0@ERICDESKTOP>

> 
> > We should add the __all__ statement -- I'll do it.
> OK, sounds reasonable.

Done.

> >
> > Also, I'd be interested in feedback on the vq stuff.  As far as I
know,
> > I'm the only one who has used it much -- and only for one
application.
> > Ideas about how to make it more flexible for other people's problems
are
> > welcome.
> >
> I am working on a project involving clustering of astronomical data.
I
> will
> test it out over the next few weeks.  I also plan to add some
additional
> functionality to the clustering for my own project.  I assume this can
be
> incorporated into scipy if it meets the standards, which are published
on
> the scipy website.

Absolutely.  I look forward to your submissions.

Thanks,
eric




From costasm at hotmail.com  Tue Dec 17 13:08:24 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Tue, 17 Dec 2002 18:08:24 +0000
Subject: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
Message-ID: <BAY1-F212xFQp9jo6BG00015af9@hotmail.com>

Well, I need this to build a complicated prototype --I need Sparse to work, 
but not that well; if the prototype works, then things will change :-)

I've tried two different approaches:
1) Tried to compile SciPy CVS on current Cygwin (gcc 3.2, python 2.2.1).  I 
got ATLAS and LAPACK and all of SciPy compiling fine, but not sparse.  I 
worked around the last error I posted on this list, but then I run into 
symbol issues and gave up.

2) I've now tried to compile SciPy CVS using gcc-mingw as specified on the 
website.  I am running into the issue that my ATLAS and LAPACK are linked 
against another python (Cygwin's 2.2.1, whereas I am running 2.1 win32 on my 
box for another project).  I downloaded pre-built ATLAS but I don't know if 
this will work, since it's probably built with another compiler (are there 
any ABI issues w/ ATLAS??; I am guessing not, but I'd like to be sure)

If I go with (2), can I use pre-built ATLAS and LAPACK?

Also, how did you compile sparse on Linux? with its makefile (which looks a 
bit out-of-date) or with setup_sparse.py?

Thanks for all your help,

Costas



>From: Travis Oliphant <oliphant.travis at ieee.org>
>To: Costas Malamas <costasm at hotmail.com>
>Subject: Re: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
>Date: 16 Dec 2002 22:32:50 -0700
>
>On Mon, 2002-12-16 at 14:58, Costas Malamas wrote:
> > Travis,
> >
> > I have tried my best to get scipy/sparse to compile.  Can you point me 
>to
> > which version is compiling for you? on what OS?  How (makefile or
> > setup_sparse.py)?
> >
>
>I'm sorry I haven't been able to help you more. I would like to see
>sparse work more reliably, but I have not had the time to make it
>happen.
>
>I use Mandrake-9.0 (it worked on 8.2 too) which uses gcc 3.2  and
>python2.2
>
>When I saw "worked" I mean it compiled and loaded in python.  There is
>no doubt a few bugs.
>
>I just checked it again and it is compiling and loading for me.  Can you
>isolate your problem?  Did you check the CVS version of SciPy out?
>
>
>Good luck,
>
>-Travis


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



From oliphant at ee.byu.edu  Tue Dec 17 14:49:16 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 17 Dec 2002 12:49:16 -0700 (MST)
Subject: [SciPy-user] Sparse Matrices (SciPy or elsewhere)?
In-Reply-To: <BAY1-F212xFQp9jo6BG00015af9@hotmail.com>
Message-ID: <Pine.LNX.4.33L2.0212171246140.26818-100000@oliphant.ee.byu.edu>

>
> Well, I need this to build a complicated prototype --I need Sparse to work,
> but not that well; if the prototype works, then things will change :-)

It does work, but features may be missing.

> 2) I've now tried to compile SciPy CVS using gcc-mingw as specified on the
> website.  I am running into the issue that my ATLAS and LAPACK are linked
> against another python (Cygwin's 2.2.1, whereas I am running 2.1 win32 on my
> box for another project).  I downloaded pre-built ATLAS but I don't know if
> this will work, since it's probably built with another compiler (are there
> any ABI issues w/ ATLAS??; I am guessing not, but I'd like to be sure)
>

I don't think there are, because ATLAS is usually statically linked.  But,
I'm the wrong person to ask.

> If I go with (2), can I use pre-built ATLAS and LAPACK?

I think so.  Can somebody with windows experience comment here?

>
> Also, how did you compile sparse on Linux? with its makefile (which looks a
> bit out-of-date) or with setup_sparse.py?

I set build_sparse=1 (currently it is set to 0),  in the main setup.py
file and then it goes off and uses the setup_sparse.py file.  I've never
actually tried to install it using just setup_sparse.py though it should probably work.

-Travis





From fperez at pizero.colorado.edu  Tue Dec 17 15:38:50 2002
From: fperez at pizero.colorado.edu (Fernando Perez)
Date: Tue, 17 Dec 2002 13:38:50 -0700 (MST)
Subject: [SciPy-user] Undefined symbol problems (flapack/min and
 clapack/clapack_sgetri)
In-Reply-To: <Pine.LNX.4.21.0212171514550.30697-100000@cens.kybi>
Message-ID: <Pine.LNX.4.44.0212171336080.7617-100000@datamat.colorado.edu>

On Tue, 17 Dec 2002, Pearu Peterson wrote:

> 
> On Mon, 16 Dec 2002, Fernando Perez wrote:
> 
> > Hi all,
> > 
> > I'm trying to install the SciPy-0.2.0_alpha_144.4350_src.tar.gz to bring 
> > my scipy installation up to date. I successfully installed it but I'm 
> > getting two import errors:
> > 
> > In [1]: import scipy.linalg.flapack
> > 
> > ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/flapack.so: 
> > undefined symbol: min
> 
> I recently fixed this one in SciPy CVS.
> See
> 
> http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin/viewcvsx.cgi/scipy/linalg/generic_flapack.pyf.diff%3Fr1%3D1.4%26r2%3D1.5
> 
> for diff.
> 
> > In [2]: import scipy.linalg.clapack
> > ImportError: /usr/lib/python2.2/site-packages/scipy/linalg/clapack.so: 
> > undefined symbol: clapack_sgetri

Thanks! Using SciPy from CVS cured both problems. I'd forgotten that with 
Scipy's current state of constant evolution, it's really not a good idea 
to rely on outdated tarballs.

Best regards,

Fernando.



From dhumphrey at bellgeo.com  Wed Dec 18 19:04:49 2002
From: dhumphrey at bellgeo.com (David Humphrey)
Date: Wed, 18 Dec 2002 18:04:49 -0600
Subject: [SciPy-user] wxWindow_GetClientSizeTuple problem using plt.plot
Message-ID: <E6C942BEA012D6119F020008C756CDF579E2@ENTERPRISE.BELLGEO.COM>

Yesterday, I installed

SciPy-0.2.0_alpha_144.4350_src.tar.gz
wxPython 2.3.3.1 for Python 2.2
wxWindows 2.2.9
Numeric 22.0

I've had Python 2.2.1 from www.python.org installed for several weeks.

On a Windows NT 4.0 SP6a machine.  I spent some time getting used to SciPy
as I have some prior experience with each of the other packages.  At the
moment, I'm interested in plt.plot().  While I've been able to get a few
simple 2-D plots to work, I'm having a proble with the following code
residing in the file test2.py:

import gui_thread
from Numeric import *
from scipy import plt
from scipy import *

binz = array([-162., -126., -90., -54., -18.,  18.,  54.,  90., 126.,
162.],Float)
countz = array([ 9006, 1621, 26248,  2912,  7096,  8537,  1533, 22517,
1224,  6563],Float)
plt.plot(binz,countz)

When I execute this script, I get the following results:

$ python test2.py
<wxPython imported>
>>>
Traceback (most recent call last):
  File "D:\Utils\Python22\Lib\site-packages\scipy\plt\wxplt.py", line 143,
in on_paint
    self.draw(wx.wxPaintDC(self))
  File "D:\Utils\Python22\Lib\site-packages\scipy\plt\wxplt.py", line 411,
in draw
    t1 = time.clock();self.reset_size(dc);t2 = time.clock()
  File "D:\Utils\Python22\Lib\site-packages\scipy\plt\wxplt.py", line 357,
in reset_size
    new_size = self.GetClientSizeTuple()
  File "d:\Utils\Python22\lib\site-packages\wxPython\windows.py", line 194,
in GetClientSizeTuple
    val = apply(windowsc.wxWindow_GetClientSizeTuple,(self,) + _args,
_kwargs)
AttributeError: 'NoneType' object has no attribute
'wxWindow_GetClientSizeTuple'
17:52:44: Debug: c:\projects\wx\src\msw\app.cpp(439):
'UnregisterClass(canvas)' failed with error 0x00000584 (class still has open
windows.).
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method wxPaintDC.__del__ of <C wxPaintDC instance at
_274db50_wxPaintDC_p>> ignored

Can anyone tell me what I'm doing wrong?

Regards,
David Humphrey
Director, Technical Services
Bell Geospace, Inc


From costasm at hotmail.com  Thu Dec 19 03:48:34 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Thu, 19 Dec 2002 08:48:34 +0000
Subject: [SciPy-user] Sparse Compilation Issues (again)
Message-ID: <BAY1-F99LZZxCZPs6Av00017900@hotmail.com>

I've been trying to compile sparse on win32 to no avail.  I tried both 
mingw32 with pre-built ATLAS and LAPACK and Cygwin, both with the Scipy CVS. 
  Both setups work OK (well, cluster also fails on Cygwin, but I took it 
out), and they crash more-or-less with the same error ("parse error before 
numeric constant", below).  Extensive Googling shows that this means a 
numeric constant is already used somewhere else, but I got no solution to 
work around it...

Ideas?

Thanks,

Costas


gcc -shared -Wl,--enable-auto-image-base 
build/temp.cygwin-1.3.17-i686-2.2/convo
lve.o build/temp.cygwin-1.3.17-i686-2.2/fortranobject.o 
build/temp.cygwin-1.3.17
-i686-2.2/convolvemodule.o -Lbuild/temp.cygwin-1.3.17-i686-2.2 
-L/usr/lib/python
2.2/config -Lbuild/temp.cygwin-1.3.17-i686-2.2 -ldfftpack -lpython2.2 
-lc_misc -
lcephes -lrootfind -lsuperlu -lmyblas -lg2c -o 
build/lib.cygwin-1.3.17-i686-2.2/
scipy/fftpack/convolve.dll
building 'scipy.sparse._zsuperlu' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT 
-I/usr/include/pyt
hon2.2 -c /d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c -o 
build/temp.
cygwin-1.3.17-i686-2.2/_zsuperlumodule.o
In file included from 
/d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/zsp_defs
.h:23,
                 from 
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:26
:
/d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/supermatrix.h:19: parse 
error
before numeric constant
/d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/supermatrix.h:21: parse 
error
before numeric constant
In file included from 
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:27
:
/d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/util.h:95: warning: 
function d
eclaration isn't a prototype
/d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/util.h:101: warning: 
function
declaration isn't a prototype
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c: In function 
`NRFormat_f
rom_spMatrix':
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:46: warning: 
implicit de
claration of function `zCreate_CompRow_Matrix'
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c: In function 
`Py_zgssv':

/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:163: warning: 
implicit d
eclaration of function `superlu_delete_allkeys'
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c: At top level:
/d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:190: warning: 
function d
eclaration isn't a prototype
error: command 'gcc' failed with exit status 1


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



From oliphant.travis at ieee.org  Thu Dec 19 10:14:10 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 19 Dec 2002 08:14:10 -0700
Subject: [SciPy-user] Sparse Compilation Issues (again)
In-Reply-To: <BAY1-F99LZZxCZPs6Av00017900@hotmail.com>
References: <BAY1-F99LZZxCZPs6Av00017900@hotmail.com>
Message-ID: <1040310851.21624.6.camel@travis.local.net>

On Thu, 2002-12-19 at 01:48, Costas Malamas wrote:
> 
> I've been trying to compile sparse on win32 to no avail.  I tried both 
> mingw32 with pre-built ATLAS and LAPACK and Cygwin, both with the Scipy CVS. 
>   Both setups work OK (well, cluster also fails on Cygwin, but I took it 
> out), and they crash more-or-less with the same error ("parse error before 
> numeric constant", below).  Extensive Googling shows that this means a 
> numeric constant is already used somewhere else, but I got no solution to 
> work around it...
> 
> Ideas?
> 
> Thanks,
> 
> Costas
> 
> 
> gcc -shared -Wl,--enable-auto-image-base 
> build/temp.cygwin-1.3.17-i686-2.2/convo
> lve.o build/temp.cygwin-1.3.17-i686-2.2/fortranobject.o 
> build/temp.cygwin-1.3.17
> -i686-2.2/convolvemodule.o -Lbuild/temp.cygwin-1.3.17-i686-2.2 
> -L/usr/lib/python
> 2.2/config -Lbuild/temp.cygwin-1.3.17-i686-2.2 -ldfftpack -lpython2.2 
> -lc_misc -
> lcephes -lrootfind -lsuperlu -lmyblas -lg2c -o 
> build/lib.cygwin-1.3.17-i686-2.2/
> scipy/fftpack/convolve.dll
> building 'scipy.sparse._zsuperlu' extension
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT 
> -I/usr/include/pyt
> hon2.2 -c /d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c -o 
> build/temp.
> cygwin-1.3.17-i686-2.2/_zsuperlumodule.o
> In file included from 
> /d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/zsp_defs
> .h:23,
>                  from 
> /d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:26
> :
> /d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/supermatrix.h:19: parse 
> error
> before numeric constant
> /d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/supermatrix.h:21: parse 
> error
> before numeric constant


Are you sure you have the correct CVS files?  This is odd for there to
be a parse error in SuperLU.  Did you modify this file somehow or not
get a complete checkout.

You could erase this file and check it out again.  You might try that
for that whole SuperLU directory.

Good luck,

-Travis




From costasm at hotmail.com  Thu Dec 19 13:44:54 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Thu, 19 Dec 2002 18:44:54 +0000
Subject: [SciPy-user] Sparse Compilation Issues (again)
Message-ID: <BAY1-F133M6A8LYxENr000183c3@hotmail.com>

Nope, straight checkout from CVS.  I had the same thought as you, so I 
checked it out twice with the same results.  I also looked for SuperLU 
itself, but the only version I found out there was 2.0 which (surprise) 
doesnt compile with sparse (I think it's bundled with 1.2?)...

Another question that's been bugging me now that I've been staring at 
sparse's source code... it looks to me like it's just a sparse matrix 
equation solver.  I will need to instantiate very large "cubes", say 
1e3x1e3x1e4, with low population densities (max around 20%, typically 
5-10%).  This 1e10 cube doesn't even allocate in Numpy/Scipy (smaller cubes 
actually crash my Win2K laptop), so I was _hoping_ that scipy.sparse would 
implement a "default value" array: i.e. the operation:
x = zeros([1e3,1e3,1e3])

would be instantaneous as x would be an empty "shell" with 0 as it's default 
value.  However, I don't see a capability like that in scipy.sparse's source 
code though.  Am I missing it?  is there anything like this for SciPy/NumPy?

Thanks for all your help,

Costas





>From: Travis Oliphant <oliphant.travis at ieee.org>
>Reply-To: scipy-user at scipy.net
>To: scipy-user at scipy.net
>Subject: Re: [SciPy-user] Sparse Compilation Issues (again)
>Date: 19 Dec 2002 08:14:10 -0700
>
>On Thu, 2002-12-19 at 01:48, Costas Malamas wrote:
> >
> > I've been trying to compile sparse on win32 to no avail.  I tried both
> > mingw32 with pre-built ATLAS and LAPACK and Cygwin, both with the Scipy 
>CVS.
> >   Both setups work OK (well, cluster also fails on Cygwin, but I took it
> > out), and they crash more-or-less with the same error ("parse error 
>before
> > numeric constant", below).  Extensive Googling shows that this means a
> > numeric constant is already used somewhere else, but I got no solution 
>to
> > work around it...
> >
> > Ideas?
> >
> > Thanks,
> >
> > Costas
> >
> >
> > gcc -shared -Wl,--enable-auto-image-base
> > build/temp.cygwin-1.3.17-i686-2.2/convo
> > lve.o build/temp.cygwin-1.3.17-i686-2.2/fortranobject.o
> > build/temp.cygwin-1.3.17
> > -i686-2.2/convolvemodule.o -Lbuild/temp.cygwin-1.3.17-i686-2.2
> > -L/usr/lib/python
> > 2.2/config -Lbuild/temp.cygwin-1.3.17-i686-2.2 -ldfftpack -lpython2.2
> > -lc_misc -
> > lcephes -lrootfind -lsuperlu -lmyblas -lg2c -o
> > build/lib.cygwin-1.3.17-i686-2.2/
> > scipy/fftpack/convolve.dll
> > building 'scipy.sparse._zsuperlu' extension
> > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT
> > -I/usr/include/pyt
> > hon2.2 -c /d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c -o
> > build/temp.
> > cygwin-1.3.17-i686-2.2/_zsuperlumodule.o
> > In file included from
> > /d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/zsp_defs
> > .h:23,
> >                  from
> > /d/Projects/scipy/scipy_cygwin/sparse/_zsuperlumodule.c:26
> > :
> > /d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/supermatrix.h:19: 
>parse
> > error
> > before numeric constant
> > /d/Projects/scipy/scipy_cygwin/sparse/SuperLU/SRC/supermatrix.h:21: 
>parse
> > error
> > before numeric constant
>
>
>Are you sure you have the correct CVS files?  This is odd for there to
>be a parse error in SuperLU.  Did you modify this file somehow or not
>get a complete checkout.
>
>You could erase this file and check it out again.  You might try that
>for that whole SuperLU directory.
>
>Good luck,
>
>-Travis
>
>
>_______________________________________________
>SciPy-user mailing list
>SciPy-user at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-user


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



From oliphant at ee.byu.edu  Thu Dec 19 14:37:48 2002
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 19 Dec 2002 12:37:48 -0700 (MST)
Subject: [SciPy-user] Sparse Compilation Issues (again)
In-Reply-To: <BAY1-F133M6A8LYxENr000183c3@hotmail.com>
Message-ID: <Pine.LNX.4.33L2.0212191232360.19865-100000@oliphant.ee.byu.edu>

>
> Nope, straight checkout from CVS.  I had the same thought as you, so I
> checked it out twice with the same results.  I also looked for SuperLU
> itself, but the only version I found out there was 2.0 which (surprise)
> doesnt compile with sparse (I think it's bundled with 1.2?)...
>

I remember upgrading SuperLU to version 2.0 just a couple of months ago.
Is the CVS version not 2.0?  Let me check into that.

> Another question that's been bugging me now that I've been staring at
> sparse's source code... it looks to me like it's just a sparse matrix
> equation solver.  I will need to instantiate very large "cubes", say
> 1e3x1e3x1e4, with low population densities (max around 20%, typically
> 5-10%).  This 1e10 cube doesn't even allocate in Numpy/Scipy (smaller cubes
> actually crash my Win2K laptop), so I was _hoping_ that scipy.sparse would
> implement a "default value" array: i.e. the operation:
> x = zeros([1e3,1e3,1e3])

Ahh.  You want something else then.  Sparse is not a sparse array, it is
only a sparse matrix.   Sparse matrices have been well studied and there
are many good storage mechanisms and algorithms using them.

Sparse arrays, on the other hand are usually just implemented as
dictionaries.   I know of no sparse array implementation for any
array-oriented environment.  You could make your own without too much
difficulty, supporting just the operations you care about.

Which operations do you want to do on these "sparse arrays"?

Really, the sparse matrix module in SciPy does not give you much if what
you really want is sparse arrays.

I'd love to hear of any successes you have in this.

-Travis






From costasm at hotmail.com  Thu Dec 19 16:39:58 2002
From: costasm at hotmail.com (Costas Malamas)
Date: Thu, 19 Dec 2002 21:39:58 +0000
Subject: [SciPy-user] Sparse Compilation Issues (again)
Message-ID: <BAY1-F862cpT788bsUZ00018d6d@hotmail.com>

>Ahh.  You want something else then.  Sparse is not a sparse array, it is
>only a sparse matrix.   Sparse matrices have been well studied and there
>are many good storage mechanisms and algorithms using them.
>
>Sparse arrays, on the other hand are usually just implemented as
>dictionaries.   I know of no sparse array implementation for any
>array-oriented environment.  You could make your own without too much
>difficulty, supporting just the operations you care about.
>
>Which operations do you want to do on these "sparse arrays"?
>
Well, pretty much everything NumPy supplies --array arithmetic and inner 
products at least.  I am looking for a quick way to a prototype, a cleaner 
solution will have to wait.

I did find a pure-python implementation of just what you described: 
dict-based sparse array, but I doubt that a python dictionary could handle 
1e9 members in a reasonable amount of time.

I took a look at NumPy's arrayobject.c; as I said, my C is rusty but it 
looks simple enough to create a default-value array that "looks" like a 
NumPy array...

Thanks again,

Costas


_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail



From joruanaidh at genuone.com  Mon Dec 23 11:56:36 2002
From: joruanaidh at genuone.com (Joseph O'Ruanaidh)
Date: Mon, 23 Dec 2002 11:56:36 -0500
Subject: [SciPy-user] warning: compilation failed. Executing as python code
Message-ID: <3E074044.7070409@genuone.com>

warning: compilation failed. Executing as python code

I am getting this message when running scipy.test_all()
under Redhat 7.1.

Has this anyhing to do with the crappy  compiler?
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)

Joe
2nd run(Numeric,compiled,speed up):  1.3802, 18.1977, 0.0758
......................................................................................
----------------------------------------------------------------------
Ran 188 tests in 691.652s

OK
 >>>
P.S.

results:




From yann.ledu at noos.fr  Sat Dec 28 21:32:05 2002
From: yann.ledu at noos.fr (Yann Le Du)
Date: Sun, 29 Dec 2002 03:32:05 +0100 (CET)
Subject: [SciPy-user] Using the mouse in gplt ?
Message-ID: <Pine.LNX.4.44.0212290325120.2145-100000@neuron.noos.fr>

Hello,

I have gnuplot installed, that I use outside of SciPy with the mouse 
enabled (I can click inside the gnuplot frame and do things like zoom, 
rotate, etc). But when I use it through SciPy, the mouse is not enabled. 
Does anyone know how to enable the mouse in gplt plot windows ?

Yann



From baecker at physik.tu-dresden.de  Sun Dec 29 13:17:17 2002
From: baecker at physik.tu-dresden.de (baecker at physik.tu-dresden.de)
Date: Sun, 29 Dec 2002 19:17:17 +0100 (CET)
Subject: [SciPy-user] Using the mouse in gplt ?
In-Reply-To: <Pine.LNX.4.44.0212290325120.2145-100000@neuron.noos.fr>
References: <Pine.LNX.4.44.0212290325120.2145-100000@neuron.noos.fr>
Message-ID: <Pine.LNX.4.51.0212291911530.15289@ptpcp2.phy.tu-dresden.de>

Hi,

to answer your question partially: you have to issue
the command "set mouse" to gnuplot (as first command you send to gnuplot).
However, I don't know how to do this within scipy.plt.

Alternatively, you might consider IPython,
  http://www-hep.colorado.edu/~fperez/ipython/
which I would highly recommend for interactive work.
Just start it with the numeric profile,
  ipython -profile numeric
and then at the prompt do (for example)
  g("plot sin(x)")

Arnd



On Sun, 29 Dec 2002, Yann Le Du wrote:

> Hello,
>
> I have gnuplot installed, that I use outside of SciPy with the mouse
> enabled (I can click inside the gnuplot frame and do things like zoom,
> rotate, etc). But when I use it through SciPy, the mouse is not enabled.
> Does anyone know how to enable the mouse in gplt plot windows ?
>
> Yann
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>


From eric at enthought.com  Sun Dec 29 15:49:14 2002
From: eric at enthought.com (eric jones)
Date: Sun, 29 Dec 2002 14:49:14 -0600
Subject: [SciPy-user] Using the mouse in gplt ?
In-Reply-To: <Pine.LNX.4.51.0212291911530.15289@ptpcp2.phy.tu-dresden.de>
Message-ID: <000001c2af7b$bf4c44c0$8901a8c0@ERICDESKTOP>

You can send raw gnuplot commands to a plot object like so:

>>> from scipy import gplt
>>> gplt.plot((1,2,3))
>>> q=gplt.current()
>>> q
<scipy.gplt.new_plot.Plot instance at 0x01BE0A80>
>>> q._send('set mouse;')

eric

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 


> -----Original Message-----
> From: scipy-user-admin at scipy.net [mailto:scipy-user-admin at scipy.net]
On
> Behalf Of baecker at physik.tu-dresden.de
> Sent: Sunday, December 29, 2002 12:17 PM
> To: SciPy User
> Subject: Re: [SciPy-user] Using the mouse in gplt ?
> 
> Hi,
> 
> to answer your question partially: you have to issue
> the command "set mouse" to gnuplot (as first command you send to
gnuplot).
> However, I don't know how to do this within scipy.plt.
> 
> Alternatively, you might consider IPython,
>   http://www-hep.colorado.edu/~fperez/ipython/
> which I would highly recommend for interactive work.
> Just start it with the numeric profile,
>   ipython -profile numeric
> and then at the prompt do (for example)
>   g("plot sin(x)")
> 
> Arnd
> 
> 
> 
> On Sun, 29 Dec 2002, Yann Le Du wrote:
> 
> > Hello,
> >
> > I have gnuplot installed, that I use outside of SciPy with the mouse
> > enabled (I can click inside the gnuplot frame and do things like
zoom,
> > rotate, etc). But when I use it through SciPy, the mouse is not
enabled.
> > Does anyone know how to enable the mouse in gplt plot windows ?
> >
> > Yann
> >
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-user
> >
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user





From loo_yee at 263.net  Mon Dec 30 02:46:50 2002
From: loo_yee at 263.net (loo yee)
Date: Mon, 30 Dec 2002 15:46:50 +0800
Subject: [SciPy-user] Help:Why Can not import scipy?
Message-ID: <00d301c2afd7$9f469e30$0f00a8c0@N15>

I installed Python 2.2,Numeric 22.0, Numarray 0.4, wyPython 2.3.4.2u
and my OS is WinXP, scipy version is 0.2.0_alpha_152.4463

But when I import scipy in PythonWin 2.2.1,there is an error

>>> import gui_thread
>>> <wxPython imported>
>>> from scipy import *
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\PYTHON22\Lib\site-packages\scipy\__init__.py", line 49, in ?
    import special, io, linalg, stats, fftpack
  File "C:\PYTHON22\Lib\site-packages\scipy\stats\__init__.py", line 195, in
?
    from stats import *
  File "C:\PYTHON22\Lib\site-packages\scipy\stats\stats.py", line 1500, in ?
    import distributions
  File "C:\PYTHON22\Lib\site-packages\scipy\stats\distributions.py", line
18, in ?
    from scipy_base import atleast_1d, polyval, angle, ceil, insert,
extract, \
ImportError: cannot import name insert
>>>

and when i import scipy in IDLE,there is another error:
>>> import gui_thread
>>> from scipy import *
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    from scipy import *
  File "C:\PYTHON22\Lib\site-packages\scipy\__init__.py", line 49, in ?
    import special, io, linalg, stats, fftpack
  File "C:\PYTHON22\Lib\site-packages\scipy\linalg\__init__.py", line 42, in
?
    from basic import *
  File "C:\PYTHON22\Lib\site-packages\scipy\linalg\basic.py", line 11, in ?
    from lapack import get_lapack_funcs
  File "C:\PYTHON22\Lib\site-packages\scipy\linalg\lapack.py", line 9, in ?
    from scipy_distutils.misc_util import PostponedException
ImportError: cannot import name PostponedException
>>>

What can i do?

Regards,

LuYi



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20021230/636360a1/attachment.html>