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

[Numpy-discussion] RE: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

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

Some one suggested that numarray ditch compatibility in this 
area and "do what's right". Namely he suggested that

nonzero --> where
where   --> select

I have to agree that these are far better names than the
existing ones. But compatibilty is important. So what to do?

Here's one suggestion; I'm curious what people think about
this solution. Nothing prevents us from having a module that
people would import for Numeric compatibilty and a different one
that has somewhat different behavior. Before people start throwing
rocks (when you finish reading you can throw them ;-) and say "didn't
you say that customized versions of Numeric or numarray were a 
bad idea?" Yes I did. But I think some customizations are bad
and perhaps some are acceptable.

What I objected to was having array objects with different behavior
Since array objects may be passed between modules that assume
different behaviors, that will cause all sorts of problems
(e.g., module A was written assuming array slices are views
but is passed an array that produces a copy when sliced).

But is there any harm when all that is different are module functions?
These are unlikely to be passed from one module to another and thus
the customization is localized to the user modules. Suppose that
the Numeric-compatible version defines "where" and "nonzero" to have
their current meanings and numarray uses "select", and "where" 
respectively.

There is one case that could arise that might cause problems. About
the only time a problem would occur is if someone did 

from numarray import *
from B import *

And in B.py

from Numericcompatible import *

in which case the numarray "where" is replaced by the Numeric "where"

I don't know if this is a strong enough reason to support two different
flavors, but what do people think of taking this approach? Are there
any other module functions that would benefit from such changes in name
or behavior (For example, the axis order issue)?

Perry Greenfield

Re: [Numpy-discussion] Numarray 0.5

[Todd M. <jm...@st...>]

On Wed, 2003-05-07 at 05:16, Peter Verveer wrote:
> > > I am not sure if this is a bug, or intended behaviour, but the possibilty
> > > to compare an array type object to 'Any' would be very useful for me.
> >
> > 'Any' grew up from the C-API,  rather than down from the Python design,
> > so it's not very well thought out.  Right now,  it is a placeholder used
> > to mark arrays with undefined types and to indicate "no type constraint"
> > in C API calls.  In normal contexts,   you can't make an array of type
> > 'Any'.  I think there are two reasonable behaviors for comparisons with
> > 'Any',  both used in C.   The first behavior is literal comparison; here
> > comparison to Any would generally return "not equal".  The second
> > behavior is wild-card matching; here, comparison to Any would generally
> > return "equal".   Which makes sense to you?  How do you want to use
> > this?
> 
> I use 'Any' right now in C functions to indicate 'no type constraint'. You 
> could use both literal comparison and wild-card matching behaviour for that, 
> if you want to do this in Python, I think. But maybe one should not do such a 
> thing in Python by comparison to 'Any' at all.
> 
> Literal comparison is what I generally expect from Python objects, so anything 
> else may just be confusing (at least to me). However, the name 'Any' does 
> suggest the wild-card matching behaviour. 
> 
> Is there specific reason why you exposed 'Any' in python?

Initially it was not exposed.  As the API type functions evolved, it
made Any less of a special case to expose it.

> Maybe it would be 
> better not to expose such a type object since it seems to be a 'special 
> case'. I am starting to think that my use for it at the Python level is not 
> appropiate. 
> For instance, I could easily use 'None' instead, and I think I 
> will do that in the future. 

Yes.  That's probably what I should have done in C as well: tNone rather
than tAny.

> 
> You mentioned that 'Any' is really a C-API thing. Unless somebody has a good 
> use for it I would now actually say that it maybe should not be exposed at 
> the Python API level at all...

I agree with this.  It might be as simple as renaming it to _Any in
Python, but I still hesitate to change this until I have a little more
time to think about it.  Too often, things go from "bad" to "not so
good"...

Thanks for the input,
Todd

[Numpy-discussion] numarray 0.5 bug

[Peter V. <ve...@em...>]

In numarray 0.5, the PyArray_ContiguousFromObject() does not appear to wo=
rk=20
correctly with Python scalar objects, if the requested type is not equal =
to=20
the type of the object. (I believe that this function should convert the=20
input to an array of the requested type?)

For instance, PyArray_ContiguousFromObject(object, tInt32, 0, 1))) works=20
correctly if object is a python integer, but not if it is a float number.

Cheers, Peter

--=20
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
EMBL
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387242
Email: Pet...@em...

Re: [Numpy-discussion] Numarray 0.5

