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

Re: [Numpy-discussion] bug in object arrays:

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

On Sun, 2004-06-06 at 12:10, Peter Verveer wrote:
> Is this a bug?

I think this is more of a bonanza:  a bug and an ambiguity.

> This should result in an array of numpy arrays, but it does give an  
> error:
> 
>  >>> a = array([1,2])
>  >>> b = array([3,4])
>  >>> c = objects.array([a,b])
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/numarray/objects.py", line 732, in array
>      return fromlist(sequence, shape)
>    File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/numarray/objects.py", line 755, in fromlist
>      return ObjectArray(objects=l, shape=shape)
>    File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/numarray/objects.py", line 506, in __init__
>      oshape = _shapeFromNestedSequence(objects)
>    File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/numarray/objects.py", line 289, in  
> _shapeFromNestedSequence
>      return [len(s)] + _shapeFromNestedSequence(s[0])
> TypeError: can only concatenate list (not "tuple") to list

The bug is that your example didn't work as follows:

>>> import numarray.objects as obj
>>> obj.array([a,b])
ObjectArray([[1, 2],
             [3, 4]])

Returning a shape=(2,) object array is another obvious behavior but
turns out not to be what Numeric does and hence not what numarray does
either.   Faced with sequence objects,  Numeric and numarray both just
keep recursing (logically anyway) until they hit something which isn't a
sequence.  Thus, they return not a 1D array of arrays, but a 2D array of
numbers:

>>> import Numeric
Numeric.array([a,b], typecode='O')
array([[1 , 2 ],
       [3 , 4 ]],'O')

With some new code I added today,  numarray of the future will support
your preferred behavior like this, barring further discussion:

>>> obj.array([a,b], rank=1)
ObjectArray([array([1, 2]), array([3, 4])])

Here, the new "rank" parameter explicitly specifies the expected rank of
the resulting array, defining the point at which nested sequences become
"objects in their own right".  Perry's inclination was that rank should
default to 1 so that your expected behavior was the default.  Since
that's not backward compatible with Numeric (or numarray-0.9) I think
maybe rank=None is better.  In this case, rank=None is equivalent to
rank=2.

How does the rank parameter sound?

Regards,
Todd

Re: [Numpy-discussion] Accessing rank-0 array value?

[Benjamin M. S. <be...@MI...>]

Francesc Alted wrote:

>For me, the basic problem is that a[()] notation would be the best way to
>get the python object with a type close to that of the numarray object. Why
>not letting a[...] or a[:] to return the same object as a[()]?. I know that
>this is not consistent with the "..." or ":" use in non-scalar arrays, but I
>find any of last two far more intuitive than a "()" index. 
>  
>
I don't agree with this idea as written; I think that a[:] should always 
return a.  However, I think that there is another relevant point here: 
single-element arrays have no rank!
In other words, from a purely mathematical point of view, it makes sense 
not to distinguish between the number 5, the vector with a single 
element 5, the 1x1 matrix 5, the 1x1x1 object-of-some-sort 5, etc.

Accordingly, if a is a single-element array, it would be sensible for 
a[()]==a[0]==a[0,0]==a[0,0,0]==a[(0)]==a[(0, 0, 0, 0, 0)]

Asking for the array's dimensions would then require a convention.

-long-time-reader, first-time-poster

Ben Schwartz

Re: [Numpy-discussion] Accessing rank-0 array value?

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

[SNIP]

>>>>a[0]
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>IndexError: Too many indices
>
>by something like:
>
>  
>
>>>>a[0]
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>IndexError: rank-0 arrays don't accept integer indices. Use '()' (empty tuple)
>instead.
>
This seems like a sensible idea. One might further restrict this and 
only raise it when a rank-0 array is indexed with zero, which is the 
only real case that causes confusion. In that case, I suggest the error 
message similar to:

IndexError: Too many indices (Use A[()] to get scalar from rank-0 array A)


