From jbaddor at physics.mcgill.ca  Fri Jun  2 10:18:34 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Fri, 2 Jun 2000 10:18:34 -0400 (EDT)
Subject: [Numpy-discussion] Is it a bug ?
Message-ID: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>

Hey Numeric people!

I am just upgrading to a more recent version of Numeric and observe a new
behaviour:

Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__
'11'
>>> Numeric.arange(2)*1j
Segmentation fault

Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__ 
'1.7'
>>> Numeric.arange(2)*1j
array([ 0.+0.j,  0.+1.j])

I also saw:
              Numerical Python - Bug Tracking
              Viewing Open Bugs
                Bug ID
                                           Summary
               102277
                     CFLOAT/DOUBLE_setitem crashes when accessing imag.
part 

Am I hitting that bug?

CU

Jean-Bernard




From ryszard at arqule.com  Fri Jun  2 11:32:49 2000
From: ryszard at arqule.com (Czerminski, Ryszard)
Date: Fri, 2 Jun 2000 11:32:49 -0400 
Subject: [Numpy-discussion] exp behaviour: is it a bug ?
Message-ID: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>

Is the behaviour illustrated below a bug
or the Python's feature ?

Python 1.5.2 (#4, Mar  3 2000, 15:04:36)  [GCC 2.8.1] on irix6
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>
>>> from math import exp
>>> x = -706.
>>> while x > -900:
...    x = x - 1
...    print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
x, exp(x) = -709 0
[...]
x, exp(x) = -745 0
Traceback (innermost last):
  File "<stdin>", line 3, in ?
OverflowError: math range error
>>>

Ryszard Czerminski   phone: (781)994-0479
ArQule, Inc.         email:ryszard at arqule.com
19 Presidential Way  http://www.arqule.com
Woburn, MA 01801     fax: (781)994-0679


-----Original Message-----
From: Jean-Bernard Addor [mailto:jbaddor at physics.mcgill.ca]
Sent: Friday, June 02, 2000 10:19 AM
To: Numpy-discussion at lists.sourceforge.net
Subject: [Numpy-discussion] Is it a bug ?


Hey Numeric people!

I am just upgrading to a more recent version of Numeric and observe a new
behaviour:

Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__
'11'
>>> Numeric.arange(2)*1j
Segmentation fault

Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__ 
'1.7'
>>> Numeric.arange(2)*1j
array([ 0.+0.j,  0.+1.j])

I also saw:
              Numerical Python - Bug Tracking
              Viewing Open Bugs
                Bug ID
                                           Summary
               102277
                     CFLOAT/DOUBLE_setitem crashes when accessing imag.
part 

Am I hitting that bug?

CU

Jean-Bernard


_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/numpy-discussion



From jsaenz at wm.lc.ehu.es  Fri Jun  2 11:49:52 2000
From: jsaenz at wm.lc.ehu.es (Jon Saenz)
Date: Fri, 2 Jun 2000 17:49:52 +0200 (MET DST)
Subject: [Numpy-discussion] exp behaviour: is it a bug ?
In-Reply-To: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>
Message-ID: <Pine.OSF.3.95.1000602174839.23124A-100000@lcdx00.wm.lc.ehu.es>

No, it works correctly for me (other Python revision, anyway):
Python 1.5.2 (#3, Sep 27 1999, 15:02:20)  [GCC egcs-2.91.66 19990314
(egcs-1.1.2
  on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from math import *
>>> x=-706.
>>> while x>-900:
...     x=x-1
...     print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
x, exp(x) = -709 1.21678e-308
.....
x, exp(x) = -898 0
x, exp(x) = -899 0
x, exp(x) = -900 0
>>>


Jon Saenz.				| Tfno: +34 946012470
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

On Fri, 2 Jun 2000, Czerminski, Ryszard wrote:

> 
> Is the behaviour illustrated below a bug
> or the Python's feature ?
> 
> Python 1.5.2 (#4, Mar  3 2000, 15:04:36)  [GCC 2.8.1] on irix6
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>>
> >>> from math import exp
> >>> x = -706.
> >>> while x > -900:
> ...    x = x - 1
> ...    print 'x, exp(x) = %g %g' % (x, exp(x))
> ... 
> x, exp(x) = -707 8.99086e-308
> x, exp(x) = -708 3.30755e-308
> x, exp(x) = -709 0
> [...]
> x, exp(x) = -745 0
> Traceback (innermost last):
>   File "<stdin>", line 3, in ?
> OverflowError: math range error
> >>>
> 
> Ryszard Czerminski   phone: (781)994-0479
> ArQule, Inc.         email:ryszard at arqule.com
> 19 Presidential Way  http://www.arqule.com
> Woburn, MA 01801     fax: (781)994-0679
> 
> 
> -----Original Message-----
> From: Jean-Bernard Addor [mailto:jbaddor at physics.mcgill.ca]
> Sent: Friday, June 02, 2000 10:19 AM
> To: Numpy-discussion at lists.sourceforge.net
> Subject: [Numpy-discussion] Is it a bug ?
> 
> 
> Hey Numeric people!
> 
> I am just upgrading to a more recent version of Numeric and observe a new
> behaviour:
> 
> Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
> on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Hello from .pythonrc.py
> >>> import Numeric
> >>> Numeric.__version__
> '11'
> >>> Numeric.arange(2)*1j
> Segmentation fault
> 
> Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Hello from .pythonrc.py
> >>> import Numeric
> >>> Numeric.__version__ 
> '1.7'
> >>> Numeric.arange(2)*1j
> array([ 0.+0.j,  0.+1.j])
> 
> I also saw:
>               Numerical Python - Bug Tracking
>               Viewing Open Bugs
>                 Bug ID
>                                            Summary
>                102277
>                      CFLOAT/DOUBLE_setitem crashes when accessing imag.
> part 
> 
> Am I hitting that bug?
> 
> CU
> 
> Jean-Bernard
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 




From cgw at fnal.gov  Fri Jun  2 11:59:37 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 2 Jun 2000 10:59:37 -0500 (CDT)
Subject: [Numpy-discussion] Is it a bug ?
In-Reply-To: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>
References: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>
Message-ID: <14647.55785.832702.542755@buffalo.fnal.gov>

Jean-Bernard Addor writes:
 > Hey Numeric people!
 > 
 > Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
 > on linux2
 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
 > Hello from .pythonrc.py
 > >>> import Numeric
 > >>> Numeric.__version__
 > '11'
 > >>> Numeric.arange(2)*1j
 > Segmentation fault
 > 

This seems to be fixed in the current CVS version.  I suggest you
either wait for the next release or grab the current version from CVS
if this is really a problem for you.

Python 1.6a2 (#9, May 22 2000, 12:34:51)  [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import Numeric
>>> Numeric.__version__
'15.2'
>>> Numeric.arange(2)*1j
array([ 0.+0.j,  0.+1.j])




From jbaddor at physics.mcgill.ca  Fri Jun  2 12:30:17 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Fri, 2 Jun 2000 12:30:17 -0400 (EDT)
Subject: [Numpy-discussion] (arange(2, typecode=Complex) % 2).typecode()
Message-ID: <Pine.LNX.3.96.1000602122425.1215C-100000@kili.physics.mcgill.ca>

Hey again!

Why is (arange(2, typecode=Complex) % 2).typecode() object and not
complex?

Jean-Bernard

Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> from Numeric import *
>>> (arange(2, typecode=Complex) % 2).typecode()
'O'
>>> arange(2, typecode=Complex) % 2
array([0j , (1+0j) ],'O')
>>> arange(2) % 2
array([0, 1])

I have the same result python 1.5.2 and Numeric 11.




From cgw at fnal.gov  Fri Jun  2 12:36:55 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 2 Jun 2000 11:36:55 -0500 (CDT)
Subject: [Numpy-discussion] math.exp underflow (was: exp behaviour: is it a bug ?)
In-Reply-To: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>
References: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>
Message-ID: <14647.58023.493846.225899@buffalo.fnal.gov>

Czerminski, Ryszard writes:
 > 
 > Is the behaviour illustrated below a bug or the Python's feature ?

I don't know why you're posting this to the NumPy discussion list,
since the
"math" module is part of the standard Python distribution, not NumPy.

Anyhow, the differing behaviors people are seeing are just coming from
differences in the system math libraries:

On Linux (Intel):

Python 1.6a2 (#9, May 22 2000, 12:34:51)  [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from math import exp
>>> x = -706.
>>> while x > -900:
...    x = x - 1
...    print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
<snip>
x, exp(x) = -745 4.94066e-324
x, exp(x) = -746 0
<snip>
x, exp(x) = -899 0
x, exp(x) = -900 0
>>> 


Wheras on Irix (MIPS):
Python 1.6a2 (#8, Jun  1 2000, 20:01:55) [C] on irix646
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from math import exp
>>> x = -706.
>>> while x > -900:
...    x = x - 1
...    print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
x, exp(x) = -709 0
x, exp(x) = -710 0
<snip>
x, exp(x) = -745 0
Traceback (most recent call last):
  File "<stdin>", line 3, in ?
OverflowError: math range error


>From the Irix man page for exp(3M):

     The exp functions return HUGE_VAL when the correct value would overflow,
     and return zero if the correct value would underflow. The -lm and -lmx
     versions set the value of errno to ERANGE for both underflow and
     overflow.

Since the Python math module sees errno set after the call to exp, it
raises an exception.

Whereas on Linux, exp(-very big number) simply returns 0 and does not
set errno.

On the one hand, Python's behavior makes sense because it simply
reflects the behavior of the system math libraries.  On the other
hand, these kinds of differences make it hard to write portable code -
you could test on Linux and think everything is OK, then run on IRIX
and get exceptions.  Maybe that's just the way life is when you are
using floating-point math... Tim Peters may have more to say on this
topic <exp(-900)wink>











From cgw at fnal.gov  Fri Jun  2 12:41:51 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 2 Jun 2000 11:41:51 -0500 (CDT)
Subject: [Numpy-discussion] (arange(2, typecode=Complex) % 2).typecode()
In-Reply-To: <Pine.LNX.3.96.1000602122425.1215C-100000@kili.physics.mcgill.ca>
References: <Pine.LNX.3.96.1000602122425.1215C-100000@kili.physics.mcgill.ca>
Message-ID: <14647.58319.400989.157163@buffalo.fnal.gov>

Jean-Bernard Addor writes:
 > Hey again!
 > 
 > Why is (arange(2, typecode=Complex) % 2).typecode() object and not
 > complex?

Looks like a bug to me!

>>> x=arange(2, typecode=Complex) 
>>> x
array([ 0.+0.j,  1.+0.j])
>>> x+10
array([ 10.+0.j,  11.+0.j])
>>> x*10
array([  0.+0.j,  10.+0.j])
>>> x/10
array([ 0. +0.j,  0.1+0.j])
>>> x%10
array([0j , (1+0j) ],'O')

I don't see (offhand) why other operations leave the array as complex,
and "%" causes it to be an 'O'.  Presumably complex arrays lack the
"mod" method and are getting promoted to Object.  However, for float
and double arrays you get the expected behavior:

>>> x=arange(2, typecode=Float) 
>>> x%10
array([ 0.,  1.])




From jbaddor at physics.mcgill.ca  Fri Jun  2 14:23:06 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Fri, 2 Jun 2000 14:23:06 -0400 (EDT)
Subject: [Numpy-discussion] CVS
In-Reply-To: <14647.55785.832702.542755@buffalo.fnal.gov>
Message-ID: <Pine.LNX.3.96.1000602141724.1215F-100000@kili.physics.mcgill.ca>

Hey Numpy people!

On Fri, 2 Jun 2000, Charles G Waldman wrote:

> This seems to be fixed in the current CVS version.  I suggest you
> either wait for the next release or grab the current version from CVS
> if this is really a problem for you.

I don't understand wich files I would need to take a new version from and
wich command I have to issue to get a version of Numpy that correct the
bug I just hit.

Thanks for help.

I would like my code to work with the next release.

Jean-Bernard




From janne at nnets.fi  Fri Jun  2 14:37:36 2000
From: janne at nnets.fi (Janne Sinkkonen)
Date: 02 Jun 2000 21:37:36 +0300
Subject: [Numpy-discussion] Is it a bug ?
In-Reply-To: Charles G Waldman's message of "Fri, 2 Jun 2000 10:59:37 -0500 (CDT)"
References: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>
	<14647.55785.832702.542755@buffalo.fnal.gov>
Message-ID: <m3aeh4j5e7.fsf@kinos.nnets.fi>

Charles G Waldman <cgw at fnal.gov> writes:

>  > >>> Numeric.__version__
>  > '11'

> >>> Numeric.__version__
> '15.2'
> >>> Numeric.arange(2)*1j
> array([ 0.+0.j,  0.+1.j])

I tested for the bug in the Numeric version 11 on the following:

Python 1.5.2+ (#7, Nov 13 1999, 17:39:22)  [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 
Python 1.5.2+ (#4, Oct  6 1999, 22:18:42) [C] on linux2 (alpha with cc)
Python 1.5.2 (#1, Apr 18 1999, 16:03:16)  [GCC pgcc-2.91.60 19981201 (egcs-1.1.1  on linux2

The bug was not present on these, nor in Numeric 15.2 in an SGI.  So the
problem seems to be not in the source but in the installation (or the
compiler).

-- 
Janne




From pauldubois at home.com  Fri Jun  2 16:52:34 2000
From: pauldubois at home.com (Paul F. Dubois)
Date: Fri, 2 Jun 2000 13:52:34 -0700
Subject: [Numpy-discussion] Package structure
Message-ID: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>

If I move things like FFT out of the core and make them separate packages, I
am left with a choice: make them real packages, which means their usage
would change, or structure the packages so that everything gets installed in
the Python search path the way it does now.

The first choice is better for the future, walling everything off into
namespaces properly. The second choice doesn't break any existing code.

The changes involve just namespace issues. Right now all of Numeric is
installed as separate top-level modules.

The same considerations apply somewhat to Numeric itself. By making the
existing Numeric.py into the __init__.py for a Numeric package, nothing
would break except imports of Precision and ArrayPrinter, which would have
to become Numeric.Precision, etc.

How much pain is the future worth?





From jhauser at ifm.uni-kiel.de  Fri Jun  2 17:38:36 2000
From: jhauser at ifm.uni-kiel.de (Janko Hauser)
Date: Fri, 2 Jun 2000 23:38:36 +0200 (CEST)
Subject: [Numpy-discussion] Package structure
In-Reply-To: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
References: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
Message-ID: <20000602213836.3559.qmail@lisboa.ifm.uni-kiel.de>

An important thing to keep in mind is the possibility that part of
Numeric.py can become a standard part of Python, this would mean that
it has the same status as the string module. This would speak against
a package structure for Numeric itself.

So if packages are used, the structure should not be a subtree of
Numeric.

Second thought: Should every module be it's own package? Or should
there be a structure so that third party modules can be sorted into
this structure (for example sorted by problem domains, math, data, IO,
physics/natural science, image processing etc.) One problem is, if some
libraries with a broader spectrum are wrapped, like GSL, the sorting
becomes obsolete. This would suggest to have a package for every
module.

I would also say, that it is not easy to aim at complete environment
if there is not a refactoring by a maintainer. As long as the modules
are only (not meant in a bad way) provided by different authors there
will be no kitchen sink application. This would also suggest a package
for every module.

__Janko




From DavidA at ActiveState.com  Fri Jun  2 18:18:04 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 2 Jun 2000 15:18:04 -0700
Subject: [Numpy-discussion] Package structure
In-Reply-To: <20000602213836.3559.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEECLCGAA.DavidA@ActiveState.com>

> An important thing to keep in mind is the possibility that part of
> Numeric.py can become a standard part of Python, this would mean that
> it has the same status as the string module. 

Why?  Packagizing of the standard library is a long-term goal.





From jhauser at ifm.uni-kiel.de  Sat Jun  3 04:30:44 2000
From: jhauser at ifm.uni-kiel.de (Janko Hauser)
Date: Sat, 3 Jun 2000 10:30:44 +0200 (CEST)
Subject: [Numpy-discussion] Package structure
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEECLCGAA.DavidA@ActiveState.com>
References: <20000602213836.3559.qmail@lisboa.ifm.uni-kiel.de> <PLEJJNOHDIGGLDPOGPJJEECLCGAA.DavidA@ActiveState.com>
Message-ID: <20000603083044.3938.qmail@lisboa.ifm.uni-kiel.de>

David Ascher writes:
 > > An important thing to keep in mind is the possibility that part of
 > > Numeric.py can become a standard part of Python, this would mean that
 > > it has the same status as the string module. 
 > 
 > Why?  Packagizing of the standard library is a long-term goal.
 > 
Also in the case of a Numeric package which goes into the standard
distribution should the other packages be integrated in the Numeric
namespace or build under an external tree in the site-packages
directory? I do not know the proposed scheme, is there something
written down somewhere?

__Janko



From pauldubois at home.com  Sat Jun  3 09:36:54 2000
From: pauldubois at home.com (Paul F. Dubois)
Date: Sat, 3 Jun 2000 06:36:54 -0700
Subject: [Numpy-discussion] Package structure
In-Reply-To: <20000603083044.3938.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <NDBBIEFMILBFPMDHJIMFGEEECGAA.pauldubois@home.com>

> Also in the case of a Numeric package which goes into the standard
> distribution should the other packages be integrated in the Numeric
> namespace or build under an external tree in the site-packages
> directory? I do not know the proposed scheme, is there something
> written down somewhere?
>
> __Janko
>
I didn't make a proposal; I was trying to gauge whether people would freak
at a change that required modification of existing scripts, or not.

My thoughts, however, were along the lines of two packages, Numeric and
MathPack. Then I would put a substructure under MathPack by subject area.

Already, however, we see ugliness on the horizon: the module RandomArray
imports both ranlib and a linear algebra package, so we have Package
Dependencies and all the glorious ugliness of real life. I'm sure we'd have
more in the future. There are competing packages for some things, such as
random numbers. Ugh, how to make this easy for a random scientist who drops
by...




From gettings at mines.utah.edu  Mon Jun  5 12:47:20 2000
From: gettings at mines.utah.edu (Paul Gettings)
Date: Mon, 5 Jun 2000 10:47:20 -0600
Subject: [Numpy-discussion] Sparse matrices in NumPy?
Message-ID: <20000605104720.A27715@mines.utah.edu>

I have a problem where I need to do matrix multiplication of a 7731x7731
matrix; storing this thing would take over 250 MB of memory, which is more
than my machine has. :(  However, the matrix is empty except for the main
diagonal.  Ideally, all that needs to be stored is a single vector 7731
elements long, and then tweak matrix multiplication algorithms to account for
this.  Are there any facilities in NumPy to do this sort of thing, or do I
have to roll my own?  Is there a way to effeciently store a very sparse
matrix and do standard matrix multiplies?  Thanks.

	-Paul Gettings
	 Dep't of Geology & Geophysics
	 University of Utah
--
  But Your Honor, they needed killin'.




From roitblat at hawaii.edu  Mon Jun  5 13:06:13 2000
From: roitblat at hawaii.edu (Herbert L. Roitblat)
Date: Mon, 5 Jun 2000 07:06:13 -1000
Subject: [Numpy-discussion] Sparse matrices in NumPy?
References: <20000605104720.A27715@mines.utah.edu>
Message-ID: <06b801bfcf10$5b915220$8fd6afcf@pixi.com>

Unless I am misunderstanding something, you have a vector, which is the
diagonal of a square matrix, and thus contains 7731 elements.  You want to
multiply it by another vector, which has 7731 columns.  Element by element
by element multiplication will, I think, give you the result that you want.

In matlab you would use the diag command and then use the .* operator to get
element by element multiplication.

In NumPY you would simply use the * operator to multiply the two vectors.

Travis Oliphant has sparse matrix classes that you might want to check out,
but I don't see why you would need them for this task.

HLR

----- Original Message -----
From: "Paul Gettings" <gettings at mines.utah.edu>
To: <numpy-discussion at lists.sourceforge.net>
Sent: Monday, June 05, 2000 6:49 AM
Subject: [Numpy-discussion] Sparse matrices in NumPy?


> I have a problem where I need to do matrix multiplication of a 7731x7731
> matrix; storing this thing would take over 250 MB of memory, which is more
> than my machine has. :(  However, the matrix is empty except for the main
> diagonal.  Ideally, all that needs to be stored is a single vector 7731
> elements long, and then tweak matrix multiplication algorithms to account
for
> this.  Are there any facilities in NumPy to do this sort of thing, or do I
> have to roll my own?  Is there a way to effeciently store a very sparse
> matrix and do standard matrix multiplies?  Thanks.
>
> -Paul Gettings
> Dep't of Geology & Geophysics
> University of Utah
> --
>   But Your Honor, they needed killin'.
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
>




From gettings at mines.utah.edu  Mon Jun  5 13:08:37 2000
From: gettings at mines.utah.edu (Paul Gettings)
Date: Mon, 5 Jun 2000 11:08:37 -0600
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <14651.56147.687865.579374@buffalo.fnal.gov>; from cgw@fnal.gov on Mon, Jun 05, 2000 at 11:54:43AM -0500
References: <20000605104720.A27715@mines.utah.edu> <14651.56147.687865.579374@buffalo.fnal.gov>
Message-ID: <20000605110837.B27715@mines.utah.edu>

> But memory is so cheap these days! ;-)
I am a grad student, and have no money. :(

>  > However, the matrix is empty except for the main diagonal. 
> Multiplying by a diagonalized matrix is just vectorized multiplication:
> a 0 0 
> 0 b 0   .  <x, y, z> = <az, by, cz>
> 0 0 c
My mistake - I need to multiply the 7731x7731 by a 7731x220 element matrix -
square matrix times rectangular matrix, not just 2 diagonal matrices.
Otherwise, the problem wouldn't be so hard. :)

--
  That which does not kill you, didn't try hard enough.




From cgw at fnal.gov  Mon Jun  5 13:22:20 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Mon, 5 Jun 2000 12:22:20 -0500 (CDT)
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <20000605110837.B27715@mines.utah.edu>
References: <20000605104720.A27715@mines.utah.edu>
	<14651.56147.687865.579374@buffalo.fnal.gov>
	<20000605110837.B27715@mines.utah.edu>
Message-ID: <14651.57804.486447.145742@buffalo.fnal.gov>

Paul Gettings writes:
 > 
 > >  > However, the matrix is empty except for the main diagonal. 
 > > Multiplying by a diagonalized matrix is just vectorized multiplication:
 > > a 0 0 
 > > 0 b 0   .  <x, y, z> = <az, by, cz>
 > > 0 0 c
 > My mistake - I need to multiply the 7731x7731 by a 7731x220 element matrix -
 > square matrix times rectangular matrix, not just 2 diagonal matrices.
 > Otherwise, the problem wouldn't be so hard. :)

Still it's not so bad, you just need to break the 7731x220 matrix into
220 vectors of length 7731 and multiply each of them by the diagonal
"matrix", one at a time, and glue the results back together.  The
7731x220 matrix should weigh in at about 6MB, hopefully you have
enough memory for this...



From jsaenz at wm.lc.ehu.es  Mon Jun  5 13:22:52 2000
From: jsaenz at wm.lc.ehu.es (Jon Saenz)
Date: Mon, 5 Jun 2000 19:22:52 +0200 (MET DST)
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <20000605110837.B27715@mines.utah.edu>
Message-ID: <Pine.OSF.3.95.1000605191542.28460A-100000@lcdx00.wm.lc.ehu.es>

I don't know if I am missing something, but:

Let's suppose you have A so that A.shape is (7731,). It is diagonal, so,
obviously, you don't need to save it all. Just a vector.

You also have B, shaped like this: (7731,220)

And you want to multiply A*B (the matrix way).

I would dare to say that what you really need is
C=A[:,NewAxis]*B
C will be shaped as (7731,220), which is what you probably need.

Jon Saenz.				| Tfno: +34 946012470
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

On Mon, 5 Jun 2000, Paul Gettings wrote:

> > But memory is so cheap these days! ;-)
> I am a grad student, and have no money. :(
> 
> >  > However, the matrix is empty except for the main diagonal. 
> > Multiplying by a diagonalized matrix is just vectorized multiplication:
> > a 0 0 
> > 0 b 0   .  <x, y, z> = <az, by, cz>
> > 0 0 c
> My mistake - I need to multiply the 7731x7731 by a 7731x220 element matrix -
> square matrix times rectangular matrix, not just 2 diagonal matrices.
> Otherwise, the problem wouldn't be so hard. :)
> 
> --
>   That which does not kill you, didn't try hard enough.
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 




From jbaddor at physics.mcgill.ca  Mon Jun  5 13:43:47 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Mon, 5 Jun 2000 13:43:47 -0400 (EDT)
Subject: [Numpy-discussion] Is it a(nother)  bug ? test_all.py
In-Reply-To: <m3aeh4j5e7.fsf@kinos.nnets.fi>
Message-ID: <Pine.LNX.3.96.1000605111624.1215H-100000@kili.physics.mcgill.ca>

Hy Numeric people!

Thank you very much Janne for your suggestion of a compilation problem. I
just recompiled with debug option and the Numeric.arange(2)*1j problem
disapeared.

Further testing of my Numeric 1.7 code shows that the code still breaks:

Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> from Numeric import *
>>> import Numeric
>>> Numeric.__version__
'11'
>>> a = arange(2, typecode=Complex) % 2
>>> a.typecode()
'O'
>>> add.outer(a**2,a**2)

Program received signal SIGSEGV, Segmentation fault.
0x4006b570 in malloc ()
(gdb) where (see at the end of message for debug info)

I have no idea if it is another bug or another compilation problem.

If this is an installation or compilation problem, I am surprised it
occures with standart linux, gcc. But I understand it can happens.

Proposal : a test for these problems should be included in test_all.py or
other test of the module. I installed with Distutils-0.8.2 and tested with
test_all.py without notification of any problem.

PS: I have the problem with Numeric 11 (distribution 14 compiled with egcc)

Thanks a lot for your help,

	Jean-Bernard

On 2 Jun 2000, Janne Sinkkonen wrote:

> Charles G Waldman <cgw at fnal.gov> writes:
> 
> >  > >>> Numeric.__version__
> >  > '11'
> 
> > >>> Numeric.__version__
> > '15.2'
> > >>> Numeric.arange(2)*1j
> > array([ 0.+0.j,  0.+1.j])
> 
> I tested for the bug in the Numeric version 11 on the following:
> 
> Python 1.5.2+ (#7, Nov 13 1999, 17:39:22)  [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 
> Python 1.5.2+ (#4, Oct  6 1999, 22:18:42) [C] on linux2 (alpha with cc)
> Python 1.5.2 (#1, Apr 18 1999, 16:03:16)  [GCC pgcc-2.91.60 19981201 (egcs-1.1.1  on linux2
> 
> The bug was not present on these, nor in Numeric 15.2 in an SGI.  So the
> problem seems to be not in the source but in the installation (or the
> compiler).
> 
> -- 
> Janne
> 


GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-pc-linux-gnu"...
(gdb) run
Starting program: /users/jbaddor/bin/python 
Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> from Numeric import *
>>> import Numeric
>>> Numeric.__version__
'11'
>>> a = arange(2, typecode=Complex) % 2
>>> a.typecode()
'O'
>>> add.outer(a**2,a**2)

Program received signal SIGSEGV, Segmentation fault.
0x4006b570 in malloc ()
(gdb) where
#0  0x4006b570 in malloc ()
#1  0x4006b0f5 in malloc ()
#2  0x8070c16 in PyString_FromStringAndSize (str=0x80d982c "[0j , (1+0j) ,
", 
    size=14) at stringobject.c:95
#3  0x80711b9 in string_slice (a=0x80d9818, i=0, j=14) at
stringobject.c:381
#4  0x80621ca in PySequence_GetSlice (s=0x80d9818, i1=0, i2=-1)
    at abstract.c:869
#5  0x807920e in apply_slice (u=0x80d9818, v=0x0, w=0x80a39cc) at
ceval.c:2552
#6  0x807699c in eval_code2 (co=0x80b4e88, globals=0x80b4d78, locals=0x0, 
    args=0x8102758, argcount=5, kws=0x810276c, kwcount=1, defs=0x80e1554, 
    defcount=2, owner=0x0) at ceval.c:938
#7  0x8077bbc in eval_code2 (co=0x80b4e88, globals=0x80b4d78, locals=0x0, 
    args=0x80d32cc, argcount=6, kws=0x80d32e4, kwcount=0, defs=0x80e1554, 
    defcount=2, owner=0x0) at ceval.c:1612
#8  0x8077bbc in eval_code2 (co=0x80e7818, globals=0x80b4d78, locals=0x0, 
    args=0x80d8ba0, argcount=6, kws=0x80d8bb8, kwcount=0, defs=0x80e19bc, 
    defcount=5, owner=0x0) at ceval.c:1612
#9  0x8077bbc in eval_code2 (co=0x80d5870, globals=0x80d95b0, locals=0x0, 
    args=0x8102a0c, argcount=1, kws=0x0, kwcount=0, defs=0x80e65c4, 
    defcount=3, owner=0x0) at ceval.c:1612
#10 0x807909d in call_function (func=0x80b4d58, arg=0x8102a00, kw=0x0)
    at ceval.c:2484
#11 0x8078c4d in PyEval_CallObjectWithKeywords (func=0x80b4d58,
arg=0x8102a00, 
    kw=0x0) at ceval.c:2322
#12 0x4014d405 in array_repr (self=0x80d3000) at Src/arrayobject.c:1119
#13 0x806ff52 in PyObject_Repr (v=0x80d3000) at object.c:237
#14 0x806fe5b in PyObject_Print (op=0x80d3000, fp=0x809f0c8, flags=0)
    at object.c:188
#15 0x8067e2e in PyFile_WriteObject (v=0x80d3000, f=0x80a2880, flags=0)
    at fileobject.c:1044
#16 0x8076c55 in eval_code2 (co=0x80d3598, globals=0x80a37e8, 
    locals=0x80a37e8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1030
#17 0x8076008 in PyEval_EvalCode (co=0x80d3598, globals=0x80a37e8, 
    locals=0x80a37e8) at ceval.c:324
#18 0x805c957 in run_node (n=0x80c7798, filename=0x8088027 "<stdin>", 
    globals=0x80a37e8, locals=0x80a37e8) at pythonrun.c:887
#19 0x805bdf8 in PyRun_InteractiveOne (fp=0x809f170, 
    filename=0x8088027 "<stdin>") at pythonrun.c:528
#20 0x805bc6f in PyRun_InteractiveLoop (fp=0x809f170, 
    filename=0x8088027 "<stdin>") at pythonrun.c:472
#21 0x805bbb2 in PyRun_AnyFile (fp=0x809f170, filename=0x8088027
"<stdin>")
    at pythonrun.c:449
#22 0x804efd9 in Py_Main (argc=1, argv=0xbffffbb4) at main.c:287
#23 0x804ea5a in main (argc=1, argv=0xbffffbb4) at python.c:12
(gdb) 




From gettings at mines.utah.edu  Mon Jun  5 13:56:09 2000
From: gettings at mines.utah.edu (Paul Gettings)
Date: Mon, 5 Jun 2000 11:56:09 -0600
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <Pine.OSF.3.95.1000605191542.28460A-100000@lcdx00.wm.lc.ehu.es>; from jsaenz@wm.lc.ehu.es on Mon, Jun 05, 2000 at 07:22:52PM +0200
References: <20000605110837.B27715@mines.utah.edu> <Pine.OSF.3.95.1000605191542.28460A-100000@lcdx00.wm.lc.ehu.es>
Message-ID: <20000605115609.C27715@mines.utah.edu>

> I would dare to say that what you really need is
> C=A[:,NewAxis]*B
> C will be shaped as (7731,220), which is what you probably need.
Based on a simple (small) test, this is exactly what I want; the result of
the NewAxis computation is identical to a matrix multiply of the full-sized
matrices.  Thanks.  Now I just have to read the docs until I understand
precisely how and why this works. :)

--
  101 USES FOR A DEAD MICROPROCESSOR
        (62)  Fungus trellis




From HZhu at knowledgetrack.com  Mon Jun  5 21:02:43 2000
From: HZhu at knowledgetrack.com (Huaiyu Zhu)
Date: Mon, 5 Jun 2000 18:02:43 -0700 (PDT)
Subject: [Numpy-discussion] Matrix computation in Matlab/Octave style
Message-ID: <Pine.LNX.4.10.10006051719560.1911-100000@rocket.knowledgetrack.com>

Are you craving for Matlab/Octave style expressions in Python?  (For example,
A*B is matrix multiplication, not elementwise.)   Now you can.

I've just made a package MatPy and started a SourceForge project for it.
It is implemented as wrappers around the Numeric and Gnuplot packages.

You can find the source codes, tests and docs on the home page
http://MatPy.sourceforge.net

The main reason I have written this package is that I'm tired of dealing
with NewAxis and have "Frame not aligned" exceptions.  Now matrices and
vectors behave as one would expect from linear algebra.

Examples:
>>> from MatPy.Matrix import *
>>> A = rand((20,5))
>>> x = rand((5,1))
>>> y = A*x
>>> b = solve(A,y)
>>> norm(b-x)
1.16043535672e-15
>>> print x
[  0.276 
   0.553 
   0.733 
   0.388 
   0.5    ]
>>> print x.T()
[  0.276   0.553   0.733   0.388   0.5    ]
>>> print x.T()*x
[  1.32   ]
>>> print x*x.T()
[  0.0763  0.153   0.203   0.107   0.138 
   0.153   0.306   0.406   0.214   0.277 
   0.203   0.406   0.538   0.284   0.367 
   0.107   0.214   0.284   0.15    0.194 
   0.138   0.277   0.367   0.194   0.25   ]
>>> z = x + rand(x.shape)*1j
>>> z.H()
[  0.276-0.606j  0.553-0.376j  0.733-0.933j  0.388-0.636j  0.5-0.314j ]
>>> z.H()*z
[   3.2+0j ]
>>> norm(z)**2
3.2026003449

There are also matrix and elementwise versions of functions:
expm and exp, sqrtm and sqrt, etc.  

Questions, comments, suggestions and helps are all very welcome.  

It is a future plan to have an efficient interface to Octave to leverage its
large code base.

Enjoy!

Huaiyu <hzhu at users.sourceforge.net>



From jhauser at ifm.uni-kiel.de  Tue Jun  6 09:43:15 2000
From: jhauser at ifm.uni-kiel.de (Janko Hauser)
Date: Tue, 6 Jun 2000 15:43:15 +0200 (CEST)
Subject: [Numpy-discussion] Proposing a new test framework
Message-ID: <14652.65523.267068.367288@ifm.uni-kiel.de>

Hello, I started to use PyUnit to build another test framework for
NumPy. The ideas behind this approach are:

-- Build on a known and maybe standard framework.

-- Make tests in such a way that they can be handled with Python so
   helper functions can be written to perform single tests from the
   commandline. 

-- The framework should facilitate the writing of new tests by
   everyone, not only for NumPy routines but also for more complex or
   derived programs.

-- The tests should be self contained, each test is done in a clean
   environment. 

-- The hole test suite can be run, also if some tests are
   failing. This is important for all these cases, where there are
   known errors in the system libraries.

-- Define and document what actually is tested. There are different
   criteria for tests on numerical functions, like testing the
   interface, the numerical valid input range, type coercions, the
   algorithm and so on.

In the end I want to have a module which can be imported and the
contained classes can be used to write new tests, perform tests and
generate reports. Together with a naming convention it should be
possible to automate the testing of new modules.

I have written some ideas down at:

http://lisboa.ifm.uni-kiel.de:80080/NumPy/NaFwiki/TestFramework

There is also a module which is NOT the proposed framework, but which
demonstrates how the code of the tests looks like.

Are there some comments, objections or new ideas?

With regards,

__Janko




From hinsen at dirac.cnrs-orleans.fr  Thu Jun 15 14:21:32 2000
From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr)
Date: Thu, 15 Jun 2000 20:21:32 +0200
Subject: [Numpy-discussion] Package structure
In-Reply-To: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
References: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
Message-ID: <200006151821.UAA06806@chinon.cnrs-orleans.fr>

> If I move things like FFT out of the core and make them separate packages, I
> am left with a choice: make them real packages, which means their usage
> would change, or structure the packages so that everything gets installed in
> the Python search path the way it does now.
> 
> The first choice is better for the future, walling everything off into
> namespaces properly. The second choice doesn't break any existing code.

There's a compromise: Change everything to a nice package structure,
and provide a compatibility module for some transition period. Then
everyone can adapt their code in a reasonable time. Ultimately the
compatibility modules can disappear.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From sanner at scripps.edu  Fri Jun 23 15:22:24 2000
From: sanner at scripps.edu (Michel Sanner)
Date: Fri, 23 Jun 2000 12:22:24 -0700
Subject: [Numpy-discussion] Numeric on Dec Alpha
Message-ID: <1000623122224.ZM350158@noah.scripps.edu>

Hi, I posted this message on the python-list a while ago and did not hear
anything .. so I try here :)

I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran it
I witnessed strange behavior.

a = Numeric.identity(4)
a.shape = (16,)

would raise an exception about the size of the array needing to remain the same
???

Using the debugger I found in arrayobject.c:2201

        if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_LONG) == -1)