[Peter V. <ve...@em...>]

> > I am not sure if this is a bug, or intended behaviour, but the possib=
ilty
> > to compare an array type object to 'Any' would be very useful for me.
>
> 'Any' grew up from the C-API,  rather than down from the Python design,
> so it's not very well thought out.  Right now,  it is a placeholder use=
d
> to mark arrays with undefined types and to indicate "no type constraint=
"
> in C API calls.  In normal contexts,   you can't make an array of type
> 'Any'.  I think there are two reasonable behaviors for comparisons with
> 'Any',  both used in C.   The first behavior is literal comparison; her=
e
> comparison to Any would generally return "not equal".  The second
> behavior is wild-card matching; here, comparison to Any would generally
> return "equal".   Which makes sense to you?  How do you want to use
> this?

I use 'Any' right now in C functions to indicate 'no type constraint'. Yo=
u=20
could use both literal comparison and wild-card matching behaviour for th=
at,=20
if you want to do this in Python, I think. But maybe one should not do su=
ch a=20
thing in Python by comparison to 'Any' at all.

Literal comparison is what I generally expect from Python objects, so any=
thing=20
else may just be confusing (at least to me). However, the name 'Any' does=
=20
suggest the wild-card matching behaviour.=20

Is there specific reason why you exposed 'Any' in python? Maybe it would =
be=20
better not to expose such a type object since it seems to be a 'special=20
case'. I am starting to think that my use for it at the Python level is n=
ot=20
appropiate. For instance, I could easily use 'None' instead, and I think =
I=20
will do that in the future.=20

You mentioned that 'Any' is really a C-API thing. Unless somebody has a g=
ood=20
use for it I would now actually say that it maybe should not be exposed a=
t=20
the Python API level at all...

Cheers, Peter
=20
--=20
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
EMBL
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387242
Email: Pet...@em...

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Agustin L. <al...@ij...>]

I meant "suchthat" (not "suchdat"), of course. The "spanglish" spelling
would be confusing for others!
Agus


On Wed, 7 May 2003, Agustin Lobo wrote:

> suchdat would make the programs much easier
> to read, very good idea.
> 
> Agus
> 
> Dr. Agustin Lobo
> Instituto de Ciencias de la Tierra (CSIC)
> Lluis Sole Sabaris s/n
> 08028 Barcelona SPAIN
> tel 34 93409 5410
> fax 34 93411 0012
> al...@ij...
> 
> 
> On 6 May 2003, Stan Heckman wrote:
> 
> > "Perry Greenfield" <pe...@st...> writes:
> > 
> > > Any objections to using "at"? 
> > 
> > no, "at" reads reasonably well.
> > 
> > > Any better suggestions.
> > 
> > "suchthat"?
> > 
> > -- 
> > Stan
> > _______________________________________________
> > SciPy-user mailing list
> > Sci...@sc...
> > http://www.scipy.net/mailman/listinfo/scipy-user
> > 
> _______________________________________________
> SciPy-user mailing list
> Sci...@sc...
> http://www.scipy.net/mailman/listinfo/scipy-user
> 

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Agustin L. <al...@ij...>]

suchdat would make the programs much easier
to read, very good idea.

Agus

Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
al...@ij...


On 6 May 2003, Stan Heckman wrote:

> "Perry Greenfield" <pe...@st...> writes:
> 
> > Any objections to using "at"? 
> 
> no, "at" reads reasonably well.
> 
> > Any better suggestions.
> 
> "suchthat"?
> 
> -- 
> Stan
> _______________________________________________
> SciPy-user mailing list
> Sci...@sc...
> http://www.scipy.net/mailman/listinfo/scipy-user
> 

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Stan H. <st...@st...>]

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

> Any objections to using "at"? 

no, "at" reads reasonably well.

> Any better suggestions.

"suchthat"?

-- 
Stan

Re: [Numpy-discussion] Numarray 0.5

[Todd M. <jm...@st...>]

On Tue, 2003-05-06 at 08:24, Peter Verveer wrote:
> Hi All,
> 
> I found the following problems after testing my software with numarray 0.5:
> 
> 1) Following works fine if both a and b are arrays:
> 
> >>> a = array([2])
> >>> b = array([1, 2])
> >>> print a + b
> [3 4]
> 
> However, if b is an python sequence:
> 
> >>> a = array([2])
> >>> b = [1, 2]
> >>> print a + b
> [3]
> 
> Apparently broadcasting does not work with python sequeces anymore. This used 
> to work fine in version 0.4. Is this a bug?

