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

[Numpy-discussion] Some questions about PyArray_As2D.

[Andrea R. <ari...@pi...>]

Hi,
I've two question about PyArray_As2D function:

1) Looking at the source code I realized that the prototype given in 
the manual is different from that of the source:

PyArray_As2D(PyObject *op, char **ptr, int *m, int *n, int type) (from 
manual)

PyArray_As2D(PyObject **op, char ***ptr, int *d1, int *d2, int 
typecode) (from source)

As far as I can understand the source version is correct while the 
manual's one is not. Am I wrong?

2) Next in the source code I've found the following memory allocation:

data = (char **)malloc(n*sizeof(char *));

without checking if malloc return NULL or not. As far as I know it's 
not safe, even if it's very unlikely that this malloc would fail.
Anyway in that case the following:

...
data[i] = ap->data + i*ap->strides[0];
...

would cause the function to abort. Again am I wrong?

Thanks in advance,
Andrea.

---
Andrea Riciputi        <mailto:and...@li...>

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman) 
  

Re: [Numpy-discussion] Detecting Numeric.

[Pearu P. <pe...@ce...>]

On Wed, 11 Dec 2002, Andrea Riciputi wrote:

> Hi there,
> I'm playing with Numeric and even if I've not so much experience with 
> it I'm trying to write a C extention to Python that can use Numeric 
> arrays. The basic idea consists in handling C (dynamically allocated) 
> array as Numeric array (if Numeric is installed) or as simple Python 
> lists if not.
> 
> How can I detect at compile time if Numeric is installed or not?? I've 
> thought something like:
> 
> #ifdef NUMERIC_IS_HERE
> #include "Numeric/arrayobject.h"
> #endif
> 
> But I've not found any hints in Numeric manual. Can anyone suggest a 
> solution to me?

If you are using distutils for building extension modules then you can
test if Numeric is available in setup.py file and define, say, HAVE_NUMPY
macro, if Numeric is available. For example,

#-------

have_numpy = 0
try:
    import Numeric
    have_numpy = 1
except ImportError:
    pass

define_macros = []
if have_numpy:
    define_macros.append(('HAVE_NUMPY', None))

if __name__ == "__main__":

    from distutils.core import setup
    setup(name = ...,
          ext_modules = [...],
          define_macros = define_macros
          )

#---------

and in extension source files use

#ifdef HAVE_NUMPY
...
#endif

HTH,
	Pearu

Re: [Numpy-discussion] Detecting Numeric.

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

Andrea Riciputi <ari...@pi...> writes:

> How can I detect at compile time if Numeric is installed or not?? I've
> thought something like:
> 
> #ifdef NUMERIC_IS_HERE
> #include "Numeric/arrayobject.h"
> #endif

Supposing that you will use distutils for compilation and installation
of your extension module, the solution is easy: your distutils script
can test for Numeric and then add the compiler flag. For example:

   defines = []
   try:
       import Numeric
       defines.append('NUMERIC_IS_HERE')
   except ImportError:
       pass

   ...

   Extension("foo", ["foo.c"], define_macros = defines)

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

[Numpy-discussion] Detecting Numeric.

[Andrea R. <ari...@pi...>]

Hi there,
I'm playing with Numeric and even if I've not so much experience with 
it I'm trying to write a C extention to Python that can use Numeric 
arrays. The basic idea consists in handling C (dynamically allocated) 
array as Numeric array (if Numeric is installed) or as simple Python 
lists if not.

How can I detect at compile time if Numeric is installed or not?? I've 
thought something like:

#ifdef NUMERIC_IS_HERE
#include "Numeric/arrayobject.h"
#endif

But I've not found any hints in Numeric manual. Can anyone suggest a 
solution to me?

Thanks in advance,
Andrea.

---
Andrea Riciputi        <mailto:and...@li...>

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman) 
  

[Numpy-discussion] Re: [SciPy-user] numarray equality testing

[Robert K. <ke...@ca...>]

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

[snip]

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

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

> -tim

-- 
Robert Kern
Ruddock House President
ke...@ca...

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

[Numpy-discussion] installation warning on RH 7.3

[Dave B. <ba...@co...>]

I just installed numpy on my RH 7.3 system under python 2.2.2.  I get the
following messages when I import Numeric.

Could someone enlighten me as to what this means and what I should do about
it?

Thanks,

Dave Bazell