return NULL;

After this call shape [0] is 4 BUT shape[1] is 0 !

I changed the code to
                  if (PyArray_As1D(&shape, (char **)&dimensions, &n,
PyArray_INT) == -1) return NULL;

and got the right result.

Did anyone else run into this kind of preblems ? what is the correct way to fix
that ?

thanks

-Michel


-- 

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

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

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sanner at scripps.edu                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------




From myers at tc.cornell.edu  Sat Jun 24 19:58:45 2000
From: myers at tc.cornell.edu (Chris Myers)
Date: Sat, 24 Jun 2000 19:58:45 -0400 (EDT)
Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #70 - 1 msg
In-Reply-To: <200006241919.MAA21234@lists.sourceforge.net>
Message-ID: <Pine.A41.3.96.1000624195157.16994F-100000@ctcmail.tc.cornell.edu>

Michel Sanner wrote:

> I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran 
> it I witnessed strange behavior.
> 
> a = Numeric.identity(4)
> a.shape = (16,)
> 
> would raise an exception about the size of the array needing to remain 
> the same ???

I have seen the same behavior on a Dec Alpha running RedHat Linux,
with Numeric compiled with gcc.

The other random pieces of Numeric that I tried seemed to work
correctly.

Chris

==========================================================================
Chris Myers 
Cornell Theory Center
--------------------------------------------------------------------------
636 Rhodes Hall              email: myers at tc.cornell.edu
Cornell University           phone: (607) 255-5894 / fax: (607) 254-8888
Ithaca, NY 14853             http://www.tc.cornell.edu/~myers
--------------------------------------------------------------------------
"To thine own self be blue." - Polonious Funk
==========================================================================