Yes, unfortunately.  Thanks for reporting it!

> 
> 2) It is not possible to compare an array type object to the 'Any' object:
> 
> >>> Float64 == Any
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.2/site-packages/numarray/numerictypes.py", line 
> 112, in __cmp__
>     return (genericTypeRank.index(self.name) -
> ValueError: list.index(x): x not in list
> 
> I am not sure if this is a bug, or intended behaviour, but the possibilty to 
> compare an array type object to 'Any' would be very useful for me.
> 

'Any' grew up from the C-API,  rather than down from the Python design,
so it's not very well thought out.  Right now,  it is a placeholder used
to mark arrays with undefined types and to indicate "no type constraint"
in C API calls.  In normal contexts,   you can't make an array of type
'Any'.  I think there are two reasonable behaviors for comparisons with
'Any',  both used in C.   The first behavior is literal comparison; here
comparison to Any would generally return "not equal".  The second
behavior is wild-card matching; here, comparison to Any would generally
return "equal".   Which makes sense to you?  How do you want to use
this?

> 3) The NA_typeNoToTypeObject() function fails if it is called before any 
> arrays are created. It looks to me as if the pNumType array in 
> libnumarraymodule.c is not initialized until an array is created. I don't 
> know if any other functions are affected in the same way. Could this be 
> fixed?

Yes.  This is fixed now in CVS.  Thanks again!

> 
> Cheers, Peter
> 
> -- 
> Dr. Peter J. Verveer
> Cell Biology and Cell Biophysics Programme
> EMBL
> Meyerhofstrasse 1
> D-69117 Heidelberg
> Germany
> Tel. : +49 6221 387245
> Fax  : +49 6221 387242
> Email: Pet...@em...
> 
> 
> 
> 
> -------------------------------------------------------
> 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
-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

Re: [Numpy-discussion] Question about numarray Bool type

[Todd M. <jm...@st...>]

On Tue, 2003-05-06 at 12:16, Francesc Alted wrote:
> Mensaje citado por: Peter Verveer <ve...@em...>:
> > > >That would be somewhat
> > > >simpler if Bool is always garantueed to be either a unsigned or a
> > signed
> > > > char type.
> > >
> > > I think perhaps we should just re-define Bool as signed char.  Any
> > other
> > > opinions?
> > 
> > That would solve the problem.
> 
> I'm in the same position than Peter. I would definitively prefer a standard C 
> type for booleans.
> 
> Francesc Alted
> 

I re-defined Bool as signed char in CVS.   Without any real expertise in
Boolology <ahem>,  I am unqualified to comment further.  Let me know if
you would like something different.

Todd

> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Fernando P. <fp...@co...>]

Fernando Perez wrote:

> I rely on this fact all the time, by first building packages and then calling 
> 'setup.py install' separately.  And I do this as a non-root user always.

Clarification: I call 'build' as non-root, then 'install' as root.  Same as doing:

make
su
make install

in python it's

setup.py build
su
setup.py install

Cheers,

f.

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Fernando P. <fp...@co...>]

Todd Miller wrote:

>>Here's a couple work arounds I use:
>>
>>1) When trying to install to /usr/lib,  I first "su root".
>>
>>2) When I don't like to or can't "su root",  I first install Python in 
>>my home directory using: "./configure --prefix=$HOME".  With a local 
>>Python, site-packages is also local and writeable by default.
>>
>>That said, setup.py has some kludges in it that need to be eliminated 
>>or factored out.
>>
>>Todd
>>
> 
> A third method,  a little less onerous than the first two, is:
> 
> 3) mkdir $HOME/numarray;  python setup.py build --gencode 
> --local=$HOME/numarray
> 
> This works OK even if you're using a Python which does not have a 
> writeable site-packages directory.

My apologies if I'm off-base, but I'm pretty sure that a properly written 
setup.py should not try to write anywhere but in the build/ subdirectory when 
invoked with the 'build' option.  It should only write in site-packages when 
called with 'install'.

I rely on this fact all the time, by first building packages and then calling 
'setup.py install' separately.  And I do this as a non-root user always.

I could be wrong, but if setup.py is trying to write at build (not install) 
time into /usr/lib/..., I think that should be considered a bug.

Best,

f.

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Todd M. <jm...@st...>]

Todd Miller wrote:

> Sebastian Haase wrote:
>
>> Hi,
>> I just tried this :
>> haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
>> <snip>
>>
>> creating /usr/lib/python2.2/site-packages/numarray
>> error: could not create '/usr/lib/python2.2/site-packages/numarray':
>> Permission denied
>>
>> I guess this is the same bug I ran into a couple month ago - I 
>> already now a
>> workaround ...
>>
>> - Sebastian
>>  
>>
> Here's a couple work arounds I use:
>
> 1) When trying to install to /usr/lib,  I first "su root".
>
> 2) When I don't like to or can't "su root",  I first install Python in 
> my home directory using: "./configure --prefix=$HOME".  With a local 
> Python, site-packages is also local and writeable by default.
>
> That said, setup.py has some kludges in it that need to be eliminated 
> or factored out.
>
> Todd
>
A third method,  a little less onerous than the first two, is:

3) mkdir $HOME/numarray;  python setup.py build --gencode 
--local=$HOME/numarray

This works OK even if you're using a Python which does not have a 
writeable site-packages directory.

>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Todd M. <jm...@st...>]

Sebastian Haase wrote:

>Hi,
>I just tried this :
>haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
><snip>
>
>creating /usr/lib/python2.2/site-packages/numarray
>error: could not create '/usr/lib/python2.2/site-packages/numarray':
>Permission denied
>
>I guess this is the same bug I ran into a couple month ago - I already now a
>workaround ...
>
>- Sebastian
>  
>
Here's a couple work arounds I use:

1) When trying to install to /usr/lib,  I first "su root".

2) When I don't like to or can't "su root",  I first install Python in 
my home directory using: "./configure --prefix=$HOME".  With a local 
Python, site-packages is also local and writeable by default.

That said, setup.py has some kludges in it that need to be eliminated or 
factored out.

Todd

Re: [Numpy-discussion] Question about numarray Bool type

[Francesc A. <fa...@op...>]

Mensaje citado por: Peter Verveer <ve...@em...>:
> > >That would be somewhat
> > >simpler if Bool is always garantueed to be either a unsigned or a
> signed
> > > char type.
> >
> > I think perhaps we should just re-define Bool as signed char.  Any
> other
> > opinions?
> 
> That would solve the problem.

I'm in the same position than Peter. I would definitively prefer a standard C 
type for booleans.

Francesc Alted

Re: [Numpy-discussion] Question about numarray Bool type

[Peter V. <ve...@em...>]

On Tuesday 06 May 2003 17:48, Todd Miller wrote:
> Peter Verveer wrote:
> >Hi,
> >
> >In the numarray source code Bool is defined as a typedef to char. Does=
 the
> >Bool array type correspond to the Int8, or the UInt8 type? If I recall
> >correctly, the char type may be signed or unsigned. Can I make any
> >assumptions about the C type used to implement Bool at all?
>
> Yes!  It's named Bool.  :)

Obviously, but then I need to include the numarray include file to make s=
ure I=20
get the right definition, and I do not always want to do that. See below.

> >I guess at the Python level it does not matter what actual C type is u=
sed
> > to implement bool arrays as it only represents boolean values. Howeve=
r,
> > at the level of C extensions I would like to deal with Bool arrays by
> > calling existing functions written for the appropiate C type.
>
> The easiest way now is to just declare your variables with type "Bool".
>  The only thing I can think of which that doesn't cover is printf/scanf=
=2E
>   Are there others?

This does not work if you want to call a routine that was not written usi=
ng=20
the numarray typedefs. For instance, I like to write my array processing=20
routines such that I can use them in a standalone C program without linki=
ng=20
to numarray. These routines know nothing about numarray, but as long as t=
he=20
layout and data types of the arrays are correct I can still use them in=20
numarray C routines. Then you need to know of course exactly what the C d=
ata=20
types of the numarray routines are. That is easy for most types since the=
y=20
are exactly defined by bit-size and sign. But this is currently not true =
for=20
the Bool type.

> >That would be somewhat
> >simpler if Bool is always garantueed to be either a unsigned or a sign=
ed
> > char type.
>
> I think perhaps we should just re-define Bool as signed char.  Any othe=
r
> opinions?

That would solve the problem.

Peter

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

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

The reason that I always try "setup.py BUILD" first is that I don't have
root permissions on that machine - so this is a quite important "test" for
me.
Thanks,
Sebastian