Python 2.2.2 (#1, Oct 21 2002, 12:22:55)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Numeric
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/Numeric/Numeric.py", line 93,
in ?
    from Precision import *
  File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line
26, in ?
    _code_table = _fill_table(typecodes)
  File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line
23, in _fill_table
    table[key] = _get_precisions(value)
  File "/usr/local/lib/python2.2/site-packages/Numeric/Precision.py", line
18, in _get_precisions
    lst.append( (zeros( (1,), t ).itemsize()*8, t) )
ValueError: Invalid type for array
>>> import Numeric
>>>

Re: [Numpy-discussion] numarray rank-0 array issues

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

"Perry Greenfield" <pe...@st...> writes:

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

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

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

Re: [Numpy-discussion] numarray equality testing

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

"Perry Greenfield" <pe...@st...> writes:

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

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

Konrad.

RE: [Numpy-discussion] Re: [SciPy-user] numarray complex comparisons

[Perry G. <pe...@st...>]

Tim Hochberg write:

> 
> What is the argument against allowing __eq__ to continue to work, while
> disallowing __lt__ and friends. The former is well defined. I 
> know comparing
> floating point number for equality is a bit of a suckers game, but were
> allowing it for floats and it's sometimes useful.
> 
> On second thought, maybe I'm just misinterpreting you here since __eq__
> works fine for complex scalars.
> 
> -tim

I wasn't clear on this. What I was arguing was that less, less_equal,
greater, greater_equal would not work, but that equal and not_equal

Primarily because that is what Python does. It does allow one
to test for equality (or non equality), but doesn't allow
for >,<,>=,<=, which is sensible in my view.

Perry

[Numpy-discussion] RE: numarray equality testing

[Perry G. <pe...@st...>]

Pearu Peterson write:

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

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

returns

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

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

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

Perry 

[Numpy-discussion] Re: [SciPy-user] numarray complex comparisons

[Tim H. <tim...@ie...>]

> The questions just keep coming...
>
> We need to decide whether or not complex comparisons work.
> They do not work for Python scalars. Consistency would argue
> for them not working for numarray arrays. However some argue:
>
> 1) not allowing them defeats more generic programming. We agreed
> until we found that IDL doesn't support them either, and we never
> noticed. We are skeptical of this claim and would like to see
> real-life examples.
>
> 2) it is useful to allow comparisons since that would result in
> repeatable, sorting of values (e.g., to find duplicate values)
> for ordering purposes. Cannot this just be handled by the sort
> routines themselves? Why must this result in comparison operators
> working?
>
> In the absence of good examples for 1) or good arguments for 2)
> we propose to make complex comparisons generate exceptions.

What is the argument against allowing __eq__ to continue to work, while
disallowing __lt__ and friends. The former is well defined. I know comparing
floating point number for equality is a bit of a suckers game, but were
allowing it for floats and it's sometimes useful.

On second thought, maybe I'm just misinterpreting you here since __eq__
works fine for complex scalars.

-tim

[Numpy-discussion] Re: [SciPy-user] numarray equality testing

[Pearu P. <pe...@ce...>]

On Mon, 9 Dec 2002, Perry Greenfield wrote:

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

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

May be you meant

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

which I would agree. Also

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

but I am not sure about

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

Pearu

[Numpy-discussion] numarray rank-0 array issues

[Perry G. <pe...@st...>]

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

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

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

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

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

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

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

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

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

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

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

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

Perry Greenfield

[Numpy-discussion] numarray complex comparisons

[Perry G. <pe...@st...>]

The questions just keep coming...

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

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

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

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

Perry Greenfield

[Numpy-discussion] numarray equality testing

[Perry G. <pe...@st...>]

This is a Numeric/numarray compatibility question.

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

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

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

Comments?

Perry Greenfield

[Numpy-discussion] ANN: F2PY - Fortran to Python Interface Generator - 6th Release

[Pearu P. <pe...@ce...>]

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

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

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

Download source:

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

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

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

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

- Improved wrapping C functions with F2PY.

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

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

- F2PY has new site for unit testing.

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

    Absoft Sun SGI Intel Itanium NAG Compaq Digital Gnu VAST

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

Enjoy,
	Pearu Peterson

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

Re: [Numpy-discussion] Numeric Python EM Project supposed to be in Dec IEEE A & P Magazine

[Rob <ro...@py...>]