On Sat, 24 Jun 2000 numpy-discussion-admin at lists.sourceforge.net wrote:

> Date: Sat, 24 Jun 2000 12:19:28 -0700
> From: numpy-discussion-admin at lists.sourceforge.net
> Reply-To: numpy-discussion at lists.sourceforge.net
> To: numpy-discussion at lists.sourceforge.net
> Subject: Numpy-discussion digest, Vol 1 #70 - 1 msg
> 
> 
> Send Numpy-discussion mailing list submissions to
> 	numpy-discussion at lists.sourceforge.net
> 
> To subscribe or unsubscribe via the web, visit
> 	http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> or, via email, send a message with subject or body 'help' to
> 	numpy-discussion-request at lists.sourceforge.net
> You can reach the person managing the list at
> 	numpy-discussion-admin at lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Numpy-discussion digest..."
> 
> 
> Today's Topics:
> 
>   1. Numeric on Dec Alpha (Michel Sanner)
> 
> --__--__--
> 
> Message: 1
> From: "Michel Sanner" <sanner at scripps.edu>
> Date: Fri, 23 Jun 2000 12:22:24 -0700
> To: numpy-discussion at lists.sourceforge.net
> Subject: [Numpy-discussion] Numeric on Dec Alpha
> 
> Hi, I posted this message on the python-list a while ago and did not hear
> anything .. so I try here :)
> 
> I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran it
> I witnessed strange behavior.
> 
> a = Numeric.identity(4)
> a.shape = (16,)
> 
> would raise an exception about the size of the array needing to remain the same
> ???
> 
> Using the debugger I found in arrayobject.c:2201
> 
>         if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_LONG) == -1)
> return NULL;
> 
> After this call shape [0] is 4 BUT shape[1] is 0 !
> 
> I changed the code to
>                   if (PyArray_As1D(&shape, (char **)&dimensions, &n,
> PyArray_INT) == -1) return NULL;
> 
> and got the right result.
> 
> Did anyone else run into this kind of preblems ? what is the correct way to fix
> that ?
> 
> thanks
> 
> -Michel
> 
> 
> -- 
> 
> -----------------------------------------------------------------------
> 
> >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!
> 
> Michel F. Sanner Ph.D.                   The Scripps Research Institute
> Assistant Professor			Department of Molecular Biology
> 					  10550 North Torrey Pines Road
> Tel. (858) 784-2341				     La Jolla, CA 92037
> Fax. (858) 784-2860
> sanner at scripps.edu                        http://www.scripps.edu/sanner
> -----------------------------------------------------------------------
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 
> 
> End of Numpy-discussion Digest
> 