----- Original Message ----- 
From: "Francesc Alted" <fa...@op...>
To: "Sebastian Haase" <ha...@ms...>;
<num...@li...>
Sent: Tuesday, May 06, 2003 7:19 AM
Subject: Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails


I guess this is a problem with permissions. It seems like if setup.py is
trying to install numarray on the Python site-packages directory. It should
not, but meanwhile, run this command as root and it should works. Ah!, do
not forget to delete (or better, move) the old site-packages/numarray in
order to do a problem-free fresh installation. Remember:

> > 1. Due to some module renamings, numarray-0.5 will not install
> > correctly on top of an existing numarray installation. Before
> > installing numarray-0.5 remove your old version of numarray.

Cheers,

A Dimarts 06 Maig 2003 03:24, Sebastian Haase va escriure:
> Hi,
> I just tried this :
> haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
> <snip>
>
> creating /usr/lib/python2.2/site-packages/numarray
> error: could not create '/usr/lib/python2.2/site-packages/numarray':
> Permission denied
>
> I guess this is the same bug I ran into a couple month ago - I already now
> a workaround ...
>
> - Sebastian
>

-- 
Francesc Alted


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Numpy-discussion mailing list
Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Question about numarray Bool type

[Todd M. <jm...@st...>]

Peter Verveer wrote:

>Hi,
>
>In the numarray source code Bool is defined as a typedef to char. Does the 
>Bool array type correspond to the Int8, or the UInt8 type? If I recall 
>correctly, the char type may be signed or unsigned. Can I make any 
>assumptions about the C type used to implement Bool at all?
>
Yes!  It's named Bool.  :)

>I guess at the Python level it does not matter what actual C type is used to 
>implement bool arrays as it only represents boolean values. However, at the 
>level of C extensions I would like to deal with Bool arrays by calling 
>existing functions written for the appropiate C type. 
>
The easiest way now is to just declare your variables with type "Bool". 
 The only thing I can think of which that doesn't cover is printf/scanf. 
  Are there others?

>That would be somewhat 
>simpler if Bool is always garantueed to be either a unsigned or a signed char 
>type. 
>
I think perhaps we should just re-define Bool as signed char.  Any other 
opinions?

>
>Cheers, Peter.
>
>  
>
Todd

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Francesc A. <fa...@op...>]

I guess this is a problem with permissions. It seems like if setup.py is
trying to install numarray on the Python site-packages directory. It shou=
ld
not, but meanwhile, run this command as root and it should works. Ah!, do
not forget to delete (or better, move) the old site-packages/numarray in
order to do a problem-free fresh installation. Remember:

> > 1. Due to some module renamings, numarray-0.5 will not install
> > correctly on top of an existing numarray installation. Before
> > installing numarray-0.5 remove your old version of numarray.

Cheers,

A Dimarts 06 Maig 2003 03:24, Sebastian Haase va escriure:
> Hi,
> I just tried this :
> haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
> <snip>
>
> creating /usr/lib/python2.2/site-packages/numarray
> error: could not create '/usr/lib/python2.2/site-packages/numarray':
> Permission denied
>
> I guess this is the same bug I ran into a couple month ago - I already =
now
> a workaround ...
>
> - Sebastian
>

--=20
Francesc Alted

[Numpy-discussion] Question about numarray Bool type

[Peter V. <ve...@em...>]

Hi,

In the numarray source code Bool is defined as a typedef to char. Does th=
e=20
Bool array type correspond to the Int8, or the UInt8 type? If I recall=20
correctly, the char type may be signed or unsigned. Can I make any=20
assumptions about the C type used to implement Bool at all?

I guess at the Python level it does not matter what actual C type is used=
 to=20
implement bool arrays as it only represents boolean values. However, at t=
he=20
level of C extensions I would like to deal with Bool arrays by calling=20
existing functions written for the appropiate C type. That would be somew=
hat=20
simpler if Bool is always garantueed to be either a unsigned or a signed =
char=20
type.=20

Cheers, Peter.

--=20
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
EMBL
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387242
Email: Pet...@em...

[Numpy-discussion] Numarray 0.5

[Peter V. <ve...@em...>]

Hi All,

I found the following problems after testing my software with numarray 0.=
5:

1) Following works fine if both a and b are arrays:

>>> a =3D array([2])
>>> b =3D array([1, 2])
>>> print a + b
[3 4]

However, if b is an python sequence:

>>> a =3D array([2])
>>> b =3D [1, 2]
>>> print a + b
[3]

