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

Re: [Numpy-discussion] Sparse matrices in NumPy?

[Jon S. <js...@wm...>]

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
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 

Re: [Numpy-discussion] Sparse matrices in NumPy?

[Charles G W. <cg...@fn...>]

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...

Re: [Numpy-discussion] Sparse matrices in NumPy?

[Paul G. <get...@mi...>]

> 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.

Re: [Numpy-discussion] Sparse matrices in NumPy?

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

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" <get...@mi...>
To: <num...@li...>
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
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
>

[Numpy-discussion] Sparse matrices in NumPy?

[Paul G. <get...@mi...>]

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'.

RE: [Numpy-discussion] Package structure

[Paul F. D. <pau...@ho...>]

> 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...

RE: [Numpy-discussion] Package structure

[Janko H. <jh...@if...>]

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

RE: [Numpy-discussion] Package structure

[David A. <Da...@Ac...>]

> 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.

Re: [Numpy-discussion] Package structure

[Janko H. <jh...@if...>]

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

[Numpy-discussion] Package structure

[Paul F. D. <pau...@ho...>]

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?

Re: [Numpy-discussion] Is it a bug ?

[Janne S. <ja...@nn...>]

Charles G Waldman <cg...@fn...> 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

[Numpy-discussion] CVS

[Jean-Bernard A. <jb...@ph...>]

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

[Numpy-discussion] (arange(2, typecode=Complex) % 2).typecode()

[Charles G W. <cg...@fn...>]

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.])

[Numpy-discussion] math.exp underflow (was: exp behaviour: is it a bug ?)

[Charles G W. <cg...@fn...>]

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>

[Numpy-discussion] (arange(2, typecode=Complex) % 2).typecode()

[Jean-Bernard A. <jb...@ph...>]

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.

[Numpy-discussion] Is it a bug ?

[Charles G W. <cg...@fn...>]

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])

Re: [Numpy-discussion] exp behaviour: is it a bug ?

[Jon S. <js...@wm...>]

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:ry...@ar...
> 19 Presidential Way  http://www.arqule.com
> Woburn, MA 01801     fax: (781)994-0679
> 
> 
> -----Original Message-----
> From: Jean-Bernard Addor [mailto:jb...@ph...]
> Sent: Friday, June 02, 2000 10:19 AM
> To: Num...@li...
> 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
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
> 

[Numpy-discussion] exp behaviour: is it a bug ?

[Czerminski, R. <ry...@ar...>]

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:ry...@ar...
19 Presidential Way  http://www.arqule.com
Woburn, MA 01801     fax: (781)994-0679


-----Original Message-----
From: Jean-Bernard Addor [mailto:jb...@ph...]
Sent: Friday, June 02, 2000 10:19 AM
To: Num...@li...
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
Num...@li...
http://lists.sourceforge.net/mailman/listinfo/numpy-discussion

[Numpy-discussion] Is it a bug ?

[Jean-Bernard A. <jb...@ph...>]

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

RE: [Numpy-discussion] Binaries for Windows?

[Paul F. D. <pau...@ho...>]

It takes someone making a build on Windows and putting the file on
SourceForge. There is a Windows installer for 15.2, just not 15.3 yet. You
can find it by looking at the full list of available releases.

> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of
> hi...@di...
> Sent: Wednesday, May 31, 2000 1:37 AM
> To: num...@li...
> Subject: [Numpy-discussion] Binaries for Windows?
>
>
> Is there any place where one can get Windows binaries for NumPy, even
> if it's not the latest release? SourceForge only has source and Linux
> binary versions, and the LLNL site doesn't seem to exist any more.
>
> Konrad.
> --
> ------------------------------------------------------------------
> -------------
> Konrad Hinsen                            | E-Mail: hi...@cn...
> Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
> Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
> 45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
> France                                   | Nederlands/Francais
> ------------------------------------------------------------------
> -------------
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion

[Numpy-discussion] Binaries for Windows?

[<hi...@di...>]

Is there any place where one can get Windows binaries for NumPy, even
if it's not the latest release? SourceForge only has source and Linux
binary versions, and the LLNL site doesn't seem to exist any more.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] Revision to MA checked in

[Paul F. D. <pau...@ho...>]

I have checked into CVS a major improvement to MA, the missing array
facility.

[Numpy-discussion] New development tree now on SourceForge.

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

As I have received several encouraging emails of interested people, 

I'm excited to announce the availability of an experimental Numerical
Python revision on the NumPy SourceForge site.  

I've placed it under the directoryname numpy2  (checkout that directory
according to the CVS instructions). 

It is NOT COMPLETED yet, so only people interested in a particular view of
a future arrayobject or who want to help fashion that view should check it
out.  

Summary:

It builds on the current NumPy.  Operations should not change on the
Python level.  Important new operations will be added.  C-API is changed
but support for backward-near-compatibility is desired and sought after.
Only an NDArray class and a Ufunc class along with standard operations on
them is set for inclusion in the new development.  Other components will
be added modules.  

NDArray:

This is a Python class with C-calls placed for speed of certain
operations.  It is built around a data object which can be any Python
object exporting a buffer interface (including a buffer object) and a
dimensions/strides object which is also relies on the buffer interface.  

A C-API gives C-users access to the pointers for this information for any
subclass of NDArray.  

Ufunc:

This is a Python class that encapsulates the N-D looping structure with
the broadcasting rules.  It will allow wrapping of fast C functions as
well as Python functions.  It basically consists of two attributes:  a
select function (for type coercion and specification) and a compute
function that does the actual computation. 


Comments and feedback (and especially code) are welcomed.   

-Travis

Re: [Numpy-discussion] using lapack and blas rpms

[<hi...@di...>]

> These instructions rely on the old way of making numpy.
> The new way would involve making corresponding changes to setup.py
> I intend to do this as the default soon as I have had numerous requests for
> it.

Is it possible with Distutils to use LAPACK if it's installed and
the C versions otherwise? That should make everybody happy.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

RE: [Numpy-discussion] using lapack and blas rpms

[Paul F. D. <pau...@ho...>]

Konrad,
These instructions rely on the old way of making numpy.
The new way would involve making corresponding changes to setup.py
I intend to do this as the default soon as I have had numerous requests for
it.
Paul

> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of
> hi...@di...
> Sent: Thursday, May 25, 2000 8:41 AM
> To: da...@da...
> Cc: num...@li...
> Subject: Re: [Numpy-discussion] using lapack and blas rpms
>
>
> > Please let me know if this is the wrong mailing list for this question:
> >
> > I'm running red hat linux 6.2 and have used rpms to install the numpy,
> > lapack, and blas packages.  How do I get numpy to use the
> versions of lapack
> > and blas I've installed?  Thanks.
>
> You can't do it with the NumPy RPMs, which use the C versions.
> So you must get the NumPy source code distribution and compile it
> yourself. Before compiling it, edit the file "Setup" such that
> the line starting with "lapack_lite" reads
>
> lapack_lite -I./Include Src/lapack_litemodule.c -llapack -lblas -lg2c -lm
>
> The compile and install according to the instructions.
> --
> ------------------------------------------------------------------
> -------------
> Konrad Hinsen                            | E-Mail: hi...@cn...
> Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
> Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
> 45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
> France                                   | Nederlands/Francais
> ------------------------------------------------------------------
> -------------
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
>