>In order to provide an universal accessor to numarray objects, what about
>adding a .toscalar() (or .toobject()) method to them? That would return a
>python object whether you are using rank-0 arrays, regular arrays,
>CharArrays or RecArrays. That object would be the minimal python container
>that would keep the values inside these objects. In case of rank-0 arrays it
>would return a Bool, Int, Float or Complex. For a regular array, a list
>(perhaps a tuple?). For CharArrays, a list (tuple?) of strings. And for
>RecArrays a list (tuple) of tuples.


That's an interesting idea. `tolist` doesn't work on rank-0 arrays, 
sensibly enough. I would expect something called toscalar to only work 
on rank-0 arrays. I don't like that since I would like to see fewer 
special cases for rank-0 arrays not less. However, something called 
`toobject` (or `topyobject`, `tocoreobject`, etc) could return a core 
python object that was equivalent to the original array, which I believe 
is what you describe above. For example, after:

obj = anArray.toobject()
type = anArray.type()
newArray = numarray.array(obj, type)

`newArray` would always be equal to `anArray` in both value and type. 
The implementation of toobject could be as simple as:

    def toobject(self):
       if self.rank == 0:
          return self[()]
       else:
          return self.tolist()

I'm not entirely convinced it's a good idea yet; I'd have to see some 
use cases, but it's an interesting idea in any event.


>Incidentally, I've noted an inconsistency in the .tostring behaviour:
>
>  
>
>>>>a=array(126)
>>>>a.tostring()
>>>>        
>>>>
>''
>  
>
Interesting. That's better than the memory error I get with 
Numarray-0.8. Or the indefinite hang I get with numarray 0.9.

>while I would expect a return value like:
>
>  
>
>>>>chr(126)
>>>>        
>>>>
>'~'
>  
>
I think it should actually be returning the same things as 
array([126]).tostring(). That is:

'\x80\x00\x00\x00'


[SNIP]

Regards,

-tim

Re: [Numpy-discussion] Accessing rank-0 array value?

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

A Dilluns 07 Juny 2004 19:35, Perry Greenfield va escriure:
> That discussion was centered on whether single element indexing
> should return rank-0 arrays or scalars. We chose scalars 
> as more intuitive (and for performance reasons as well).
> There was hope that rank-0 arrays would be more convenient
> to use, and that they could also be indexed as a[0], however
> this is inconsistent with the shape as Peter points out (and
> as others before did as well).
> 
> That being said, I'd like to understand why you (Francesc)
> would like to use rank-0 arrays. There is certainly a legitimate
> problem to be solved, and perhaps there are better alternatives.

Well, I've come to use rank-0 arrays in a natural way in my libraries, and I
liked to retrieve their content before returning it to the user. I was
simply a bit surprised that retrieving that value was so hidden in
documentation (in case that issue is documented at all, because I have not
found it yet).

My natural try was first to use "[0]" notation, and the error lost me.
Suggestion: it would be possible to change the default error:

>>> a[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IndexError: Too many indices

by something like:

>>> a[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IndexError: rank-0 arrays don't accept integer indices. Use '()' (empty tuple)
instead. 

In order to provide an universal accessor to numarray objects, what about
adding a .toscalar() (or .toobject()) method to them? That would return a
python object whether you are using rank-0 arrays, regular arrays,
CharArrays or RecArrays. That object would be the minimal python container
that would keep the values inside these objects. In case of rank-0 arrays it
would return a Bool, Int, Float or Complex. For a regular array, a list
(perhaps a tuple?). For CharArrays, a list (tuple?) of strings. And for
RecArrays a list (tuple) of tuples.

Incidentally, I've noted an inconsistency in the .tostring behaviour:

>>> a=array(126)
>>> a.tostring()
''

while I would expect a return value like:

>>> chr(126)
'~'

> The original source of the previous rank-0 discussion was that
> they aided what had been dubbed "generic programming". This 
> was being promoted primarily by the scipy guys and the general
> idea was to make it easier to write code that did not constantly
> have to check whether an input was scalar or an array. With
> scalars always mapping to rank-0 arrays, it was felt that
> this would aid writing code that would work for both scalars
> and arrays without any conditional tests. It's a good thing
> to want. I wonder if we should now develop tools to make writing
> such code much easier.
>
> So if your needs are along this line, this seems like a good time
> to try to figure out ways of dealing with such issues.

My needs are restricted to very few lines of code, so I can pass by using
the conditionals. However, yeah, I would be happy as well if I would be able
to implement that kind of "generic programming". I find that to be elegant,
although it may perfectly not worth the effort, I don't know.

Well, for me the whole issue was getting rank-0 values as python objects.
Sorry if my point of view is adding confusion to these issues.

Cheers,

-- 
Francesc Alted

[Numpy-discussion] WE GIVE THE BEST DISCOUNT EVER bright

[Krishna L. <ceo...@wm...>]

war any fresh wall satisfied allowed goes argue period order 

Re: [Numpy-discussion] Problems installing not as root

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

Ryan Gutenkunst wrote:
> Hi all,
> 
> I'm trying to install Numerical Python without root access, and I'm 
> having great difficulty.
> 
> I'm running Python 2.2.2 (which was installed systemwide by root). I 
> used 'python setup.py install --prefix ~/installed' to install numpy and 
> I have ~/installed/lib/python2.2/site-packages in my PYTHONPATH.
> 
> Initially 'import' was failing, but  creating an empty __init.py__ in 
> site-packages/Numeric seems to have fixed that. I still can't seem to 
> use any of the functions, though. I get errors like:

Don't do this, it's a bit tricky to get it right.  You're stuck in .pth hell, 
because Numeric is not a true python package, and python only picks up .pth 
files in a few locations in the filesystem (NOT in all of your pythonpath). 
Since those locations are all root-only, you'll need to add explicitly

~/installed/lib/python2.2/site-packages/Numeric

to your PYTHONPATH for things to work smoothly.

If you insist, here's a hacked __init__.py to fake what you are looking for:

littlewood[Numeric]> cat __init__.py
# fperez.  Hack to make Numeric behave like a real package, regardless of 
where it's
# installed.  This is needed because Numeric relies on a .pth file for path
# manipulations, but those are ONLY scanned in sys.prefix, not for all paths in
# PYTHONPATH.

import sys
sys.path.append('/usr/local/lib/python/Numeric')  #put what you need here
from Numeric import *

#--------------- fix the linebreaks above before using

Unfortunately it doesn't look like Numeric will become a true python package, 
so we're stuck with these hacks.  Welcome to the club of .pth haters :)

Cheers,

f

Re: [Numpy-discussion] Problems installing not as root

[Robert K. <rk...@uc...>]

Ryan Gutenkunst wrote:
> Hi all,
> 
> I'm trying to install Numerical Python without root access, and I'm 
> having great difficulty.

Ryan! Long time, no see. Good to see you're joining in on the Python fun.

> I'm running Python 2.2.2 (which was installed systemwide by root). I 
> used 'python setup.py install --prefix ~/installed' to install numpy and 
> I have ~/installed/lib/python2.2/site-packages in my PYTHONPATH.
> 
> Initially 'import' was failing, but  creating an empty __init.py__ in 
> site-packages/Numeric seems to have fixed that. 

No good. Numeric isn't a package (in the technical sense of a collection 
of modules all in a directory that has an __init__.py, etc.).

Check for the existence of the file 
~/installed/lib/python2.2/site-packages/Numeric.pth . It should have one 
line saying, "Numeric". When the interpreter starts up, it scans what's 
in the PYTHONPATH and the defaults paths. When it encounters .pth files, 
it automatically adds the paths named in them to the PYTHONPATH.

You can also try adding ~/installed/lib/python2.2/site-packages/Numeric 
directly to your PYTHONPATH.

If you have more problems, you can contact me off-list; I'll take care 
of you.

-- 
Robert Kern
rk...@uc...

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

Re: [Numpy-discussion] Problems installing not as root

[Jeffery D. C. <jco...@ea...>]

On Monday 07 June 2004 02:36 pm, Ryan Gutenkunst wrote:
> Hi all,
>
> I'm trying to install Numerical Python without root access, and I'm
> having great difficulty.
>
> I'm running Python 2.2.2 (which was installed systemwide by root). I
> used 'python setup.py install --prefix ~/installed' to install numpy and
> I have ~/installed/lib/python2.2/site-packages in my PYTHONPATH.

Maybe this will work:  eliminate the __init__.py (and __init__.pyc) that you 
created and add the following to your PATH instead:

~/installed/lib/python2.2/site-packages/Numeric


>
> Initially 'import' was failing, but  creating an empty __init.py__ in
> site-packages/Numeric seems to have fixed that. I still can't seem to
> use any of the functions, though. I get errors like:
>
> Python 2.2.2 (#1, Nov 22 2002, 17:25:34)
> [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
>  >>> import Numeric
>  >>> a = array([1.2, 3.5, -1])
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> NameError: name 'array' is not defined
>
>  >>> a = Numeric.array([1.2, 3.5, -1])
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> AttributeError: 'module' object has no attribute 'array'
>
> I'm new at python, and am completely perplexed. Perhaps I need a more
> complete __init.py__?
>
> Thanks in advance,
> Ryan

--
Jeff

[Numpy-discussion] Problems installing not as root

[Ryan G. <rn...@co...>]

Hi all,

I'm trying to install Numerical Python without root access, and I'm 
having great difficulty.

I'm running Python 2.2.2 (which was installed systemwide by root). I 
used 'python setup.py install --prefix ~/installed' to install numpy and 
I have ~/installed/lib/python2.2/site-packages in my PYTHONPATH.

Initially 'import' was failing, but  creating an empty __init.py__ in 
site-packages/Numeric seems to have fixed that. I still can't seem to 
use any of the functions, though. I get errors like:

Python 2.2.2 (#1, Nov 22 2002, 17:25:34)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import Numeric
 >>> a = array([1.2, 3.5, -1])
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
NameError: name 'array' is not defined
 >>> a = Numeric.array([1.2, 3.5, -1])
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'array'

I'm new at python, and am completely perplexed. Perhaps I need a more 
complete __init.py__?

Thanks in advance,
Ryan

-- 
Ryan Gutenkunst               |
Cornell Dept. of Physics      |       "It is not the mountain
                               |        we conquer but ourselves."
Clark 535 / (607)255-6068     |        -- Sir Edmund Hillary
AIM: JepettoRNG               |
          http://www.physics.cornell.edu/~rgutenkunst/

RE: [Numpy-discussion] Accessing rank-0 array value?

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

Peter Verveer wrote:
> 
> I do not agree. The a[()] notation is consistent and clear if you know 
> that you can index with a tuple of indices: you index a rank-0 array 
> with a tuple of length zero.
> 
> The "..." and ":" should do the same as for any other array: return the 
> whole thing, not a single element.
> 
Peter gets at the crux of the reasons behind the current behavior.
(Much of this was discussed some time ago). There is a distinction
between a scalar and a rank-0 array in that one expects that
all the array semantics will be consistent with all other arrays.
Thus "..." and ":" behave exactly the same.

That discussion was centered on whether single element indexing
should return rank-0 arrays or scalars. We chose scalars 
as more intuitive (and for performance reasons as well).
There was hope that rank-0 arrays would be more convenient
to use, and that they could also be indexed as a[0], however
this is inconsistent with the shape as Peter points out (and
as others before did as well).

That being said, I'd like to understand why you (Francesc)
would like to use rank-0 arrays. There is certainly a legitimate
problem to be solved, and perhaps there are better alternatives.

The original source of the previous rank-0 discussion was that
they aided what had been dubbed "generic programming". This 
was being promoted primarily by the scipy guys and the general
idea was to make it easier to write code that did not constantly
have to check whether an input was scalar or an array. With
scalars always mapping to rank-0 arrays, it was felt that
this would aid writing code that would work for both scalars
and arrays without any conditional tests. It's a good thing
to want. I wonder if we should now develop tools to make writing
such code much easier.

Matlab apparently treats all scalars as rank-0 values and thus
makes it fairly easy to deal with such things. On the other hand,
Python does have real scalars so things are not quite so simple.
One can wrap all inputs with array(), but then what will be returned
will also be an array (rank-0 or whatever). That isn't always what
is desired when scalars are given as an argument to a function.

So if your needs are along this line, this seems like a good time
to try to figure out ways of dealing with such issues.

Perry

Re: [Numpy-discussion] Accessing rank-0 array value?

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

I do not agree. The a[()] notation is consistent and clear if you know 
that you can index with a tuple of indices: you index a rank-0 array 
with a tuple of length zero.

The "..." and ":" should do the same as for any other array: return the 
whole thing, not a single element.

On 7 Jun 2004, at 18:27, Francesc Alted wrote:

> First of all, thanks to everybody for their responses.
>
> For me, the basic problem is that a[()] notation would be the best way 
> to
> get the python object with a type close to that of the numarray 
> object. Why
> not letting a[...] or a[:] to return the same object as a[()]?. I know 
> that
> this is not consistent with the "..." or ":" use in non-scalar arrays, 
> but I
> find any of last two far more intuitive than a "()" index.
>
> Besides, IMHO, an scalar array is not a "regular" array, so the 
> consistency
> restrictions should not be set as hard as they are now.
>
> Regards,
>
> -- 
> Francesc Alted
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Accessing rank-0 array value?

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

First of all, thanks to everybody for their responses.

For me, the basic problem is that a[()] notation would be the best way to
get the python object with a type close to that of the numarray object. Why
not letting a[...] or a[:] to return the same object as a[()]?. I know that
this is not consistent with the "..." or ":" use in non-scalar arrays, but I
find any of last two far more intuitive than a "()" index. 

Besides, IMHO, an scalar array is not a "regular" array, so the consistency
restrictions should not be set as hard as they are now.

Regards,

-- 
Francesc Alted

Re: [Numpy-discussion] Accessing rank-0 array value?

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

On Mon, 2004-06-07 at 11:51, Colin J. Williams wrote:
> Todd,
> 
> What are the objections to returning a scalar?  

Where?

> To me, this seems to be 
> simpler than some kluge, such as float(array) or int(array).  To use 
> these, one has first to determine what array._type is.

I don't think so.  What you get is driven by what you ask for, not the
type of the array:

>>> a = numarray.array(10)
>>> float(a)
10.0
>>> int(a)
10
>>> a = numarray.array(10.0)
>>> int(a)
10
>>> float(a)
10.0
>>> complex(a)
(10+0j)

Regards,
Todd


> Colin W.
> 
> Todd Miller wrote:
> 
> >On Mon, 2004-06-07 at 06:50, Nadav Horesh wrote:
> >  
> >
> >>b has a scalar properties:
> >>
> >>    
> >>
> >>>>>b+3
> >>>>>          
> >>>>>
> >>5
> >>
> >>    
> >>
> >>>>>b.rank
> >>>>>          
> >>>>>
> >>0
> >>
> >>The odd issue is that rank>0 arrays keeps their type in similar operations:
> >>
> >>    
> >>
> >>>>>a = array((2,), type=Int16)
> >>>>>a
> >>>>>          
> >>>>>
> >>array([2], type=Int16)
> >>
> >>    
> >>
> >>>>>a + 3
> >>>>>          
> >>>>>
> >>array([5], type=Int16)
> >>
> >>I would expect that rank 0 arrays would behave like scalars with a given numarray type (Int8, UInt64, ...).
> >>
> >>  Nadav.
> >>    
> >>
> >
> >Originally, I think your expected behavior was the behavior.  The
> >official policy now, always subject to debate, is that rank-0 arrays
> >should be a mostly hidden implementation detail.  The fact that a scalar
> >is returned here is a matter of consistency and no accident.  (This is
> >not to say that I'm confident that we're completely consistent... I'm
> >just trying to explain the direction we're heading.)
> >
> >Todd
> >
> >  
> >
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Accessing rank-0 array value?

[Colin J. W. <cj...@sy...>]

Todd,

What are the objections to returning a scalar?  To me, this seems to be 
simpler than some kluge, such as float(array) or int(array).  To use 
these, one has first to determine what array._type is.

Colin W.

Todd Miller wrote:

>On Mon, 2004-06-07 at 06:50, Nadav Horesh wrote:
>  
>
>>b has a scalar properties:
>>
>>    
>>
>>>>>b+3
>>>>>          
>>>>>
>>5
>>
>>    
>>
>>>>>b.rank
>>>>>          
>>>>>
>>0
>>
>>The odd issue is that rank>0 arrays keeps their type in similar operations:
>>
>>    
>>
>>>>>a = array((2,), type=Int16)
>>>>>a
>>>>>          
>>>>>
>>array([2], type=Int16)
>>
>>    
>>
>>>>>a + 3
>>>>>          
>>>>>
>>array([5], type=Int16)
>>
>>I would expect that rank 0 arrays would behave like scalars with a given numarray type (Int8, UInt64, ...).
>>
>>  Nadav.
>>    
>>
>
>Originally, I think your expected behavior was the behavior.  The
>official policy now, always subject to debate, is that rank-0 arrays
>should be a mostly hidden implementation detail.  The fact that a scalar
>is returned here is a matter of consistency and no accident.  (This is
>not to say that I'm confident that we're completely consistent... I'm
>just trying to explain the direction we're heading.)
>
>Todd
>
>  
>

Re: [Numpy-discussion] Pre-process crash on AIX

[Marc P. <Mar...@on...>]

Todd Miller wrote:
> 
> PSEUDO = """
> #define <function> (*(<rval> (*) <proto> ) <module>_API[ <num> ])
> """
> 

ok, this one works. I tried to use other syntaxes for the original
macros, but the compiler still fails. I though it was a pre-processing
phase, but it looks like it's something more internal...

-MP-

Re: [Numpy-discussion] Pre-process crash on AIX

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

On Mon, 2004-06-07 at 10:36, Marc Poinot wrote:
> I've got a crash with xlC compiler on AIX 5.1 (using 64 bits mode).
> The macro used to check the API function before the call makes the
> compiler crazy. 

You might want to look at  numarray-0.9/include/numarray/genapi.py and
see if you can modify the macro generation into something xlC can
stomach.  

Right now, the call consists of these parts:

1. A cast of the API jump table pointer and function ID to a pointer to
a function with a particular signature.

2. Code which checks to see that the API pointer has been initialized
and gives a fatal error rather than dumping core if it has not been
inited.

The macro generation Python code looks like:

PSEUDO = """
#define <function> (<module>_API ? (*(<rval> (*) <proto> ) <module>_API[
<num> ]) : (*(<rval> (*) <proto> ) FatalApiError))
"""

You can simplify it to this by eliminating part 2:

PSEUDO = """
#define <function> (*(<rval> (*) <proto> ) <module>_API[ <num> ])
"""
 
And then re-install with:

python setup.py install --gencode

Beyond that,  you're in new territory for me.   Good luck!   Let us know
how it goes.

> This simple test fails:
> 
> #include "Python.h"
> #include "numarray/arrayobject.h"
> 
> int main()
> {
>   char * foo;
>   int    d[3]; // don't care about alloc, it doesn't compile ;)
> 
>   NA_vNewArray(foo,tInt64,1,d);
> }
> 
> Can I use another function without the macro to replace NA_vNewArray ?
> Is there somebody with a successful installed numarray 0.9 on AIX ?
> 
> Yes -> what about this problem above, did you change something ?
> No  -> great ! Ok, I'm going back to 8086 harware.
> 
> -MP-
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] Pre-process crash on AIX

[Marc P. <Mar...@on...>]

I've got a crash with xlC compiler on AIX 5.1 (using 64 bits mode).
The macro used to check the API function before the call makes the
compiler crazy. This simple test fails:

#include "Python.h"
#include "numarray/arrayobject.h"

int main()
{
  char * foo;
  int    d[3]; // don't care about alloc, it doesn't compile ;)

  NA_vNewArray(foo,tInt64,1,d);
}

Can I use another function without the macro to replace NA_vNewArray ?
Is there somebody with a successful installed numarray 0.9 on AIX ?

Yes -> what about this problem above, did you change something ?
No  -> great ! Ok, I'm going back to 8086 harware.

-MP-

RE: [Numpy-discussion] Accessing rank-0 array value?

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

On Mon, 2004-06-07 at 06:50, Nadav Horesh wrote:
> b has a scalar properties:
> 
> >>> b+3
> 5
> 
> >>> b.rank
> 0
> 
> The odd issue is that rank>0 arrays keeps their type in similar operations:
> 
> >>> a = array((2,), type=Int16)
> >>> a
> array([2], type=Int16)
> 
> >>> a + 3
> array([5], type=Int16)
> 
> I would expect that rank 0 arrays would behave like scalars with a given numarray type (Int8, UInt64, ...).
> 
>   Nadav.

Originally, I think your expected behavior was the behavior.  The
official policy now, always subject to debate, is that rank-0 arrays
should be a mostly hidden implementation detail.  The fact that a scalar
is returned here is a matter of consistency and no accident.  (This is
not to say that I'm confident that we're completely consistent... I'm
just trying to explain the direction we're heading.)

Todd

-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Accessing rank-0 array value?

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

On Mon, 2004-06-07 at 05:27, Peter Verveer wrote:
> For instance:
> 
>  >>> float(b)
> 2.0
> 
> or probably more appropriate since it retains the type:
> 
>  >>> b[()]
> 2
> 
> Both not very intuitive, are there any better ways?

Not that I'm aware of.  The root problem is that it is not possible to
say:  b[].

At one point, it was possible to say b[0],  but that feature was
intentionally removed after a fair amount of discussion.

Todd

> 
> On 7 Jun 2004, at 11:17, Francesc Alted wrote:
> 
> > Hi,
> >
> > Perhaps this is a stupid question, but I did not found any easy way to 
> > get
> > the python object value from a rank-0 numarray array. That is:
> >
> >>>> from numarray import *
> >>>> b=array(2)
> >>>> b
> > array(2)
> >>>> b[0]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > IndexError: Too many indices
> >
> > In C, that seem to be possible provided you use the call:
> > PyObject* PyArray_Return(PyArrayObject *apr)
> >
> > Is there any way to do that in python?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] Java version for numarray?

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

Hi,

I'm using numarray objects basically like data containers for fast I/O
purposes in the context of pytables. I'm thinking now to port part of my
code to Java, and I'd like to use Jython to easy the transition. I've seen
that a there is a port of Numeric to Jython
(http://jnumerical.sourceforge.net/), and I thought that I could use these
Numeric objects as containers. Unfortunately, there are a couple of objects
that pytables relies on, namely RecArray and CharArray, that are not
supported by Numeric.

My questions are:

- I think that both RecArray and CharArray modules are written in pure
python, so the porting to Jython should be relatively easy, provided I'm
successful making them to use Numeric objects instead of NumArray objects.
What do you think? Would that be feasible?

- Is there any effort going on in order to have an implementation of
numarray ready for use in Jython?

Thanks,

-- 
Francesc Alted

RE: [Numpy-discussion] Accessing rank-0 array value?

[Nadav H. <na...@vi...>]

b has a scalar properties:

>>> b+3
5

>>> b.rank
0

The odd issue is that rank>0 arrays keeps their type in similar =
operations:

>>> a =3D array((2,), type=3DInt16)
>>> a
array([2], type=3DInt16)

>>> a + 3
array([5], type=3DInt16)

I would expect that rank 0 arrays would behave like scalars with a given =
numarray type (Int8, UInt64, ...).

  Nadav.



-----Original Message-----
From:	Peter Verveer [mailto:ve...@em...]
Sent:	Mon 07-Jun-04 12:27
To:	Francesc Alted
Cc:	Numpy Discussion List
Subject:	Re: [Numpy-discussion] Accessing rank-0 array value?
For instance:

 >>> float(b)
2.0

or probably more appropriate since it retains the type:

 >>> b[()]
2

Both not very intuitive, are there any better ways?

On 7 Jun 2004, at 11:17, Francesc Alted wrote:

> Hi,
>
> Perhaps this is a stupid question, but I did not found any easy way to =

> get
> the python object value from a rank-0 numarray array. That is:
>
>>>> from numarray import *
>>>> b=3Darray(2)
>>>> b
> array(2)
>>>> b[0]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> IndexError: Too many indices
>
> In C, that seem to be possible provided you use the call:
> PyObject* PyArray_Return(PyArrayObject *apr)
>
> Is there any way to do that in python?



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Numpy-discussion mailing list
Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] Accessing rank-0 array value?

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

For instance:

 >>> float(b)
2.0

or probably more appropriate since it retains the type:

 >>> b[()]
2

Both not very intuitive, are there any better ways?

On 7 Jun 2004, at 11:17, Francesc Alted wrote:

> Hi,
>
> Perhaps this is a stupid question, but I did not found any easy way to 
> get
> the python object value from a rank-0 numarray array. That is:
>
>>>> from numarray import *
>>>> b=array(2)
>>>> b
> array(2)
>>>> b[0]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> IndexError: Too many indices
>
> In C, that seem to be possible provided you use the call:
> PyObject* PyArray_Return(PyArrayObject *apr)
>
> Is there any way to do that in python?

[Numpy-discussion] Accessing rank-0 array value?

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

Hi,

Perhaps this is a stupid question, but I did not found any easy way to get
the python object value from a rank-0 numarray array. That is:

>>> from numarray import *
>>> b=array(2)
>>> b
array(2)
>>> b[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IndexError: Too many indices

In C, that seem to be possible provided you use the call:
PyObject* PyArray_Return(PyArrayObject *apr)

Is there any way to do that in python?

Thanks,

-- 
Francesc Alted

[Numpy-discussion] bug in object arrays:

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

Is this a bug?

This should result in an array of numpy arrays, but it does give an  
error:

 >>> a = array([1,2])
 >>> b = array([3,4])
 >>> c = objects.array([a,b])
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/objects.py", line 732, in array
     return fromlist(sequence, shape)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/objects.py", line 755, in fromlist
     return ObjectArray(objects=l, shape=shape)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/objects.py", line 506, in __init__
     oshape = _shapeFromNestedSequence(objects)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/objects.py", line 289, in  
_shapeFromNestedSequence
     return [len(s)] + _shapeFromNestedSequence(s[0])
TypeError: can only concatenate list (not "tuple") to list

[Numpy-discussion] failure delivery

[<MAI...@ya...>]

Message from  yahoo.com.
Unable to deliver message to the following address(es).

<beg...@gm...>:
216.239.57.27 failed after I sent the message.
Remote host said: 552 Illegal Attachment

--- Original message follows.

Return-Path: <num...@li...>

The original message is over 5k.  Message truncated to 1K.

Message-ID: <200...@mt...>
Received: from mta1-vm2.mail.yahoo.com for beg...@gm...; Jun  5 13:22:43 2004 -0700
X-YahooFilteredBulk: 128.2.222.173
X-Yahoo-Forwarded: from ad...@be... to beg...@gm...
Received: from 128.2.222.173  (HELO cs.cmu.edu) (128.2.222.173)
  by mta1-vm2.mail.yahoo.com with SMTP; Sat, 05 Jun 2004 13:22:43 -0700
Received: from 200-163-004-246.bsace7013.dsl.brasiltelecom.net.br
          ([200.163.4.246]) by cs.cmu.edu id aa11414; 5 Jun 2004 16:19 EDT
From: num...@li...
To: ad...@cs...
Subject: Hi
Date: Sat, 5 Jun 2004 17:19:37 -0300
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0016----=_NextPart_000_0016"
X-Priority: 3
X-MSMail-Priority: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit


My message.
Thanks

+++ X-Attachment-Type: document
+++ X-Attachment-Status: no virus found
+++ Powered by the new Panda OnlineAntiVirus
+++ Website: www.pandasoftware.com



-----
*** MESSAGE TRUNCATED ***