Apparently broadcasting does not work with python sequeces anymore. This =
used=20
to work fine in version 0.4. Is this a bug?

2) It is not possible to compare an array type object to the 'Any' object=
:

>>> Float64 =3D=3D Any
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/numarray/numerictypes.py",=
 line=20
112, in __cmp__
    return (genericTypeRank.index(self.name) -
ValueError: list.index(x): x not in list

I am not sure if this is a bug, or intended behaviour, but the possibilty=
 to=20
compare an array type object to 'Any' would be very useful for me.

3) The NA_typeNoToTypeObject() function fails if it is called before any=20
arrays are created. It looks to me as if the pNumType array in=20
libnumarraymodule.c is not initialized until an array is created. I don't=
=20
know if any other functions are affected in the same way. Could this be=20
fixed?

Cheers, Peter

--=20
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
EMBL
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387242
Email: Pet...@em...

Re: [Numpy-discussion] Python global interpreter lock ...

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

On Wednesday 30 April 2003 08:47, Andrew P. Lentvorski, Jr. wrote:

> 1) Does numpy (or numarray) release the Python GIL?

No.

> 2) If not, why not?  Is this simply something I could fix by making the
> changes myself, or are there larger reasons for not releasing the GIL?

There is one good reason, which is that the GIL release code doesn't nest=
=2E If=20
NumPy released the GIL during its operations, then any C code that uses N=
umPy=20
functions would have to reacquire the GIL before calling NumPy, then=20
re-release the GIL afterwards. In most real-life situations, it is simple=
r=20
and presumably more efficient to release the GIL once for a block of=20
numerical computations, which would include many calls to NumPy functions=
=2E

One could of course release the GIL not within the functions that are par=
t of=20
the NumPy C API, but in a thin wrapper around it that is directly called =
from=20
Python.

The only other problem that I see is the general object type arrays, whic=
h=20
make calls back into the Python interpreter.

Konrad.
--=20
-------------------------------------------------------------------------=
------
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] numarray 0.5 -> python setup.py build fails

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

Hi,
I just tried this :
haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
<snip>

creating /usr/lib/python2.2/site-packages/numarray
error: could not create '/usr/lib/python2.2/site-packages/numarray':
Permission denied

I guess this is the same bug I ran into a couple month ago - I already now a
workaround ...

- Sebastian



----- Original Message ----- 
From: "Todd Miller" <jm...@st...>
To: <num...@li...>
Sent: Monday, May 05, 2003 5:11 AM
Subject: [Numpy-discussion] Numarray-0.5 released


> Release Notes for numarray-0.5
>
> Numarray is an array processing package designed to efficiently
> manipulate large multi-dimensional arrays.  Numarray is modelled after
> Numeric and features c-code generated from python template scripts,
> the capacity to operate directly on arrays in files, and improved type
> promotions.
>
> I. ENHANCEMENTS
>
> 1. Universal Function Overhead Reduction
>
> The constant time overhead for most universal functions has been reduced
> by a factor of 10-20.  This results in better performance for small
> arrays.
>
> 2. FFT mode and IRAF boundary modes added to Convolve.convolve2d
>
> There's now an FFT switch for the 2d convolution function in the
> Convolve package; when set to 1, convolution is performed via the FFT
> rather than using the naiive algorithm.  In addition, convolve2d now
> supports boundary modes which are identical to IRAF's convolution
> function.
>
> 3. Numarray is now supported by f2py
>
> Numarray numerical arrays can now be used with f2py wrappers for
> Fortran code.  To compile f2py wrapped extensions for numarray,
> use the switch -DNUMARRAY on the f2py command line. Support
> is currently limited to f77 and numerical arrays.
>
>
> II. BUGS FIXED
>
> 650926        exotic type coercions
> 653424        Convolve.boxcar boundary bug
> 653429        python setup.py build
> 654669        array index by list
> 655942        logical operator reductions
> 657058        inverse real fft bug
> 677796         byteswap not working
> 709956        error summing over large boolean arrays
> 710480        MLab.median makes unnecessary msort call
> 714537        conjugate function changes its argument
>
> See
> http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse
> for more details.
>
> III. CAUTIONS
>
> 1. Due to some module renamings, numarray-0.5 will not install
> correctly on top of an existing numarray installation. Before
> installing numarray-0.5 remove your old version of numarray.
>
> 2. Due to reorganization of the C-API, numarray extensions must be
> recompiled.
>
> 3. For numarray-0.5 and up, the byteswap related methods have been
> redefined:
>
> a.byteswap()                   swaps but leaves byteorder alone
> a.togglebyteorder()            Does "big" <-> "little"
> a._byteswap()                  now an alias for byteswap
> a._togglebyteorder()           deleted
>
> 4. round() has been deprecated.  Use around() instead.
>
> 5. Installing from source, the first time you run setup.py, you must
> specify --gencode, e.g.:  python setup.py install --gencode
>
> WHERE
> -----------
>
> Numarray-0.5 windows executable installers, source code, and manual is
> here:
>
> http://sourceforge.net/project/showfiles.php?group_id=1369
>
> Numarray is hosted by Source Forge in the same project which hosts
> Numeric:
>
> http://sourceforge.net/projects/numpy/
>
> The web page for Numarray information is at:
>
> http://stsdas.stsci.edu/numarray/index.html
>
> Trackers for Numarray Bugs, Feature Requests, Support, and Patches are
> at
> the Source Forge project for NumPy at:
>
> http://sourceforge.net/tracker/?group_id=1369
>
> REQUIREMENTS
> ------------------------------
>
> numarray-0.5 requires Python 2.2.2 or greater.
>
>
> AUTHORS, LICENSE
> ------------------------------
>
> Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC
> Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science
> Institute.  Thanks go to Jochen Kupper of the University of North
> Carolina for his work on Numarray and for porting the Numarray manual
> to TeX format.  Thanks also to Edward C. Jones, Francesc Alted,
> Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson and everyone
> who has contributed with comments and feedback.
>
> Numarray is made available under a BSD-style License.  See
> LICENSE.txt in the source distribution for details.
>
> -- 
> Todd Miller jm...@st...
> STSCI / ESS / SSB
>
>
>
> -------------------------------------------------------
> 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
>

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

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