From vanroose at ruca.ua.ac.be  Sun Jun 25 09:02:56 2000
From: vanroose at ruca.ua.ac.be (Vanroose Wim)
Date: Sun, 25 Jun 2000 15:02:56 +0200
Subject: [Numpy-discussion] Generalized Eigenvalue problem
References: <200006241919.MAA21234@lists.sourceforge.net>
Message-ID: <39560300.580CB90C@ruca.ua.ac.be>

Dear NumPythoneers,

            I have to solve the generalized Eigenvalue problem      A u = lambda B
u
There are lapack procedures http://netlib2.cs.utk.edu/lapack/lug/node37.html.

These procedures are not present in the lite versions included in the NumPy
distribution.

            Did somebody already treat such problems??  Within Numpy or outside
Numpy. Do I have to install the full blown version of Lapack??


Wim Vanroose








From hinsen at dirac.cnrs-orleans.fr  Mon Jun 26 13:53:04 2000
From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr)
Date: Mon, 26 Jun 2000 19:53:04 +0200
Subject: [Numpy-discussion] Generalized Eigenvalue problem
In-Reply-To: <39560300.580CB90C@ruca.ua.ac.be> (message from Vanroose Wim on
	Sun, 25 Jun 2000 15:02:56 +0200)
References: <200006241919.MAA21234@lists.sourceforge.net> <39560300.580CB90C@ruca.ua.ac.be>
Message-ID: <200006261753.TAA20378@chinon.cnrs-orleans.fr>

>             Did somebody already treat such problems??  Within Numpy or outside
> Numpy. Do I have to install the full blown version of Lapack??

Yes, but it's not a big deal. If you then want a nicer high-level
interface, look at the module LinearAlgebra for guidance; input
parameters to LAPACK are treated rather consistently, so you shouldn't
have to invent anything reallly new.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From jbaddor at physics.mcgill.ca  Fri Jun  2 10:18:34 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Fri, 2 Jun 2000 10:18:34 -0400 (EDT)
Subject: [Numpy-discussion] Is it a bug ?
Message-ID: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>

Hey Numeric people!

I am just upgrading to a more recent version of Numeric and observe a new
behaviour:

Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__
'11'
>>> Numeric.arange(2)*1j
Segmentation fault

Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__ 
'1.7'
>>> Numeric.arange(2)*1j
array([ 0.+0.j,  0.+1.j])

I also saw:
              Numerical Python - Bug Tracking
              Viewing Open Bugs
                Bug ID
                                           Summary
               102277
                     CFLOAT/DOUBLE_setitem crashes when accessing imag.