Rob wrote:
> 
> It should be in the educational corner.  I've beefed up the intro to the
> site.  Will be interesting to see if I get many new hits.  Rob.
> --
> -----------------------------
> The Numeric Python EM Project
> 
> www.pythonemproject.com
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

It was supposed to be in A & P magazine all the way back in June, but
the editors goofed up, and profusely apologized :)  Rob.

-- 
-----------------------------
The Numeric Python EM Project

www.pythonemproject.com

[Numpy-discussion] Numeric Python EM Project supposed to be in Dec IEEE A & P Magazine

[Rob <ro...@py...>]

It should be in the educational corner.  I've beefed up the intro to the
site.  Will be interesting to see if I get many new hits.  Rob.
-- 
-----------------------------
The Numeric Python EM Project

www.pythonemproject.com

Re: [Numpy-discussion] PEP 242 Numeric kinds

[Chris B. <Chr...@no...>]

José Fonseca wrote:
> to say that the manipulation of numeric
> arrays is only of interest to scientific programmers is the same of when
> in the early computing days engineers saing that computers would only be
> good for crunching numbers, and that the concept of personal computers
> was just non-sense...

I absolutely concur.
 
> For a non-scientic usage of Numeric see the examples in
> http://www.pygame.org/pcr/repository.php, but I can imagine the
> usefullness of Numeric in many more non-scientific applications:
> imaging, sound visualization plugins, 3D graphics, and probably much
> more.

It goes MUCH farther than this. All these examples are what I would call
serious number crunching. Perhaps not strictly scientific, but certainly
the realm of numeric programming, and all places where the "kinds"
concept would be useful.

However, there is a great deal of usefulness in Numeric for applications
that are not doing a lot of number crunching. Performance is only one
reason to use Numeric. The other reason is much cleaner and easier
syntax for manipulating arrays of numbers, especially ones of more than
one dimension. Being able to slice across multiple dimensions, array
oriented arithmetic, overloaded comparisons, etc. I use Numeric for
virtually every program I write, whether performance is an issue or not.
Not having to write all those ugly, confusing and error prone loops is a
godsend.

All that being said, the "kinds" concept is probably mostly of concern
to the Number crunching community. However, it is also sort of a low
level concept, and having it part of core language makes sense, just
like it makes sense to have complex number and long integers in the core
language.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[Numpy-discussion] Re: [Python-Dev] PEP 242 Numeric kinds

[Michael M. <mc...@ni...>]

On Friday 06 December 2002 02:12 am, Brett Cannon wrote:
> [Paul F Dubois]
>
> > We had put off consideration of PEP 242 Numeric kinds until June 2002
> > when a meeting of some interested parties was to occur but the meeting
> > didn't occur. 
[...] 
> I just want to be able to add up a bunch of money values and not have a
> few pennies disappear in the end; usually I am the one who has to eat the
> loss and I am an poor college graduate who can't afford the rounding.  =)

Does the kinds implementation work with binary floats and decimal numbers? 
From a quick scan of the PEP it looks like it is only binary floats. If it 
only applies to binary numbers then the kinds capability will not eliminate 
decimal number rounding errors. That problem will require extending Python to 
include a decimal number type. 

The abstract mentions a clarification of decimal literals, but I suspect Paul 
was not suggesting that the numbers defined by kinds will use decimal 
arithmetic instead of binary arithmetic.

[Numpy-discussion] Re: [Python-Dev] PEP 242 Numeric kinds

[Brett C. <ba...@OC...>]

[Paul F Dubois]

> We had put off consideration of PEP 242 Numeric kinds until June 2002
> when a meeting of some interested parties was to occur but the meeting
> didn't occur. I have a draft implementation and users of it but my
> feeling is that although correct and useful the PEP is not useful enough
> to put it in the standard library. Since it really only interests
> scientific programmers I propose simply making it a separate deliverable
> on the Numeric site and withdrawing the PEP.
>

I say add it.  If there are already users out there then that demonstrates
as least some form of a demand.

Besides, if rationals can get into the library (that module was finally
accepted to be added to the library, right?) then a module to help do
consistent decimal math should at least be included at least until the
Python core can move to C99 (if I am remembering a comment from Tim saying
that C99 adds more explicit numeric types, e.g., exactly 2 byte float).