On Mon, 5 May 2003, Perry Greenfield wrote:

> Any objections to using "at"? Any better suggestions.

For me 'wheretrue' sounds most accurate but I agree, it's longish.

Its short form 'where' is less accurate (because of its general
meaning) but not too confusing.

At first, 'at' confused me a little... until I figured out its long
version 'trueat'.

Hmm, I have always assumed that 'nonzero(x)' means elementwise 
'not not x' (like Python __nonzero__ is equivalent to 'not not') and
therefore never felt the need to use it.
But now I see I was wrong! So, 'nonzero' sounded and still 
sounds misleading for me.

For 'nz' I am -1 because 'nz' can often be a suitable variable name.

In summary, I would like 'trueat' the most and 'nonzero' the least.
'where' and 'at' (in that order) are somewhere in between.

Pearu

[Numpy-discussion] [numarray issue] nonzero? Comments on new name solicited

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

[In the next week or so I am going to be raising some issues
regarding the next numarray release, 0.6. By the way, we keep the
version number less than 1.0 because we still hold out the
possiblity of changing some interface issues (generally it has
been in the direction of making numarray more compatible with
Numeric). The following raises one of these interface issues.

numarray has a more general approach to the nonzero function 
than does Numeric. It is able to return multiple index arrays
for multidimensional arrays (where as nonzero only works for
1-d arrays). In the interest of giving a more generic interface
for the function, numarray always returns the index array(s)
as part of a tuple, even if the argument to nonzero is 1-D and
there is only one resulting index array.

However, this is a problem for Numeric old code that uses nonzero
and expects an array instead of a tuple. The sensible thing to do
is to retain  compatibilty with the Numeric nonzero (and likewise
only  support 1-d arrays). So we need a new name for our new nonzero
function. To tell you the truth, I always felt that nonzero
was a terrible name anyway and much preferred the name that
IDL used for that function, namely "where". Alas, "where" is
already used for another purpose in Numeric. But to illustrate,
which is clearer?

x[nonzero(x > 0.)] = 0.

or

x[where(x > 0.)] = 0

So, we considered some other alternatives, in particular

nz
wheretrue 

but our favorite is: "at". For example:

x[at(x > 0.)] = 0.

This has the benefit of being short and having a fairly clear
meaning. Short is important since it will keep expressions
of arrays using index arrays short and more readable.

True, this is more likely to conflict with existing user variable or
function names,  but if one is simply trying to use existing files,
then there is no problem since they won't need the "at" function since
its functionality was not previously available.

Any objections to using "at"? Any better suggestions.

Of course, these changes will break existing numarray code that
use the nonzero function.

Perry Greenfield

[Numpy-discussion] http://stsdas.stsci.edu/numarray outdated

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

Hi all,
I'm happy to hear about the new release !
Could someone put this information on the web ?
http://stsdas.stsci.edu/numarray/
still dates to 2002 Aug (which is before 0.4 !!)

Or is this page the wrong page anyway -- I just end up there because google
points into that direction when you ask for 'numarray'

Thanks for the great work.
Sebastian




----- Original Message ----- 
From: "Todd Miller" <jm...@st...>
To: <num...@li...>
Sent: Monday, May 05, 2003 5:11 AM
Subject: [Numpy-discussion] Numarray-0.5 released


> Release Notes for numarray-0.5
>
> Numarray is an array processing package designed to efficiently
> manipulate large multi-dimensional arrays.  Numarray is modelled after
> Numeric and features c-code generated from python template scripts,
> the capacity to operate directly on arrays in files, and improved type
> promotions.
>
> I. ENHANCEMENTS
>
> 1. Universal Function Overhead Reduction
>
> The constant time overhead for most universal functions has been reduced
> by a factor of 10-20.  This results in better performance for small
> arrays.
>
> 2. FFT mode and IRAF boundary modes added to Convolve.convolve2d
>
> There's now an FFT switch for the 2d convolution function in the
> Convolve package; when set to 1, convolution is performed via the FFT
> rather than using the naiive algorithm.  In addition, convolve2d now
> supports boundary modes which are identical to IRAF's convolution
> function.
>
> 3. Numarray is now supported by f2py
>
> Numarray numerical arrays can now be used with f2py wrappers for
> Fortran code.  To compile f2py wrapped extensions for numarray,
> use the switch -DNUMARRAY on the f2py command line. Support
> is currently limited to f77 and numerical arrays.
>
>
> II. BUGS FIXED
>
> 650926        exotic type coercions
> 653424        Convolve.boxcar boundary bug
> 653429        python setup.py build
> 654669        array index by list
> 655942        logical operator reductions
> 657058        inverse real fft bug
> 677796         byteswap not working
> 709956        error summing over large boolean arrays
> 710480        MLab.median makes unnecessary msort call
> 714537        conjugate function changes its argument
>
> See
> http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse
> for more details.
>
> III. CAUTIONS
>
> 1. Due to some module renamings, numarray-0.5 will not install
> correctly on top of an existing numarray installation. Before
> installing numarray-0.5 remove your old version of numarray.
>
> 2. Due to reorganization of the C-API, numarray extensions must be
> recompiled.
>
> 3. For numarray-0.5 and up, the byteswap related methods have been
> redefined:
>
> a.byteswap()                   swaps but leaves byteorder alone
> a.togglebyteorder()            Does "big" <-> "little"
> a._byteswap()                  now an alias for byteswap
> a._togglebyteorder()           deleted
>
> 4. round() has been deprecated.  Use around() instead.
>
> 5. Installing from source, the first time you run setup.py, you must
> specify --gencode, e.g.:  python setup.py install --gencode
>
> WHERE
> -----------
>
> Numarray-0.5 windows executable installers, source code, and manual is
> here:
>
> http://sourceforge.net/project/showfiles.php?group_id=1369
>
> Numarray is hosted by Source Forge in the same project which hosts
> Numeric:
>
> http://sourceforge.net/projects/numpy/
>
> The web page for Numarray information is at:
>
> http://stsdas.stsci.edu/numarray/index.html
>
> Trackers for Numarray Bugs, Feature Requests, Support, and Patches are
> at
> the Source Forge project for NumPy at:
>
> http://sourceforge.net/tracker/?group_id=1369
>
> REQUIREMENTS
> ------------------------------
>
> numarray-0.5 requires Python 2.2.2 or greater.
>
>
> AUTHORS, LICENSE
> ------------------------------
>
> Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC
> Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science
> Institute.  Thanks go to Jochen Kupper of the University of North
> Carolina for his work on Numarray and for porting the Numarray manual
> to TeX format.  Thanks also to Edward C. Jones, Francesc Alted,
> Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson and everyone
> who has contributed with comments and feedback.
>
> Numarray is made available under a BSD-style License.  See
> LICENSE.txt in the source distribution for details.
>
> -- 
> Todd Miller jm...@st...
> STSCI / ESS / SSB
>
>
>
> -------------------------------------------------------
> 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
>