part 

Am I hitting that bug?

CU

Jean-Bernard




From ryszard at arqule.com  Fri Jun  2 11:32:49 2000
From: ryszard at arqule.com (Czerminski, Ryszard)
Date: Fri, 2 Jun 2000 11:32:49 -0400 
Subject: [Numpy-discussion] exp behaviour: is it a bug ?
Message-ID: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>

Is the behaviour illustrated below a bug
or the Python's feature ?

Python 1.5.2 (#4, Mar  3 2000, 15:04:36)  [GCC 2.8.1] on irix6
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>
>>> from math import exp
>>> x = -706.
>>> while x > -900:
...    x = x - 1
...    print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
x, exp(x) = -709 0
[...]
x, exp(x) = -745 0
Traceback (innermost last):
  File "<stdin>", line 3, in ?
OverflowError: math range error
>>>

Ryszard Czerminski   phone: (781)994-0479
ArQule, Inc.         email:ryszard at arqule.com
19 Presidential Way  http://www.arqule.com
Woburn, MA 01801     fax: (781)994-0679


-----Original Message-----
From: Jean-Bernard Addor [mailto:jbaddor at physics.mcgill.ca]
Sent: Friday, June 02, 2000 10:19 AM
To: Numpy-discussion at lists.sourceforge.net
Subject: [Numpy-discussion] Is it a bug ?


Hey Numeric people!

I am just upgrading to a more recent version of Numeric and observe a new
behaviour:

Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__
'11'
>>> Numeric.arange(2)*1j
Segmentation fault

Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__ 
'1.7'
>>> Numeric.arange(2)*1j
array([ 0.+0.j,  0.+1.j])

I also saw:
              Numerical Python - Bug Tracking
              Viewing Open Bugs
                Bug ID
                                           Summary
               102277
                     CFLOAT/DOUBLE_setitem crashes when accessing imag.
part 

Am I hitting that bug?

CU

Jean-Bernard


_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/numpy-discussion



From jsaenz at wm.lc.ehu.es  Fri Jun  2 11:49:52 2000
From: jsaenz at wm.lc.ehu.es (Jon Saenz)
Date: Fri, 2 Jun 2000 17:49:52 +0200 (MET DST)
Subject: [Numpy-discussion] exp behaviour: is it a bug ?
In-Reply-To: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>
Message-ID: <Pine.OSF.3.95.1000602174839.23124A-100000@lcdx00.wm.lc.ehu.es>

No, it works correctly for me (other Python revision, anyway):
Python 1.5.2 (#3, Sep 27 1999, 15:02:20)  [GCC egcs-2.91.66 19990314
(egcs-1.1.2
  on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from math import *
>>> x=-706.
>>> while x>-900:
...     x=x-1
...     print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
x, exp(x) = -709 1.21678e-308
.....
x, exp(x) = -898 0
x, exp(x) = -899 0
x, exp(x) = -900 0
>>>


Jon Saenz.				| Tfno: +34 946012470
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

On Fri, 2 Jun 2000, Czerminski, Ryszard wrote:

> 
> Is the behaviour illustrated below a bug
> or the Python's feature ?
> 
> Python 1.5.2 (#4, Mar  3 2000, 15:04:36)  [GCC 2.8.1] on irix6
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>>
> >>> from math import exp
> >>> x = -706.
> >>> while x > -900:
> ...    x = x - 1
> ...    print 'x, exp(x) = %g %g' % (x, exp(x))
> ... 
> x, exp(x) = -707 8.99086e-308
> x, exp(x) = -708 3.30755e-308
> x, exp(x) = -709 0
> [...]
> x, exp(x) = -745 0
> Traceback (innermost last):
>   File "<stdin>", line 3, in ?
> OverflowError: math range error
> >>>
> 
> Ryszard Czerminski   phone: (781)994-0479
> ArQule, Inc.         email:ryszard at arqule.com
> 19 Presidential Way  http://www.arqule.com
> Woburn, MA 01801     fax: (781)994-0679
> 
> 
> -----Original Message-----
> From: Jean-Bernard Addor [mailto:jbaddor at physics.mcgill.ca]
> Sent: Friday, June 02, 2000 10:19 AM
> To: Numpy-discussion at lists.sourceforge.net
> Subject: [Numpy-discussion] Is it a bug ?
> 
> 
> Hey Numeric people!
> 
> I am just upgrading to a more recent version of Numeric and observe a new
> behaviour:
> 
> Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
> on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Hello from .pythonrc.py
> >>> import Numeric
> >>> Numeric.__version__
> '11'
> >>> Numeric.arange(2)*1j
> Segmentation fault
> 
> Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> Hello from .pythonrc.py
> >>> import Numeric
> >>> Numeric.__version__ 
> '1.7'
> >>> Numeric.arange(2)*1j
> array([ 0.+0.j,  0.+1.j])
> 
> I also saw:
>               Numerical Python - Bug Tracking
>               Viewing Open Bugs
>                 Bug ID
>                                            Summary
>                102277
>                      CFLOAT/DOUBLE_setitem crashes when accessing imag.
> part 
> 
> Am I hitting that bug?
> 
> CU
> 
> Jean-Bernard
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 




From cgw at fnal.gov  Fri Jun  2 11:59:37 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 2 Jun 2000 10:59:37 -0500 (CDT)
Subject: [Numpy-discussion] Is it a bug ?
In-Reply-To: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>
References: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>
Message-ID: <14647.55785.832702.542755@buffalo.fnal.gov>

Jean-Bernard Addor writes:
 > Hey Numeric people!
 > 
 > Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
 > on linux2
 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
 > Hello from .pythonrc.py
 > >>> import Numeric
 > >>> Numeric.__version__
 > '11'
 > >>> Numeric.arange(2)*1j
 > Segmentation fault
 > 

This seems to be fixed in the current CVS version.  I suggest you
either wait for the next release or grab the current version from CVS
if this is really a problem for you.

Python 1.6a2 (#9, May 22 2000, 12:34:51)  [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> import Numeric
>>> Numeric.__version__
'15.2'
>>> Numeric.arange(2)*1j
array([ 0.+0.j,  0.+1.j])




From jbaddor at physics.mcgill.ca  Fri Jun  2 12:30:17 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Fri, 2 Jun 2000 12:30:17 -0400 (EDT)
Subject: [Numpy-discussion] (arange(2, typecode=Complex) % 2).typecode()
Message-ID: <Pine.LNX.3.96.1000602122425.1215C-100000@kili.physics.mcgill.ca>

Hey again!

Why is (arange(2, typecode=Complex) % 2).typecode() object and not
complex?

Jean-Bernard

Python 1.5.1 (#1, Dec 17 1998, 20:58:15)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> from Numeric import *
>>> (arange(2, typecode=Complex) % 2).typecode()
'O'
>>> arange(2, typecode=Complex) % 2
array([0j , (1+0j) ],'O')
>>> arange(2) % 2
array([0, 1])

I have the same result python 1.5.2 and Numeric 11.




From cgw at fnal.gov  Fri Jun  2 12:36:55 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 2 Jun 2000 11:36:55 -0500 (CDT)
Subject: [Numpy-discussion] math.exp underflow (was: exp behaviour: is it a bug ?)
In-Reply-To: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>
References: <6B00FB949906D211A88800104B8AE5200183D5A4@WIREHEAD>
Message-ID: <14647.58023.493846.225899@buffalo.fnal.gov>

Czerminski, Ryszard writes:
 > 
 > Is the behaviour illustrated below a bug or the Python's feature ?

I don't know why you're posting this to the NumPy discussion list,
since the
"math" module is part of the standard Python distribution, not NumPy.

Anyhow, the differing behaviors people are seeing are just coming from
differences in the system math libraries:

On Linux (Intel):

Python 1.6a2 (#9, May 22 2000, 12:34:51)  [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from math import exp
>>> x = -706.
>>> while x > -900:
...    x = x - 1
...    print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
<snip>
x, exp(x) = -745 4.94066e-324
x, exp(x) = -746 0
<snip>
x, exp(x) = -899 0
x, exp(x) = -900 0
>>> 


Wheras on Irix (MIPS):
Python 1.6a2 (#8, Jun  1 2000, 20:01:55) [C] on irix646
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from math import exp
>>> x = -706.
>>> while x > -900:
...    x = x - 1
...    print 'x, exp(x) = %g %g' % (x, exp(x))
... 
x, exp(x) = -707 8.99086e-308
x, exp(x) = -708 3.30755e-308
x, exp(x) = -709 0
x, exp(x) = -710 0
<snip>
x, exp(x) = -745 0
Traceback (most recent call last):
  File "<stdin>", line 3, in ?
OverflowError: math range error


>From the Irix man page for exp(3M):

     The exp functions return HUGE_VAL when the correct value would overflow,
     and return zero if the correct value would underflow. The -lm and -lmx
     versions set the value of errno to ERANGE for both underflow and
     overflow.

Since the Python math module sees errno set after the call to exp, it
raises an exception.

Whereas on Linux, exp(-very big number) simply returns 0 and does not
set errno.

On the one hand, Python's behavior makes sense because it simply
reflects the behavior of the system math libraries.  On the other
hand, these kinds of differences make it hard to write portable code -
you could test on Linux and think everything is OK, then run on IRIX
and get exceptions.  Maybe that's just the way life is when you are
using floating-point math... Tim Peters may have more to say on this
topic <exp(-900)wink>











From cgw at fnal.gov  Fri Jun  2 12:41:51 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Fri, 2 Jun 2000 11:41:51 -0500 (CDT)
Subject: [Numpy-discussion] (arange(2, typecode=Complex) % 2).typecode()
In-Reply-To: <Pine.LNX.3.96.1000602122425.1215C-100000@kili.physics.mcgill.ca>
References: <Pine.LNX.3.96.1000602122425.1215C-100000@kili.physics.mcgill.ca>
Message-ID: <14647.58319.400989.157163@buffalo.fnal.gov>

Jean-Bernard Addor writes:
 > Hey again!
 > 
 > Why is (arange(2, typecode=Complex) % 2).typecode() object and not
 > complex?

Looks like a bug to me!

>>> x=arange(2, typecode=Complex) 
>>> x
array([ 0.+0.j,  1.+0.j])
>>> x+10
array([ 10.+0.j,  11.+0.j])
>>> x*10
array([  0.+0.j,  10.+0.j])
>>> x/10
array([ 0. +0.j,  0.1+0.j])
>>> x%10
array([0j , (1+0j) ],'O')

I don't see (offhand) why other operations leave the array as complex,
and "%" causes it to be an 'O'.  Presumably complex arrays lack the
"mod" method and are getting promoted to Object.  However, for float
and double arrays you get the expected behavior:

>>> x=arange(2, typecode=Float) 
>>> x%10
array([ 0.,  1.])




From jbaddor at physics.mcgill.ca  Fri Jun  2 14:23:06 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Fri, 2 Jun 2000 14:23:06 -0400 (EDT)
Subject: [Numpy-discussion] CVS
In-Reply-To: <14647.55785.832702.542755@buffalo.fnal.gov>
Message-ID: <Pine.LNX.3.96.1000602141724.1215F-100000@kili.physics.mcgill.ca>

Hey Numpy people!

On Fri, 2 Jun 2000, Charles G Waldman wrote:

> This seems to be fixed in the current CVS version.  I suggest you
> either wait for the next release or grab the current version from CVS
> if this is really a problem for you.

I don't understand wich files I would need to take a new version from and
wich command I have to issue to get a version of Numpy that correct the
bug I just hit.

Thanks for help.

I would like my code to work with the next release.

Jean-Bernard




From janne at nnets.fi  Fri Jun  2 14:37:36 2000
From: janne at nnets.fi (Janne Sinkkonen)
Date: 02 Jun 2000 21:37:36 +0300
Subject: [Numpy-discussion] Is it a bug ?
In-Reply-To: Charles G Waldman's message of "Fri, 2 Jun 2000 10:59:37 -0500 (CDT)"
References: <Pine.LNX.3.96.1000602094507.1215A-100000@kili.physics.mcgill.ca>
	<14647.55785.832702.542755@buffalo.fnal.gov>
Message-ID: <m3aeh4j5e7.fsf@kinos.nnets.fi>

Charles G Waldman <cgw at fnal.gov> writes:

>  > >>> Numeric.__version__
>  > '11'

> >>> Numeric.__version__
> '15.2'
> >>> Numeric.arange(2)*1j
> array([ 0.+0.j,  0.+1.j])

I tested for the bug in the Numeric version 11 on the following:

Python 1.5.2+ (#7, Nov 13 1999, 17:39:22)  [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 
Python 1.5.2+ (#4, Oct  6 1999, 22:18:42) [C] on linux2 (alpha with cc)
Python 1.5.2 (#1, Apr 18 1999, 16:03:16)  [GCC pgcc-2.91.60 19981201 (egcs-1.1.1  on linux2

The bug was not present on these, nor in Numeric 15.2 in an SGI.  So the
problem seems to be not in the source but in the installation (or the
compiler).

-- 
Janne




From pauldubois at home.com  Fri Jun  2 16:52:34 2000
From: pauldubois at home.com (Paul F. Dubois)
Date: Fri, 2 Jun 2000 13:52:34 -0700
Subject: [Numpy-discussion] Package structure
Message-ID: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>

If I move things like FFT out of the core and make them separate packages, I
am left with a choice: make them real packages, which means their usage
would change, or structure the packages so that everything gets installed in
the Python search path the way it does now.

The first choice is better for the future, walling everything off into
namespaces properly. The second choice doesn't break any existing code.

The changes involve just namespace issues. Right now all of Numeric is
installed as separate top-level modules.

The same considerations apply somewhat to Numeric itself. By making the
existing Numeric.py into the __init__.py for a Numeric package, nothing
would break except imports of Precision and ArrayPrinter, which would have
to become Numeric.Precision, etc.

How much pain is the future worth?





From jhauser at ifm.uni-kiel.de  Fri Jun  2 17:38:36 2000
From: jhauser at ifm.uni-kiel.de (Janko Hauser)
Date: Fri, 2 Jun 2000 23:38:36 +0200 (CEST)
Subject: [Numpy-discussion] Package structure
In-Reply-To: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
References: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
Message-ID: <20000602213836.3559.qmail@lisboa.ifm.uni-kiel.de>

An important thing to keep in mind is the possibility that part of
Numeric.py can become a standard part of Python, this would mean that
it has the same status as the string module. This would speak against
a package structure for Numeric itself.

So if packages are used, the structure should not be a subtree of
Numeric.

Second thought: Should every module be it's own package? Or should
there be a structure so that third party modules can be sorted into
this structure (for example sorted by problem domains, math, data, IO,
physics/natural science, image processing etc.) One problem is, if some
libraries with a broader spectrum are wrapped, like GSL, the sorting
becomes obsolete. This would suggest to have a package for every
module.

I would also say, that it is not easy to aim at complete environment
if there is not a refactoring by a maintainer. As long as the modules
are only (not meant in a bad way) provided by different authors there
will be no kitchen sink application. This would also suggest a package
for every module.

__Janko




From DavidA at ActiveState.com  Fri Jun  2 18:18:04 2000
From: DavidA at ActiveState.com (David Ascher)
Date: Fri, 2 Jun 2000 15:18:04 -0700
Subject: [Numpy-discussion] Package structure
In-Reply-To: <20000602213836.3559.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <PLEJJNOHDIGGLDPOGPJJEECLCGAA.DavidA@ActiveState.com>

> An important thing to keep in mind is the possibility that part of
> Numeric.py can become a standard part of Python, this would mean that
> it has the same status as the string module. 

Why?  Packagizing of the standard library is a long-term goal.





From jhauser at ifm.uni-kiel.de  Sat Jun  3 04:30:44 2000
From: jhauser at ifm.uni-kiel.de (Janko Hauser)
Date: Sat, 3 Jun 2000 10:30:44 +0200 (CEST)
Subject: [Numpy-discussion] Package structure
In-Reply-To: <PLEJJNOHDIGGLDPOGPJJEECLCGAA.DavidA@ActiveState.com>
References: <20000602213836.3559.qmail@lisboa.ifm.uni-kiel.de> <PLEJJNOHDIGGLDPOGPJJEECLCGAA.DavidA@ActiveState.com>
Message-ID: <20000603083044.3938.qmail@lisboa.ifm.uni-kiel.de>

David Ascher writes:
 > > An important thing to keep in mind is the possibility that part of
 > > Numeric.py can become a standard part of Python, this would mean that
 > > it has the same status as the string module. 
 > 
 > Why?  Packagizing of the standard library is a long-term goal.
 > 
Also in the case of a Numeric package which goes into the standard
distribution should the other packages be integrated in the Numeric
namespace or build under an external tree in the site-packages
directory? I do not know the proposed scheme, is there something
written down somewhere?

__Janko



From pauldubois at home.com  Sat Jun  3 09:36:54 2000
From: pauldubois at home.com (Paul F. Dubois)
Date: Sat, 3 Jun 2000 06:36:54 -0700
Subject: [Numpy-discussion] Package structure
In-Reply-To: <20000603083044.3938.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <NDBBIEFMILBFPMDHJIMFGEEECGAA.pauldubois@home.com>

> Also in the case of a Numeric package which goes into the standard
> distribution should the other packages be integrated in the Numeric
> namespace or build under an external tree in the site-packages
> directory? I do not know the proposed scheme, is there something
> written down somewhere?
>
> __Janko
>
I didn't make a proposal; I was trying to gauge whether people would freak
at a change that required modification of existing scripts, or not.

My thoughts, however, were along the lines of two packages, Numeric and
MathPack. Then I would put a substructure under MathPack by subject area.

Already, however, we see ugliness on the horizon: the module RandomArray
imports both ranlib and a linear algebra package, so we have Package
Dependencies and all the glorious ugliness of real life. I'm sure we'd have
more in the future. There are competing packages for some things, such as
random numbers. Ugh, how to make this easy for a random scientist who drops
by...




From gettings at mines.utah.edu  Mon Jun  5 12:47:20 2000
From: gettings at mines.utah.edu (Paul Gettings)
Date: Mon, 5 Jun 2000 10:47:20 -0600
Subject: [Numpy-discussion] Sparse matrices in NumPy?
Message-ID: <20000605104720.A27715@mines.utah.edu>

I have a problem where I need to do matrix multiplication of a 7731x7731
matrix; storing this thing would take over 250 MB of memory, which is more
than my machine has. :(  However, the matrix is empty except for the main
diagonal.  Ideally, all that needs to be stored is a single vector 7731
elements long, and then tweak matrix multiplication algorithms to account for
this.  Are there any facilities in NumPy to do this sort of thing, or do I
have to roll my own?  Is there a way to effeciently store a very sparse
matrix and do standard matrix multiplies?  Thanks.

	-Paul Gettings
	 Dep't of Geology & Geophysics
	 University of Utah
--
  But Your Honor, they needed killin'.




From roitblat at hawaii.edu  Mon Jun  5 13:06:13 2000
From: roitblat at hawaii.edu (Herbert L. Roitblat)
Date: Mon, 5 Jun 2000 07:06:13 -1000
Subject: [Numpy-discussion] Sparse matrices in NumPy?
References: <20000605104720.A27715@mines.utah.edu>
Message-ID: <06b801bfcf10$5b915220$8fd6afcf@pixi.com>

Unless I am misunderstanding something, you have a vector, which is the
diagonal of a square matrix, and thus contains 7731 elements.  You want to
multiply it by another vector, which has 7731 columns.  Element by element
by element multiplication will, I think, give you the result that you want.

In matlab you would use the diag command and then use the .* operator to get
element by element multiplication.

In NumPY you would simply use the * operator to multiply the two vectors.

Travis Oliphant has sparse matrix classes that you might want to check out,
but I don't see why you would need them for this task.

HLR

----- Original Message -----
From: "Paul Gettings" <gettings at mines.utah.edu>
To: <numpy-discussion at lists.sourceforge.net>
Sent: Monday, June 05, 2000 6:49 AM
Subject: [Numpy-discussion] Sparse matrices in NumPy?


> I have a problem where I need to do matrix multiplication of a 7731x7731
> matrix; storing this thing would take over 250 MB of memory, which is more
> than my machine has. :(  However, the matrix is empty except for the main
> diagonal.  Ideally, all that needs to be stored is a single vector 7731
> elements long, and then tweak matrix multiplication algorithms to account
for
> this.  Are there any facilities in NumPy to do this sort of thing, or do I
> have to roll my own?  Is there a way to effeciently store a very sparse
> matrix and do standard matrix multiplies?  Thanks.
>
> -Paul Gettings
> Dep't of Geology & Geophysics
> University of Utah
> --
>   But Your Honor, they needed killin'.
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
>




From gettings at mines.utah.edu  Mon Jun  5 13:08:37 2000
From: gettings at mines.utah.edu (Paul Gettings)
Date: Mon, 5 Jun 2000 11:08:37 -0600
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <14651.56147.687865.579374@buffalo.fnal.gov>; from cgw@fnal.gov on Mon, Jun 05, 2000 at 11:54:43AM -0500
References: <20000605104720.A27715@mines.utah.edu> <14651.56147.687865.579374@buffalo.fnal.gov>
Message-ID: <20000605110837.B27715@mines.utah.edu>

> But memory is so cheap these days! ;-)
I am a grad student, and have no money. :(

>  > However, the matrix is empty except for the main diagonal. 
> Multiplying by a diagonalized matrix is just vectorized multiplication:
> a 0 0 
> 0 b 0   .  <x, y, z> = <az, by, cz>
> 0 0 c
My mistake - I need to multiply the 7731x7731 by a 7731x220 element matrix -
square matrix times rectangular matrix, not just 2 diagonal matrices.
Otherwise, the problem wouldn't be so hard. :)

--
  That which does not kill you, didn't try hard enough.




From cgw at fnal.gov  Mon Jun  5 13:22:20 2000
From: cgw at fnal.gov (Charles G Waldman)
Date: Mon, 5 Jun 2000 12:22:20 -0500 (CDT)
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <20000605110837.B27715@mines.utah.edu>
References: <20000605104720.A27715@mines.utah.edu>
	<14651.56147.687865.579374@buffalo.fnal.gov>
	<20000605110837.B27715@mines.utah.edu>
Message-ID: <14651.57804.486447.145742@buffalo.fnal.gov>

Paul Gettings writes:
 > 
 > >  > However, the matrix is empty except for the main diagonal. 
 > > Multiplying by a diagonalized matrix is just vectorized multiplication:
 > > a 0 0 
 > > 0 b 0   .  <x, y, z> = <az, by, cz>
 > > 0 0 c
 > My mistake - I need to multiply the 7731x7731 by a 7731x220 element matrix -
 > square matrix times rectangular matrix, not just 2 diagonal matrices.
 > Otherwise, the problem wouldn't be so hard. :)

Still it's not so bad, you just need to break the 7731x220 matrix into
220 vectors of length 7731 and multiply each of them by the diagonal
"matrix", one at a time, and glue the results back together.  The
7731x220 matrix should weigh in at about 6MB, hopefully you have
enough memory for this...



From jsaenz at wm.lc.ehu.es  Mon Jun  5 13:22:52 2000
From: jsaenz at wm.lc.ehu.es (Jon Saenz)
Date: Mon, 5 Jun 2000 19:22:52 +0200 (MET DST)
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <20000605110837.B27715@mines.utah.edu>
Message-ID: <Pine.OSF.3.95.1000605191542.28460A-100000@lcdx00.wm.lc.ehu.es>

I don't know if I am missing something, but:

Let's suppose you have A so that A.shape is (7731,). It is diagonal, so,
obviously, you don't need to save it all. Just a vector.

You also have B, shaped like this: (7731,220)

And you want to multiply A*B (the matrix way).

I would dare to say that what you really need is
C=A[:,NewAxis]*B
C will be shaped as (7731,220), which is what you probably need.

Jon Saenz.				| Tfno: +34 946012470
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

On Mon, 5 Jun 2000, Paul Gettings wrote:

> > But memory is so cheap these days! ;-)
> I am a grad student, and have no money. :(
> 
> >  > However, the matrix is empty except for the main diagonal. 
> > Multiplying by a diagonalized matrix is just vectorized multiplication:
> > a 0 0 
> > 0 b 0   .  <x, y, z> = <az, by, cz>
> > 0 0 c
> My mistake - I need to multiply the 7731x7731 by a 7731x220 element matrix -
> square matrix times rectangular matrix, not just 2 diagonal matrices.
> Otherwise, the problem wouldn't be so hard. :)
> 
> --
>   That which does not kill you, didn't try hard enough.
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 




From jbaddor at physics.mcgill.ca  Mon Jun  5 13:43:47 2000
From: jbaddor at physics.mcgill.ca (Jean-Bernard Addor)
Date: Mon, 5 Jun 2000 13:43:47 -0400 (EDT)
Subject: [Numpy-discussion] Is it a(nother)  bug ? test_all.py
In-Reply-To: <m3aeh4j5e7.fsf@kinos.nnets.fi>
Message-ID: <Pine.LNX.3.96.1000605111624.1215H-100000@kili.physics.mcgill.ca>

Hy Numeric people!

Thank you very much Janne for your suggestion of a compilation problem. I
just recompiled with debug option and the Numeric.arange(2)*1j problem
disapeared.

Further testing of my Numeric 1.7 code shows that the code still breaks:

Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> from Numeric import *
>>> import Numeric
>>> Numeric.__version__
'11'
>>> a = arange(2, typecode=Complex) % 2
>>> a.typecode()
'O'
>>> add.outer(a**2,a**2)

Program received signal SIGSEGV, Segmentation fault.
0x4006b570 in malloc ()
(gdb) where (see at the end of message for debug info)

I have no idea if it is another bug or another compilation problem.

If this is an installation or compilation problem, I am surprised it
occures with standart linux, gcc. But I understand it can happens.

Proposal : a test for these problems should be included in test_all.py or
other test of the module. I installed with Distutils-0.8.2 and tested with
test_all.py without notification of any problem.

PS: I have the problem with Numeric 11 (distribution 14 compiled with egcc)

Thanks a lot for your help,

	Jean-Bernard

On 2 Jun 2000, Janne Sinkkonen wrote:

> Charles G Waldman <cgw at fnal.gov> writes:
> 
> >  > >>> Numeric.__version__
> >  > '11'
> 
> > >>> Numeric.__version__
> > '15.2'
> > >>> Numeric.arange(2)*1j
> > array([ 0.+0.j,  0.+1.j])
> 
> I tested for the bug in the Numeric version 11 on the following:
> 
> Python 1.5.2+ (#7, Nov 13 1999, 17:39:22)  [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 
> Python 1.5.2+ (#4, Oct  6 1999, 22:18:42) [C] on linux2 (alpha with cc)
> Python 1.5.2 (#1, Apr 18 1999, 16:03:16)  [GCC pgcc-2.91.60 19981201 (egcs-1.1.1  on linux2
> 
> The bug was not present on these, nor in Numeric 15.2 in an SGI.  So the
> problem seems to be not in the source but in the installation (or the
> compiler).
> 
> -- 
> Janne
> 


GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-pc-linux-gnu"...
(gdb) run
Starting program: /users/jbaddor/bin/python 
Python 1.5.2 (#9, May 30 2000, 15:08:12)  [GCC 2.95.2 19991024 (release)]
on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Hello from .pythonrc.py
>>> from Numeric import *
>>> import Numeric
>>> Numeric.__version__
'11'
>>> a = arange(2, typecode=Complex) % 2
>>> a.typecode()
'O'
>>> add.outer(a**2,a**2)

Program received signal SIGSEGV, Segmentation fault.
0x4006b570 in malloc ()
(gdb) where
#0  0x4006b570 in malloc ()
#1  0x4006b0f5 in malloc ()
#2  0x8070c16 in PyString_FromStringAndSize (str=0x80d982c "[0j , (1+0j) ,
", 
    size=14) at stringobject.c:95
#3  0x80711b9 in string_slice (a=0x80d9818, i=0, j=14) at
stringobject.c:381
#4  0x80621ca in PySequence_GetSlice (s=0x80d9818, i1=0, i2=-1)
    at abstract.c:869
#5  0x807920e in apply_slice (u=0x80d9818, v=0x0, w=0x80a39cc) at
ceval.c:2552
#6  0x807699c in eval_code2 (co=0x80b4e88, globals=0x80b4d78, locals=0x0, 
    args=0x8102758, argcount=5, kws=0x810276c, kwcount=1, defs=0x80e1554, 
    defcount=2, owner=0x0) at ceval.c:938
#7  0x8077bbc in eval_code2 (co=0x80b4e88, globals=0x80b4d78, locals=0x0, 
    args=0x80d32cc, argcount=6, kws=0x80d32e4, kwcount=0, defs=0x80e1554, 
    defcount=2, owner=0x0) at ceval.c:1612
#8  0x8077bbc in eval_code2 (co=0x80e7818, globals=0x80b4d78, locals=0x0, 
    args=0x80d8ba0, argcount=6, kws=0x80d8bb8, kwcount=0, defs=0x80e19bc, 
    defcount=5, owner=0x0) at ceval.c:1612
#9  0x8077bbc in eval_code2 (co=0x80d5870, globals=0x80d95b0, locals=0x0, 
    args=0x8102a0c, argcount=1, kws=0x0, kwcount=0, defs=0x80e65c4, 
    defcount=3, owner=0x0) at ceval.c:1612
#10 0x807909d in call_function (func=0x80b4d58, arg=0x8102a00, kw=0x0)
    at ceval.c:2484
#11 0x8078c4d in PyEval_CallObjectWithKeywords (func=0x80b4d58,
arg=0x8102a00, 
    kw=0x0) at ceval.c:2322
#12 0x4014d405 in array_repr (self=0x80d3000) at Src/arrayobject.c:1119
#13 0x806ff52 in PyObject_Repr (v=0x80d3000) at object.c:237
#14 0x806fe5b in PyObject_Print (op=0x80d3000, fp=0x809f0c8, flags=0)
    at object.c:188
#15 0x8067e2e in PyFile_WriteObject (v=0x80d3000, f=0x80a2880, flags=0)
    at fileobject.c:1044
#16 0x8076c55 in eval_code2 (co=0x80d3598, globals=0x80a37e8, 
    locals=0x80a37e8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1030
#17 0x8076008 in PyEval_EvalCode (co=0x80d3598, globals=0x80a37e8, 
    locals=0x80a37e8) at ceval.c:324
#18 0x805c957 in run_node (n=0x80c7798, filename=0x8088027 "<stdin>", 
    globals=0x80a37e8, locals=0x80a37e8) at pythonrun.c:887
#19 0x805bdf8 in PyRun_InteractiveOne (fp=0x809f170, 
    filename=0x8088027 "<stdin>") at pythonrun.c:528
#20 0x805bc6f in PyRun_InteractiveLoop (fp=0x809f170, 
    filename=0x8088027 "<stdin>") at pythonrun.c:472
#21 0x805bbb2 in PyRun_AnyFile (fp=0x809f170, filename=0x8088027
"<stdin>")
    at pythonrun.c:449
#22 0x804efd9 in Py_Main (argc=1, argv=0xbffffbb4) at main.c:287
#23 0x804ea5a in main (argc=1, argv=0xbffffbb4) at python.c:12
(gdb) 




From gettings at mines.utah.edu  Mon Jun  5 13:56:09 2000
From: gettings at mines.utah.edu (Paul Gettings)
Date: Mon, 5 Jun 2000 11:56:09 -0600
Subject: [Numpy-discussion] Sparse matrices in NumPy?
In-Reply-To: <Pine.OSF.3.95.1000605191542.28460A-100000@lcdx00.wm.lc.ehu.es>; from jsaenz@wm.lc.ehu.es on Mon, Jun 05, 2000 at 07:22:52PM +0200
References: <20000605110837.B27715@mines.utah.edu> <Pine.OSF.3.95.1000605191542.28460A-100000@lcdx00.wm.lc.ehu.es>
Message-ID: <20000605115609.C27715@mines.utah.edu>

> I would dare to say that what you really need is
> C=A[:,NewAxis]*B
> C will be shaped as (7731,220), which is what you probably need.
Based on a simple (small) test, this is exactly what I want; the result of
the NewAxis computation is identical to a matrix multiply of the full-sized
matrices.  Thanks.  Now I just have to read the docs until I understand
precisely how and why this works. :)

--
  101 USES FOR A DEAD MICROPROCESSOR
        (62)  Fungus trellis




From HZhu at knowledgetrack.com  Mon Jun  5 21:02:43 2000
From: HZhu at knowledgetrack.com (Huaiyu Zhu)
Date: Mon, 5 Jun 2000 18:02:43 -0700 (PDT)
Subject: [Numpy-discussion] Matrix computation in Matlab/Octave style
Message-ID: <Pine.LNX.4.10.10006051719560.1911-100000@rocket.knowledgetrack.com>

Are you craving for Matlab/Octave style expressions in Python?  (For example,
A*B is matrix multiplication, not elementwise.)   Now you can.

I've just made a package MatPy and started a SourceForge project for it.
It is implemented as wrappers around the Numeric and Gnuplot packages.

You can find the source codes, tests and docs on the home page
http://MatPy.sourceforge.net

The main reason I have written this package is that I'm tired of dealing
with NewAxis and have "Frame not aligned" exceptions.  Now matrices and
vectors behave as one would expect from linear algebra.

Examples:
>>> from MatPy.Matrix import *
>>> A = rand((20,5))
>>> x = rand((5,1))
>>> y = A*x
>>> b = solve(A,y)
>>> norm(b-x)
1.16043535672e-15
>>> print x
[  0.276 
   0.553 
   0.733 
   0.388 
   0.5    ]
>>> print x.T()
[  0.276   0.553   0.733   0.388   0.5    ]
>>> print x.T()*x
[  1.32   ]
>>> print x*x.T()
[  0.0763  0.153   0.203   0.107   0.138 
   0.153   0.306   0.406   0.214   0.277 
   0.203   0.406   0.538   0.284   0.367 
   0.107   0.214   0.284   0.15    0.194 
   0.138   0.277   0.367   0.194   0.25   ]
>>> z = x + rand(x.shape)*1j
>>> z.H()
[  0.276-0.606j  0.553-0.376j  0.733-0.933j  0.388-0.636j  0.5-0.314j ]
>>> z.H()*z
[   3.2+0j ]
>>> norm(z)**2
3.2026003449

There are also matrix and elementwise versions of functions:
expm and exp, sqrtm and sqrt, etc.  

Questions, comments, suggestions and helps are all very welcome.  

It is a future plan to have an efficient interface to Octave to leverage its
large code base.

Enjoy!

Huaiyu <hzhu at users.sourceforge.net>



From jhauser at ifm.uni-kiel.de  Tue Jun  6 09:43:15 2000
From: jhauser at ifm.uni-kiel.de (Janko Hauser)
Date: Tue, 6 Jun 2000 15:43:15 +0200 (CEST)
Subject: [Numpy-discussion] Proposing a new test framework
Message-ID: <14652.65523.267068.367288@ifm.uni-kiel.de>

Hello, I started to use PyUnit to build another test framework for
NumPy. The ideas behind this approach are:

-- Build on a known and maybe standard framework.

-- Make tests in such a way that they can be handled with Python so
   helper functions can be written to perform single tests from the
   commandline. 

-- The framework should facilitate the writing of new tests by
   everyone, not only for NumPy routines but also for more complex or
   derived programs.

-- The tests should be self contained, each test is done in a clean
   environment. 

-- The hole test suite can be run, also if some tests are
   failing. This is important for all these cases, where there are
   known errors in the system libraries.

-- Define and document what actually is tested. There are different
   criteria for tests on numerical functions, like testing the
   interface, the numerical valid input range, type coercions, the
   algorithm and so on.

In the end I want to have a module which can be imported and the
contained classes can be used to write new tests, perform tests and
generate reports. Together with a naming convention it should be
possible to automate the testing of new modules.

I have written some ideas down at:

http://lisboa.ifm.uni-kiel.de:80080/NumPy/NaFwiki/TestFramework

There is also a module which is NOT the proposed framework, but which
demonstrates how the code of the tests looks like.

Are there some comments, objections or new ideas?

With regards,

__Janko




From hinsen at dirac.cnrs-orleans.fr  Thu Jun 15 14:21:32 2000
From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr)
Date: Thu, 15 Jun 2000 20:21:32 +0200
Subject: [Numpy-discussion] Package structure
In-Reply-To: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
References: <NDBBIEFMILBFPMDHJIMFEEDOCGAA.pauldubois@home.com>
Message-ID: <200006151821.UAA06806@chinon.cnrs-orleans.fr>

> If I move things like FFT out of the core and make them separate packages, I
> am left with a choice: make them real packages, which means their usage
> would change, or structure the packages so that everything gets installed in
> the Python search path the way it does now.
> 
> The first choice is better for the future, walling everything off into
> namespaces properly. The second choice doesn't break any existing code.

There's a compromise: Change everything to a nice package structure,
and provide a compatibility module for some transition period. Then
everyone can adapt their code in a reasonable time. Ultimately the
compatibility modules can disappear.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------



From sanner at scripps.edu  Fri Jun 23 15:22:24 2000
From: sanner at scripps.edu (Michel Sanner)
Date: Fri, 23 Jun 2000 12:22:24 -0700
Subject: [Numpy-discussion] Numeric on Dec Alpha
Message-ID: <1000623122224.ZM350158@noah.scripps.edu>

Hi, I posted this message on the python-list a while ago and did not hear
anything .. so I try here :)

I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran it
I witnessed strange behavior.

a = Numeric.identity(4)
a.shape = (16,)

would raise an exception about the size of the array needing to remain the same
???

Using the debugger I found in arrayobject.c:2201

        if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_LONG) == -1)
return NULL;

After this call shape [0] is 4 BUT shape[1] is 0 !

I changed the code to
                  if (PyArray_As1D(&shape, (char **)&dimensions, &n,
PyArray_INT) == -1) return NULL;

and got the right result.

Did anyone else run into this kind of preblems ? what is the correct way to fix
that ?

thanks

-Michel


-- 

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

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

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sanner at scripps.edu                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------




From myers at tc.cornell.edu  Sat Jun 24 19:58:45 2000
From: myers at tc.cornell.edu (Chris Myers)
Date: Sat, 24 Jun 2000 19:58:45 -0400 (EDT)
Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #70 - 1 msg
In-Reply-To: <200006241919.MAA21234@lists.sourceforge.net>
Message-ID: <Pine.A41.3.96.1000624195157.16994F-100000@ctcmail.tc.cornell.edu>

Michel Sanner wrote:

> I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran 
> it I witnessed strange behavior.
> 
> a = Numeric.identity(4)
> a.shape = (16,)
> 
> would raise an exception about the size of the array needing to remain 
> the same ???

I have seen the same behavior on a Dec Alpha running RedHat Linux,
with Numeric compiled with gcc.

The other random pieces of Numeric that I tried seemed to work
correctly.

Chris

==========================================================================
Chris Myers 
Cornell Theory Center
--------------------------------------------------------------------------
636 Rhodes Hall              email: myers at tc.cornell.edu
Cornell University           phone: (607) 255-5894 / fax: (607) 254-8888
Ithaca, NY 14853             http://www.tc.cornell.edu/~myers
--------------------------------------------------------------------------
"To thine own self be blue." - Polonious Funk
==========================================================================




On Sat, 24 Jun 2000 numpy-discussion-admin at lists.sourceforge.net wrote:

> Date: Sat, 24 Jun 2000 12:19:28 -0700
> From: numpy-discussion-admin at lists.sourceforge.net
> Reply-To: numpy-discussion at lists.sourceforge.net
> To: numpy-discussion at lists.sourceforge.net
> Subject: Numpy-discussion digest, Vol 1 #70 - 1 msg
> 
> 
> Send Numpy-discussion mailing list submissions to
> 	numpy-discussion at lists.sourceforge.net
> 
> To subscribe or unsubscribe via the web, visit
> 	http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> or, via email, send a message with subject or body 'help' to
> 	numpy-discussion-request at lists.sourceforge.net
> You can reach the person managing the list at
> 	numpy-discussion-admin at lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Numpy-discussion digest..."
> 
> 
> Today's Topics:
> 
>   1. Numeric on Dec Alpha (Michel Sanner)
> 
> --__--__--
> 
> Message: 1
> From: "Michel Sanner" <sanner at scripps.edu>
> Date: Fri, 23 Jun 2000 12:22:24 -0700
> To: numpy-discussion at lists.sourceforge.net
> Subject: [Numpy-discussion] Numeric on Dec Alpha
> 
> Hi, I posted this message on the python-list a while ago and did not hear
> anything .. so I try here :)
> 
> I built Numeric on a Dec Alpha under OSF1 V4.0. I built fine but when I ran it
> I witnessed strange behavior.
> 
> a = Numeric.identity(4)
> a.shape = (16,)
> 
> would raise an exception about the size of the array needing to remain the same
> ???
> 
> Using the debugger I found in arrayobject.c:2201
> 
>         if (PyArray_As1D(&shape, (char **)&dimensions, &n, PyArray_LONG) == -1)
> return NULL;
> 
> After this call shape [0] is 4 BUT shape[1] is 0 !
> 
> I changed the code to
>                   if (PyArray_As1D(&shape, (char **)&dimensions, &n,
> PyArray_INT) == -1) return NULL;
> 
> and got the right result.
> 
> Did anyone else run into this kind of preblems ? what is the correct way to fix
> that ?
> 
> thanks
> 
> -Michel
> 
> 
> -- 
> 
> -----------------------------------------------------------------------
> 
> >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!
> 
> Michel F. Sanner Ph.D.                   The Scripps Research Institute
> Assistant Professor			Department of Molecular Biology
> 					  10550 North Torrey Pines Road
> Tel. (858) 784-2341				     La Jolla, CA 92037
> Fax. (858) 784-2860
> sanner at scripps.edu                        http://www.scripps.edu/sanner
> -----------------------------------------------------------------------
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 
> 
> End of Numpy-discussion Digest
> 