I just want to be able to add up a bunch of money values and not have a
few pennies disappear in the end; usually I am the one who has to eat the
loss and I am an poor college graduate who can't afford the rounding.  =)

-Brett

[Numpy-discussion] Re: [Python-Dev] PEP 242 Numeric kinds

[Raymond H. <py...@rc...>]

> I have a draft implementation and users of it but my
> feeling is that although correct and useful the PEP is not useful enough
> to put it in the standard library. Since it really only interests
> scientific programmers I propose simply making it a separate deliverable
> on the Numeric site and withdrawing the PEP.

As the PEP author, your feeling is probably the most accurate.
And, it is true that Kinds will, in general, appeal to the same crowd 
as Numeric.

OTOH, "import kinds" is entirely unobtrusive and general purpose.
The interface is simple; and may help some code become less platform
sensitive (in the way the Metafont writes its own portable routines to 
create consistent lettering); and it has some educational value (making
it easy to demonstrate the effects of truncation and floating point
round-off).  

Also, I think accounting applications can benefit from having some
positive assurance that multi-billion dollar calculations don't lose 
their pennies and that the books will still balance.

So, the only downside is having an additional block of code to 
maintain.  My vote is for adding it to the standard library.  Control
over precision is more of a core capability than it is an extension,
but, as the PEP author and principal user, you probably know best.

'nuff said,


Raymond Hettinger


#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################

Re: [Numpy-discussion] PEP 242 Numeric kinds

[F. <j_r...@ya...>]

On Thu, Dec 05, 2002 at 05:02:26PM -0800, Paul F Dubois wrote:
> Since it really only interests
> scientific programmers I propose simply making it a separate deliverable
> on the Numeric site and withdrawing the PEP.

I'm not fully aware about the advantages/implications of puting Numeric
in Python standard library, but to say that the manipulation of numeric
arrays is only of interest to scientific programmers is the same of when
in the early computing days engineers saing that computers would only be
good for crunching numbers, and that the concept of personal computers
was just non-sense...

For a non-scientic usage of Numeric see the examples in
http://www.pygame.org/pcr/repository.php, but I can imagine the
usefullness of Numeric in many more non-scientific applications:
imaging, sound visualization plugins, 3D graphics, and probably much
more.

The use of Numeric can speed up alot of algorithms which would be
otherwise very slow in pure Python, and therefore forcing one to write C
extensions. That's why IMHO something with the Numeric functionality
should exist in the Python standard library.

Note that this is not the same that saying that Numeric should be
included as is - perhaps it's better to have it seperately to let it
mature more, perhaps not - but still, there is much more than a niche
interest around it.

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

[Numpy-discussion] PEP 242 Numeric kinds

[Paul F D. <pa...@pf...>]

We had put off consideration of PEP 242 Numeric kinds until June 2002
when a meeting of some interested parties was to occur but the meeting
didn't occur. I have a draft implementation and users of it but my
feeling is that although correct and useful the PEP is not useful enough
to put it in the standard library. Since it really only interests
scientific programmers I propose simply making it a separate deliverable
on the Numeric site and withdrawing the PEP.

Re: [Numpy-discussion] howto build numarray 0.4 ? file 'Src/_convmodule.c' does not exist

[Sebastian H. <ha...@ms...>]

> On Tue, Dec 03, 2002 at 02:34:06PM -0800, Sebastian Haase wrote:
> > Hi all,
> > I downloaded numarray 0.4 about 5 minutes after I got the announce but
> > my naive 'python2.2 ./setup.py build'   gives this
> >
> > haase@baboon:~/numarray-0.4: python2.2 ./setup.py build
> > running build
> > running build_py
> > not copying Lib/ndarray.py (output up-to-date)
> [...]
> > not copying Lib/memmap.py (output up-to-date)
> > running build_ext
> > building '_conv' extension
> > error: file 'Src/_convmodule.c' does not exist
> >
> > What am I missing? I'm running Linux (debian woody) on i386.
>
> Looks like you have to run 'python2.2 ./setup.py install' instead. Looking
at
> setup.py, something special is done when the target is 'install'.
>
> [I think this is a bad idea, as I like to build stuff as my user, and
> install as root. This requires me to build it as root.]

I just tried it (actually as user not root!!) and it runs through up to a
"cannot create directory..." error.
That's probably fine with me (for now) and I'm just setting PYTHONPATH ...

Thanks again, Sebastian.