From vanroose at ruca.ua.ac.be  Sun Jun 25 09:02:56 2000
From: vanroose at ruca.ua.ac.be (Vanroose Wim)
Date: Sun, 25 Jun 2000 15:02:56 +0200
Subject: [Numpy-discussion] Generalized Eigenvalue problem
References: <200006241919.MAA21234@lists.sourceforge.net>
Message-ID: <39560300.580CB90C@ruca.ua.ac.be>

Dear NumPythoneers,

            I have to solve the generalized Eigenvalue problem      A u = lambda B
u
There are lapack procedures http://netlib2.cs.utk.edu/lapack/lug/node37.html.

These procedures are not present in the lite versions included in the NumPy
distribution.

            Did somebody already treat such problems??  Within Numpy or outside
Numpy. Do I have to install the full blown version of Lapack??


Wim Vanroose








From hinsen at dirac.cnrs-orleans.fr  Mon Jun 26 13:53:04 2000
From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr)
Date: Mon, 26 Jun 2000 19:53:04 +0200
Subject: [Numpy-discussion] Generalized Eigenvalue problem
In-Reply-To: <39560300.580CB90C@ruca.ua.ac.be> (message from Vanroose Wim on
	Sun, 25 Jun 2000 15:02:56 +0200)
References: <200006241919.MAA21234@lists.sourceforge.net> <39560300.580CB90C@ruca.ua.ac.be>
Message-ID: <200006261753.TAA20378@chinon.cnrs-orleans.fr>

>             Did somebody already treat such problems??  Within Numpy or outside
> Numpy. Do I have to install the full blown version of Lapack??

Yes, but it's not a big deal. If you then want a nicer high-level
interface, look at the module LinearAlgebra for guidance; input
parameters to LAPACK are treated rather consistently, so you shouldn't
have to invent anything reallly new.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------