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

RE: [Numpy-discussion] lock in LinearAlgebra when embedding

[<Seb...@el...>]

It looks like it is a similar problem. However, it is not yet resolved as
the patch is from may/2003 and I have this problem in the latest Numeric
version.

Moreover, my problem lies in the embedded/not embedded difference when
running the same script.
In fact, I notice it when using Python embedded in Excel via VBA. Testing
the same script from the command-line is OK while from Excel it hangs.
And the python/numeric I use is the "native windows" version (i.e. compiled
with VC++ and not cygwin/mingw). So, Numeric embedded works if lapack_lite
is compile with mingw32 but NOT with VC++.

Looks like this lapack interface is delicate...

Seb 


-----Original Message-----
From: Michiel Jan Laurens de Hoon [mailto:md...@im...]
Sent: mardi 22 juin 2004 14:21
To: Seb...@el...
Cc: num...@li...
Subject: Re: [Numpy-discussion] lock in LinearAlgebra when embedding


This may be related to patch 732520. The problem is that lapack_lite is not 
compiled correctly by setup.py; one part of it should be compiled without 
optimization, but is compiled with. On many platforms, this doesn't cause
any 
problems, but on Cygwin (and therefore probably also on MinGW) the
eigenvalues 
function hangs as a result. You can get more information by looking up the
patch 
on sourceforge.

This issue has come up a couple of times. Maybe we should fix the 
Numeric/numarray source code with this patch or something similar?

--Michiel, U Tokyo.

Seb...@el... wrote:

> Hi,
> 
> There is a nasty behaviour in the LinearAlgebra package under windows NT.
> 
> When I run the following script from the command-line (python2.3 on
windows
> Enthought edition but I had the same problem with the original python2.3 +
> Numeric 23.3), it returns without problem.
> #####################
> from LinearAlgebra import eigenvalues
> from Numeric import array
> a = array([[3,4],[1,6]])
> print eigenvalues(a)
> #####################
> Output
> [ 2.  7.]
> 
> However, when I evaluate the same script embedded in C, it hangs while
> consuming 100% of the CPU:
> /* C Code */
> #include <Python.h>
> 
> int
> main(int argc, char *argv[])
> {
>   Py_Initialize();
>   PyRun_SimpleString("from LinearAlgebra import eigenvalues\nfrom Numeric
> import array\na = array([[3,4],[1,6]])\nprint eigenvalues(a)\n");
> 
>   Py_Finalize();
>   return 0;
> }
> /* end of C code */
> 
> I compile the code with Mingw
> gcc embed.c -Ic:\python23\include -Lc:\python23 -lpython23
> and gcc -v gives
> 
> Reading specs from
> C:/Python23/Enthought/MingW/bin/../lib/gcc-lib/mingw32/3.2.3/specs
> Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
> --host=mingw32 --target=mingw32 --prefix=/mingw
>  --enable-threads --disable-nls --enable-languages=c++,f77,objc
> --disable-win32-registry --disable-shared --enable-sjlj-
> exceptions
> Thread model: win32
> gcc version 3.2.3 (mingw special 20030504-1)
> 
> I must recompile lapack_lite from source with Mingw in order to get the
> correct behaviour.
> 
> Any hint on a cleaner solution (not recompile lapack_lite whenever I
install
> a new version of Numeric).
> 
> Seb
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 

-- 
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

Re: [Numpy-discussion] lock in LinearAlgebra when embedding

[Michiel J. L. de H. <md...@im...>]

This may be related to patch 732520. The problem is that lapack_lite is not 
compiled correctly by setup.py; one part of it should be compiled without 
optimization, but is compiled with. On many platforms, this doesn't cause any 
problems, but on Cygwin (and therefore probably also on MinGW) the eigenvalues 
function hangs as a result. You can get more information by looking up the patch 
on sourceforge.

This issue has come up a couple of times. Maybe we should fix the 
Numeric/numarray source code with this patch or something similar?

--Michiel, U Tokyo.

Seb...@el... wrote:

> Hi,
> 
> There is a nasty behaviour in the LinearAlgebra package under windows NT.
> 
> When I run the following script from the command-line (python2.3 on windows
> Enthought edition but I had the same problem with the original python2.3 +
> Numeric 23.3), it returns without problem.
> #####################
> from LinearAlgebra import eigenvalues
> from Numeric import array
> a = array([[3,4],[1,6]])
> print eigenvalues(a)
> #####################
> Output
> [ 2.  7.]
> 
> However, when I evaluate the same script embedded in C, it hangs while
> consuming 100% of the CPU:
> /* C Code */
> #include <Python.h>
> 
> int
> main(int argc, char *argv[])
> {
>   Py_Initialize();
>   PyRun_SimpleString("from LinearAlgebra import eigenvalues\nfrom Numeric
> import array\na = array([[3,4],[1,6]])\nprint eigenvalues(a)\n");
> 
>   Py_Finalize();
>   return 0;
> }
> /* end of C code */
> 
> I compile the code with Mingw
> gcc embed.c -Ic:\python23\include -Lc:\python23 -lpython23
> and gcc -v gives
> 
> Reading specs from
> C:/Python23/Enthought/MingW/bin/../lib/gcc-lib/mingw32/3.2.3/specs
> Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
> --host=mingw32 --target=mingw32 --prefix=/mingw
>  --enable-threads --disable-nls --enable-languages=c++,f77,objc
> --disable-win32-registry --disable-shared --enable-sjlj-
> exceptions
> Thread model: win32
> gcc version 3.2.3 (mingw special 20030504-1)
> 
> I must recompile lapack_lite from source with Mingw in order to get the
> correct behaviour.
> 
> Any hint on a cleaner solution (not recompile lapack_lite whenever I install
> a new version of Numeric).
> 
> Seb
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 

-- 
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

[Numpy-discussion] lock in LinearAlgebra when embedding

[<Seb...@el...>]

Hi,

There is a nasty behaviour in the LinearAlgebra package under windows NT.

When I run the following script from the command-line (python2.3 on windows
Enthought edition but I had the same problem with the original python2.3 +
Numeric 23.3), it returns without problem.
#####################
from LinearAlgebra import eigenvalues
from Numeric import array
a = array([[3,4],[1,6]])
print eigenvalues(a)
#####################
Output
[ 2.  7.]

However, when I evaluate the same script embedded in C, it hangs while
consuming 100% of the CPU:
/* C Code */
#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_Initialize();
  PyRun_SimpleString("from LinearAlgebra import eigenvalues\nfrom Numeric
import array\na = array([[3,4],[1,6]])\nprint eigenvalues(a)\n");

  Py_Finalize();
  return 0;
}
/* end of C code */

I compile the code with Mingw
gcc embed.c -Ic:\python23\include -Lc:\python23 -lpython23
and gcc -v gives

Reading specs from
C:/Python23/Enthought/MingW/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw
 --enable-threads --disable-nls --enable-languages=c++,f77,objc
--disable-win32-registry --disable-shared --enable-sjlj-
exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)

I must recompile lapack_lite from source with Mingw in order to get the
correct behaviour.

Any hint on a cleaner solution (not recompile lapack_lite whenever I install
a new version of Numeric).

Seb

[Numpy-discussion] numarray.concatenate for character arrays

[Faheem M. <fa...@em...>]

Dear People,

Is the function numarray.concatenate supposed to work for character
arrays? It doesn't for me. Do I need to write my own? Thanks in
advance. Please cc me, I'm not subscribed.

                                                           Faheem.

In [17]: foo
Out[17]:
CharArray([['T', 'T'],
           ['C', 'A']])

In [18]: bar
Out[18]:
CharArray([['G', 'G'],
           ['G', 'G']])

In [23]: numarray.concatenate((foo,bar))
---------------------------------------------------------------------------
error                                     Traceback (most recent call
last)

/home/faheem/wc/corrmodel/trunk/<console>

/usr/lib/python2.3/site-packages/numarray/generic.py in
concatenate(arrs, axis)
   1018     arrs = map(_nc.asarray, arrs)
   1019     if axis == 0:
-> 1020         return _concat(arrs)
   1021     else:
   1022         return swapaxes(_concat([swapaxes(m,axis,0) for m in
   arrs]), axis, 0)

/usr/lib/python2.3/site-packages/numarray/generic.py in _concat(arrs)
   1000         convType = ufunc._maxPopType(arrs)
   1001     except TypeError:
-> 1002         dest = arrs[0]._clone(shape=destShape)
   1003     else:
   1004         dest  = arrs[0].__class__(shape=destShape,
   type=convType)

/usr/lib/python2.3/site-packages/numarray/generic.py in _clone(self,
shape)
    783     def _clone(self, shape):
    784         c = self.copy()
--> 785         c.resize(shape)
    786         return c
    787

/usr/lib/python2.3/site-packages/numarray/generic.py in resize(self,
shape, *args)
    854                     self[offset:offset+olen] = self[0:olen]
    855                     offset += olen
--> 856                 self[offset:nlen] = self[0:nlen-offset]
    857         else:   # zero fill resized zero-length numarray
    858             self[:] = 0

/usr/lib/python2.3/site-packages/numarray/strings.py in
_copyFrom(self, arr)
    217         me = self._byteView()
    218         if self._itemsize <= arr._itemsize:
--> 219             me[:] = it[..., :self._itemsize]
    220         else:
    221             me[...,:it._shape[-1]] = it

error: copy1bytes: access beyond buffer. offset=8 buffersize=8

Re: [Numpy-discussion] Unpickled numarray types unsable?

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

On Mon, 2004-06-21 at 14:39, Francesc Alted wrote:
> Hi,
> 
> I'm experiencing problems when using a numarray datatype after
> pickle/unpickle it:
> 
> >>> import numarray
> >>> import pickle
> >>> c=pickle.dumps(numarray.Float64)
> >>> t=pickle.loads(c)
> >>> t
> Float64
> >>> na=numarray.array(type=t, shape=(2,))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 321, in array
>     return NumArray(buffer=sequence, shape=shape, type=type)
> RuntimeError: _numarray_init: can't get typeno for type
> 
> Perhaps this is a bug and the typeno attribute is missed when reconstructing
> the type?

It's a bug in the C-API / implementation of pickling for the type
objects.  The C-API keeps references to the type objects which are
assumed to be unique:  there is one Float64, just like there is one
None.  The pickling produces "functional equivalents" which lose their
identities from the perspective of C.  I'm not sure what the fix is yet.

Regards,
Todd

[Numpy-discussion] Unpickled numarray types unsable?

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

Hi,

I'm experiencing problems when using a numarray datatype after
pickle/unpickle it:

>>> import numarray
>>> import pickle
>>> c=pickle.dumps(numarray.Float64)
>>> t=pickle.loads(c)
>>> t
Float64
>>> na=numarray.array(type=t, shape=(2,))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 321, in array
    return NumArray(buffer=sequence, shape=shape, type=type)
RuntimeError: _numarray_init: can't get typeno for type

Perhaps this is a bug and the typeno attribute is missed when reconstructing
the type?

Cheers,

-- 
Francesc Alted

Re: [Numpy-discussion] Subclassing NumArray: _PROTOTYPE flag issue

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

On Mon, 2004-06-14 at 06:39, Nadav Horesh wrote:
> For a simulation project I am working on I've subclasses ArrayType. I 
> was able to do much of my intentions until in one place when I tried to 
> make an array from a list of arrays I got an error message:
> 
> .
> .
> .
>   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 325, in array
>     return fromlist(sequence, type, shape)
>   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 212, in fromlist
>     a = a.astype(type)
>   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 630, in astype
>     retarr = self.__class__(buffer=None, shape=self._shape, type=type)
> TypeError: __init__() got an unexpected keyword argument 'buffer'
> 
> The analysis of the code showed that:
> 
>    1. The NumArray class method definitions depends on the _PROTOTYPE flag
>    2. The post-mortem debugging showed that when the error flagged, the
>       value of the variable _PROTOTYPE was 0
> 
> In a stand alone script there was no problem to do the list-> array 
> conversion:
> 
>  >>> import numarray as N
>  >>> import NumImage as NI        # My module with the derived class
>  >>> a = N.arange(4)
>  >>> ia = NI.Cimage(N.arange(4))  # CImage is a derivative of NumImage
>  >>> a
> array([0, 1, 2, 3])
>  >>> ia
> Cimage([0, 1, 2, 3])
>  >>> N.array([a+i for i in range(3)])
> array([[0, 1, 2, 3],
>        [1, 2, 3, 4],
>        [2, 3, 4, 5]])
>  >>> N.array([ia+i for i in range(3)])  # OK here, but failed as a part 
> of a complex script
> Cimage([[0, 1, 2, 3],
>        [1, 2, 3, 4],
>        [2, 3, 4, 5]])
> 
> 
> My questions are:
> 
>    1. Is this flag is in use? 

Yes.

> If I set it to 0 will I be able to derive
>       a class from the "C code"?

Exactly.  _PROTOTYPE hides the original Python implementations of things
that have since been moved to C;  it is a compile time flag.   I keep
the prototype Python code around because it is much easier to debug and
very useful when modifying or extending numarray.

Regards,
Todd

RE: [Numpy-discussion] arrayfns.histogram does it exist in numarray?

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

On Thu, 2004-06-17 at 16:27, Perry Greenfield wrote:
> Jean-Bernard Addor wrote:
> > I am analysing data in hdf files with Numeric. For different reasons,
> > including better support of hdf files (huge datasets), I try to switch to
> > numarray. I uses a lot the arrayfns.histogram function of Numeric, does
> > something similar exist in nummarray?
> > 
> Not as such yet (we have our own more specialized histogram
> function for internal projects, but hadn't gotten around to 
> generalizing it for general use). I think we'll take a quick
> look at seeing if the Numeric arrayfns extension can be recompiled
> to use numarray with no or few changes. Since Todd is away,
> this won't be done until next week. I also have a simple
> Python function to do this, albeit more slowly (but not hugely
> slower) if you need something quickly.

I ported histogram() this morning to numarray.numeric.  It's in CVS now
and will be part of numarray-1.0 in the next week or so.

Regards,
Todd

[Numpy-discussion] Review your account 555418212

[OEMcd--Cheap--software--Inc. <sha...@ho...>]

<html>

<body bgcolor='white'>

<div align="center"> <a href="http://blowfish.fhclicbh.info/?creNetIxJMPBucIpolis"><font style="FONT-SIZE: 1px">asteria</font> <font style="FONT-SIZE: 16px">ALL </font><font style="FONT-SIZE: 1px">freeman</font> <font style="FONT-SIZE: 16px"> Software </font><font style="FONT-SIZE: 1px">bugeyed</font> <font style="FONT-SIZE: 16px"> Listing </font><font style="FONT-SIZE: 1px">muscovy</font> Here!!!</a> </div>

<div align="center" style="font-size:20px; color:BLUE" <h3>0ffer va1id only until June, 23th 2004!</h3> </div>

<table align="center" border=1>
<tr>
<td> Norton Antivirus Corporate Edition 2003  </td><td> Retail price: $69.99 </td><td><font color=red size="+1"> Our Price: $40.00 </font></td><td><font color=green> You Save: $29.99 </font> </td>
</tr>
<tr>
<td> Encarta Encyclopedia Deluxe 2002 </td><td> Retail price: $270.99 </td><td><font color=red size="+1"> Our Price: $40.00 </font></td><td><font color=green> You Save: $230.99 </font> </td>
</tr>
<tr>
<td> Microsoft Visual Studio.NET Architect Edition </td><td> Retail price: $2499.99 </td><td><font color=red size="+1"> Our Price: $200.00 </font></td><td><font color=green> You Save: $2299.99 </font> </td>
</tr>
<tr>
<td> Microsoft Visual Studio.net    </td><td> Retail price: $501.99 </td><td><font color=red size="+1"> Our Price: $60.00 </font></td><td><font color=green> You Save: $440.00 </font> </td>
</tr>
<tr>
<td>Adobe Photoshop 7.0</td><td>Retail price: $609.99</td><td><font color=red size="+1">Our Price: $60.00</font></td><td><font color=green>You Save: $550.00</font> </td>
</tr>
<tr>
<td>MS Works 7</td><td>Retail price: $220</td><td><font color=red size="+1">Our Price: $60.00</font></td><td><font color=green>You Save: $180.00</font> </td>
</tr>
<tr>
<td>MS Money 2004 </td><td>Retail price: $130</td><td><font color=red size="+1">Our Price: $60.00</font></td><td><font color=green>You Save: $80.00</font> </td>
</tr>
<tr>
<td>MS Encarta Encyclopedia Delux 2004 (3CD) </td><td>Retail price: $181.99 </td><td><font color=red size="+1">Our Price: $80.00</font></td><td><font color=green>You Save: $101.99</font> </td>
</tr>

</table>
<div align="center"> <a href="http://angelic.fhclicbh.info/?creNetIxJMPBucIwilliamsburg"><font style="FONT-SIZE: 1px">rubbery</font> <font style="FONT-SIZE: 16px">More </font><font style="FONT-SIZE: 1px">blurry</font> <font style="FONT-SIZE: 16px"> Software </font><font style="FONT-SIZE: 1px">northwestern</font> <font style="FONT-SIZE: 16px"> Listing </font><font style="FONT-SIZE: 1px">drain</font> Here!!!</a> </div>
<br>

destabilizepostludesnuffkalamazoomamboadrenalinehauntactivismsuccessivejoycestandstillcatholicbetelcharlemagnevalhalladenumerableinorganicaileroneaseltangentantonyplumpbellamycrypticsparlingemigrantdualismgreylagsiltationbeepthinnishlaundergrenademalignesmarkbattransferralsurfeitkspensionsickcoffeepotbunchpugnaciousglowpairwisefeldsparswingablemultiplexoratlantesgreenwoodtenthmercilesslychorusmilitantisraeliteconditionvetnairtrigfredfifthdirectricescantorperspicuousbasteshuttlecockfamineindolentcertificatesignalsuffocatefinalculinarycourteousscourgecationracewaypompadourepochbirdbathzealothelmsmandivisibledecathlonfaustushaleyjoveshapirotopologizecotillionjeffreyineluctableoneroussummitryreddenfrenchcoalesceethnologyprefectureginnstaccatodadintoxicantpresumptuoussharkjacobeanapplianceleadsmenpetersenprecedentetiquettepamnecessitysurgicalplatoonfillipcantabrigiancallouswatchdogannettepresbyterydopanttitanicgodheadcontinuowrotelinseedtransposablepaloindivisiblenichromeglomcatnipyoreplaintiffcoriander

</body>

</html>

Re: [Numpy-discussion] Using dotblas

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

Robert Kern wrote:

> Check the last few lines of Numeric.py .

Argh.  Could've saved myself the embarrasment :)

In my meager defense, the README.html file for doblas then needs to be 
updated, since that's what I followed:

# quote

Finally, if you don't know whether dotblas will be available on all the 
machines where you whish to run your code, you can simply use a try-except 
statement like this:

import Numeric
try:
     import dotblas
     Numeric.dot = dotblas.dot
  if we can't find the fast dotblas, just use the normal dot
except ImportError: pass

# /quote


Thanks, though.  I'll clean up my codes

f

[Numpy-discussion] Using dotblas

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

Hi all,

I've built NumPy 23.1 with dotblas enabled, and as per the readme I'm starting 
to pepper my code with things like:

# External packages
import Numeric as N

# Use BLAS-optimized versions when available
try:
     import dotblas
     N.dot = dotblas._dotblas.matrixproduct
     N.multiarray.innerproduct = dotblas._dotblas.innerproduct
except ImportError:
     print '*** dotblas not available, using regular Numeric functions'


I wonder if this is really necessary, and if so, why.

Is there any reason _not_ to use the dotblas versions when available?  If not, 
shouldn't Numeric itself pick them up internally so that it always exposes the 
fastest possible version?

I can always send in a patch to do this ( a trivial 5-liner like the above 
code), but I may just be missing something, as it seems too obvious not to be 
already the default.

Regards,

f.

RE: [Numpy-discussion] arrayfns.histogram does it exist in numarray?

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

Jean-Bernard Addor wrote:
> I am analysing data in hdf files with Numeric. For different reasons,
> including better support of hdf files (huge datasets), I try to switch to
> numarray. I uses a lot the arrayfns.histogram function of Numeric, does
> something similar exist in nummarray?
> 
Not as such yet (we have our own more specialized histogram
function for internal projects, but hadn't gotten around to 
generalizing it for general use). I think we'll take a quick
look at seeing if the Numeric arrayfns extension can be recompiled
to use numarray with no or few changes. Since Todd is away,
this won't be done until next week. I also have a simple
Python function to do this, albeit more slowly (but not hugely
slower) if you need something quickly.

Perry

[Numpy-discussion] arrayfns.histogram does it exist in numarray?

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

Hello !

I am analysing data in hdf files with Numeric. For different reasons,
including better support of hdf files (huge datasets), I try to switch to
numarray. I uses a lot the arrayfns.histogram function of Numeric, does
something similar exist in nummarray?

See you,

	Jean-Bernard

RE: [Numpy-discussion] Subclassing NumArray: _PROTOTYPE flag issue

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

OK it is my mistake, I did not implement the buffer argument in the =
constructor of my derived class. Still I have some minor problems, but =
nothing to bother about for the time being.

It is very compelling to subclass NumArray, I wish that it will be =
documented when version 1.0 will be released.

  Nadav


-----Original Message-----
From:	Perry Greenfield [mailto:pe...@st...]
Sent:	Mon 14-Jun-04 21:27
To:	Nadav Horesh; numpy
Cc:=09
Subject:	RE: [Numpy-discussion] Subclassing NumArray: _PROTOTYPE flag =
issue
Unfortunately Todd is away this week. I can try to help if you
can illustrate what is being tried in the more complex
script that you are referring to that is failing.

Offhand, I didn't believe that _PROTOTYPE should ever be
set to 0 unless it was done so explicitly for testing or
debugging purposes (but perhaps I misremember).

Thanks, Perry

Nadav Horesh wrote:
> For a simulation project I am working on I've subclasses ArrayType. I
> was able to do much of my intentions until in one place when I tried =
to
> make an array from a list of arrays I got an error message:
>
> .
> .
> .
>   File
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", =
line
> 325, in array
>     return fromlist(sequence, type, shape)
>   File
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", =
line
> 212, in fromlist
>     a =3D a.astype(type)
>   File
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", =
line
> 630, in astype
>     retarr =3D self.__class__(buffer=3DNone, shape=3Dself._shape, =
type=3Dtype)
> TypeError: __init__() got an unexpected keyword argument 'buffer'
>
> The analysis of the code showed that:
>
>    1. The NumArray class method definitions depends on the _PROTOTYPE =
flag
>    2. The post-mortem debugging showed that when the error flagged, =
the
>       value of the variable _PROTOTYPE was 0
>
> In a stand alone script there was no problem to do the list-> array
> conversion:
>
>  >>> import numarray as N
>  >>> import NumImage as NI        # My module with the derived class
>  >>> a =3D N.arange(4)
>  >>> ia =3D NI.Cimage(N.arange(4))  # CImage is a derivative of =
NumImage
>  >>> a
> array([0, 1, 2, 3])
>  >>> ia
> Cimage([0, 1, 2, 3])
>  >>> N.array([a+i for i in range(3)])
> array([[0, 1, 2, 3],
>        [1, 2, 3, 4],
>        [2, 3, 4, 5]])
>  >>> N.array([ia+i for i in range(3)])  # OK here, but failed as a =
part
> of a complex script
> Cimage([[0, 1, 2, 3],
>        [1, 2, 3, 4],
>        [2, 3, 4, 5]])
>
>
> My questions are:
>
>    1. Is this flag is in use? If I set it to 0 will I be able to =
derive
>       a class from the "C code"?
>    2. Any intelligent solution?
>
>   Nadav.
>
>
> -------------------------------------------------------
> 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
>

[Numpy-discussion] numarray.sum should raise exception for wrong axis argument

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

Hi,
please take a look at this:
>>> na.sum( na.zeros((2,6)) )
[0 0 0 0 0 0]
>>> na.sum( na.zeros((2,6)) , 0)
[0 0 0 0 0 0]
>>> na.sum( na.zeros((2,6)) , 1)
[0 0]
>>> na.sum( na.zeros((2,6)) , 2)
[0 0]
>>> na.sum( na.zeros((2,6)) , 3)
[0 0]
>>> na.sum( na.zeros((2,6)) , 4)
[0 0]
>>> na.sum( na.zeros((2,6)) , -1)
[0 0]
>>> na.sum( na.zeros((2,6)) , -2)
[0 0 0 0 0 0]
>>> na.sum( na.zeros((2,6)) , -3)
[0 0]
>>> na.sum( na.zeros((2,6)) , -4)
[0 0]
>>> 

I think here should be a ValueError exception thrown rather than defaulting to 
the '-1'-axis.  Comments ?

Thanks,
Sebastian Haase

RE: [Numpy-discussion] Subclassing NumArray: _PROTOTYPE flag issue

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

Unfortunately Todd is away this week. I can try to help if you
can illustrate what is being tried in the more complex
script that you are referring to that is failing.

Offhand, I didn't believe that _PROTOTYPE should ever be
set to 0 unless it was done so explicitly for testing or
debugging purposes (but perhaps I misremember).

Thanks, Perry

Nadav Horesh wrote:
> For a simulation project I am working on I've subclasses ArrayType. I
> was able to do much of my intentions until in one place when I tried to
> make an array from a list of arrays I got an error message:
>
> .
> .
> .
>   File
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line
> 325, in array
>     return fromlist(sequence, type, shape)
>   File
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line
> 212, in fromlist
>     a = a.astype(type)
>   File
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line
> 630, in astype
>     retarr = self.__class__(buffer=None, shape=self._shape, type=type)
> TypeError: __init__() got an unexpected keyword argument 'buffer'
>
> The analysis of the code showed that:
>
>    1. The NumArray class method definitions depends on the _PROTOTYPE flag
>    2. The post-mortem debugging showed that when the error flagged, the
>       value of the variable _PROTOTYPE was 0
>
> In a stand alone script there was no problem to do the list-> array
> conversion:
>
>  >>> import numarray as N
>  >>> import NumImage as NI        # My module with the derived class
>  >>> a = N.arange(4)
>  >>> ia = NI.Cimage(N.arange(4))  # CImage is a derivative of NumImage
>  >>> a
> array([0, 1, 2, 3])
>  >>> ia
> Cimage([0, 1, 2, 3])
>  >>> N.array([a+i for i in range(3)])
> array([[0, 1, 2, 3],
>        [1, 2, 3, 4],
>        [2, 3, 4, 5]])
>  >>> N.array([ia+i for i in range(3)])  # OK here, but failed as a part
> of a complex script
> Cimage([[0, 1, 2, 3],
>        [1, 2, 3, 4],
>        [2, 3, 4, 5]])
>
>
> My questions are:
>
>    1. Is this flag is in use? If I set it to 0 will I be able to derive
>       a class from the "C code"?
>    2. Any intelligent solution?
>
>   Nadav.
>
>
> -------------------------------------------------------
> 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] ObjectArray

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

Todd Miller wrote:

>On Fri, 2004-06-11 at 10:53, Colin J. Williams wrote:
>  
>
>>Todd,
>>
>>I'm trying out objects.py from the CVS as of June 11, with PROTOTYPE=
>>1
>>
>>Suggestions and comments based on that.
>>
>>1.  change the order in ObjectsArray so the __init__ becomes:
>>                def __init__(self, objects=None, shape=None,
>>rank=None):
>>     The thinking is that, in the absence of others, objects is the
>>argument most likely to be specified.
>>    
>>
>
>I think this can go either way.  For people that care,  there are
>already array() and fromlist().  Subclasses can override the order.  Am
>I missing something?
>
The convenience of being able to call the ObjectArray constructor 
without using keywords. 
For this purpose, I suggest that it's best to order the parameters in 
the most likely frequency of usage. 

I've found that it's not good to have a subclass with a different 
signature.  A generic call to a constructor is as likely to call the 
subclass as the class.

>>2.  add a check in __init__ to ensure that the shape is in fact
>>shape-like.
>>    
>>
>
>Right now it raises a TypeError, and although it's ugly, it does at
>least trap the error and give a clue in the right direction.
>
The error traceback is rather deep and doesn't directly point to the 
source of the problem.

>>3.  real doc strings would be helpful.  Currently, the doc strings are
>>monopolized by the doctest stuff, 
>>     which was  not  the original intent of doc strings.
>>    
>>
>
>True enough.  Maybe for 1.1.
>  
>
This is particularly important for objects which are not elsewhere 
documented, including private functions.

>>4.  I wonder about the need for both rank and shape.  NumArray gets
>>along fine with just shape.
>>    
>>
>
>This is a new feature, and is useful in the context of object arrays
>where a sequence object is an ambiguous thing:  should the sequence be
>seen as containing elements of an object array, or itself an element of
>the object array.  rank lets you specify the rank of the resulting
>object array explicitly.  It is also computed implicitly if not
>specified based on the first object which doesn't match the type of the
>original sequence.  This is new for 1.0.
>
I hadn't spotted that rank gives one the opportunity to specify the 
dimensionality of  objects, but
shape provides another way of doing it.

>>5.  It is assumed that objects (in __init__) is a sequence, but no
>>check to make sure that it is.
>>    
>>
>
>Actually, for 1.0 I don't even think it has to be a sequence anymore. 
>It's possible to make a rank-0 object array.
>  
>
Yes, it is, this adds to the generality.

>>6.  _byteorder is specified for NumArray, but not for ObjectArray,
>>this upsets a utility which 
>>     looks at array   characteristics.
>>    
>>
>
>_byteorder is a private attribute which doesn't make sense for
>ObjectArray.  Add exception handling to the utility if it must be used
>with ObjectArrays.
>
I'll do that.

>
>  
>
>>7.  How is an ObjectArray better than a nested list of objects?  It
>>seems to provide speedier access
>>     to object pointers for larger n.  It may offer the opportunity 
>>to present data in a more organized
>>     tabular manner.  Dictionaries are better, in that they provide
>>access by means of an arbitrary key, 
>>     for the cost of hashing.
>>
>>     NumArray appears to offer storage saving, in addition to the
>>above, but not here.
>>
>>     Am I missing something?  
>>    
>>
>
>ObjectArrays can be indexed, manipulated, and printed like numarrays. 
>ObjectArrays also work with object array ufuncs, so for instance, adding
>two ObjectArrays together implicitly applies the add builtin to each
>pair of elements.  These ufuncs even support reductions and
>accumulations.  This *is* a good question,   but I still think
>ObjectArrays are useful in some contexts.
>
The ability to use the ufuncs is potentially good, but presumably 
assumes a homogeneous ObjectArray.
We can't mix strings and dictionaries.

>
>Thanks for the feedback.
>
>Regards,
>Todd
>
>  
>
Many thanks for your response.  ObjectArray provides a flexible addition 
to numarray.

Colin W

>
>  
>

[Numpy-discussion] Subclassing NumArray: _PROTOTYPE flag issue

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

For a simulation project I am working on I've subclasses ArrayType. I 
was able to do much of my intentions until in one place when I tried to 
make an array from a list of arrays I got an error message:

.
.
.
  File 
"/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
325, in array
    return fromlist(sequence, type, shape)
  File 
"/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
212, in fromlist
    a = a.astype(type)
  File 
"/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
630, in astype
    retarr = self.__class__(buffer=None, shape=self._shape, type=type)
TypeError: __init__() got an unexpected keyword argument 'buffer'

The analysis of the code showed that:

   1. The NumArray class method definitions depends on the _PROTOTYPE flag
   2. The post-mortem debugging showed that when the error flagged, the
      value of the variable _PROTOTYPE was 0

In a stand alone script there was no problem to do the list-> array 
conversion:

 >>> import numarray as N
 >>> import NumImage as NI        # My module with the derived class
 >>> a = N.arange(4)
 >>> ia = NI.Cimage(N.arange(4))  # CImage is a derivative of NumImage
 >>> a
array([0, 1, 2, 3])
 >>> ia
Cimage([0, 1, 2, 3])
 >>> N.array([a+i for i in range(3)])
array([[0, 1, 2, 3],
       [1, 2, 3, 4],
       [2, 3, 4, 5]])
 >>> N.array([ia+i for i in range(3)])  # OK here, but failed as a part 
of a complex script
Cimage([[0, 1, 2, 3],
       [1, 2, 3, 4],
       [2, 3, 4, 5]])


My questions are:

   1. Is this flag is in use? If I set it to 0 will I be able to derive
      a class from the "C code"?
   2. Any intelligent solution?

  Nadav.

Re: [Numpy-discussion] ObjectArray

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

On Fri, 2004-06-11 at 10:53, Colin J. Williams wrote:
> Todd,
> 
> I'm trying out objects.py from the CVS as of June 11, with PROTOTYPE=
> 1
> 
> Suggestions and comments based on that.
> 
> 1.  change the order in ObjectsArray so the __init__ becomes:
>                 def __init__(self, objects=None, shape=None,
> rank=None):
>      The thinking is that, in the absence of others, objects is the
> argument most likely to be specified.

I think this can go either way.  For people that care,  there are
already array() and fromlist().  Subclasses can override the order.  Am
I missing something?

> 2.  add a check in __init__ to ensure that the shape is in fact
> shape-like.

Right now it raises a TypeError, and although it's ugly, it does at
least trap the error and give a clue in the right direction.

> 3.  real doc strings would be helpful.  Currently, the doc strings are
> monopolized by the doctest stuff, 
>      which was  not  the original intent of doc strings.

True enough.  Maybe for 1.1.

> 4.  I wonder about the need for both rank and shape.  NumArray gets
> along fine with just shape.

This is a new feature, and is useful in the context of object arrays
where a sequence object is an ambiguous thing:  should the sequence be
seen as containing elements of an object array, or itself an element of
the object array.  rank lets you specify the rank of the resulting
object array explicitly.  It is also computed implicitly if not
specified based on the first object which doesn't match the type of the
original sequence.  This is new for 1.0.

> 5.  It is assumed that objects (in __init__) is a sequence, but no
> check to make sure that it is.

Actually, for 1.0 I don't even think it has to be a sequence anymore. 
It's possible to make a rank-0 object array.

> 6.  _byteorder is specified for NumArray, but not for ObjectArray,
> this upsets a utility which 
>      looks at array   characteristics.

_byteorder is a private attribute which doesn't make sense for
ObjectArray.  Add exception handling to the utility if it must be used
with ObjectArrays.

> 7.  How is an ObjectArray better than a nested list of objects?  It
> seems to provide speedier access
>      to object pointers for larger n.  It may offer the opportunity 
> to present data in a more organized
>      tabular manner.  Dictionaries are better, in that they provide
> access by means of an arbitrary key, 
>      for the cost of hashing.
> 
>      NumArray appears to offer storage saving, in addition to the
> above, but not here.
> 
>      Am I missing something?  

ObjectArrays can be indexed, manipulated, and printed like numarrays. 
ObjectArrays also work with object array ufuncs, so for instance, adding
two ObjectArrays together implicitly applies the add builtin to each
pair of elements.  These ufuncs even support reductions and
accumulations.  This *is* a good question,   but I still think
ObjectArrays are useful in some contexts.

Thanks for the feedback.

Regards,
Todd

Re: [Numpy-discussion] Numarray problem on Opteron system, Suse 9.1

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

On Fri, 2004-06-11 at 09:37, Jason Ruiter wrote:
> Greetings,
> 
Hi,

I think you're getting into bleeding edge territory.   For numarray, 
the particular problem you exposed should be solved for 1.0,  but I
still think the overall 64-bit prognosis is not good.  There are API
issues in Python itself which are going to make really large arrays a
problem until they're solved; for instance, the sequence protocol
returns the length of a sequence as an int (32-bits on most platforms).

Regards,
Todd


> I'm running Suse 9.1 on a dual opteron system with 16GB of RAM.  I'm
> using Python 2.3.3, Numeric 23.1 and numarray 0.9.
> 
> I'm trying to allocate large (>4GB) arrays.  Under Numeric, I get:
> 
> Python 2.3.3 (#1, Apr  6 2004, 09:45:08)
> [GCC 3.3.3 (SuSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from Numeric import *
> >>> a=ones(2000000000,Int16);
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib64/python2.3/site-packages/Numeric/Numeric.py", line
> 578, in ones
>     a=zeros(shape, typecode, savespace)
> MemoryError: can't allocate memory for array
> >>>
> 
> Under numarray:
> 
> Python 2.3.3 (#1, Apr  6 2004, 09:45:08)
> [GCC 3.3.3 (SuSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from numarray import *
> >>> a=ones(2000000000,Int16)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib64/python2.3/site-packages/numarray/numarraycore.py",
> line 1111, in ones
>     retarr = _fillarray(_gen.product(shape), 1, 0, type)
>   File "/usr/lib64/python2.3/site-packages/numarray/numarraycore.py",
> line 144, in _fillarray
>     outarr = NumArray((size,), outtype)
> ValueError: new_memory: invalid region size: -294967296.
> >>>
> 
> 
> I've verified that python, Numeric, and numarray are built and linked
> against the 64bit libraries.
> 
> I've also verified that it's possible to allocate a >16GB Array with the
> following program I found on one of the debian mailling lists.
> :q:q:q!
> #include <stdio.h>
> #include <stdlib.h>
> int main()  {  size_t n;  void *p;  double gb;
>   for(gb=20;gb>.3;gb-=.5) {
>         n= 1024L * 1024L * 1024L * gb;
>         p = malloc( n );
>         printf("%12lu %4.1lfGb %p\n",n,n/1024./1024./1024.,p);
>         free(p); }  return 0;  }
> 
>  21474836480 20.0Gb (nil)
>  20937965568 19.5Gb (nil)
>  20401094656 19.0Gb (nil)
>  19864223744 18.5Gb (nil)
>  19327352832 18.0Gb (nil)
>  18790481920 17.5Gb (nil)
>  18253611008 17.0Gb (nil)
>  17716740096 16.5Gb 0x3995a02010
>  17179869184 16.0Gb 0x3995a02010
>  16642998272 15.5Gb 0x3995a02010
>  16106127360 15.0Gb 0x3995a02010
>  15569256448 14.5Gb 0x3995a02010
>  15032385536 14.0Gb 0x3995a02010
>  14495514624 13.5Gb 0x3995a02010
>  13958643712 13.0Gb 0x3995a02010
>  13421772800 12.5Gb 0x3995a02010
>  12884901888 12.0Gb 0x3995a02010
>  12348030976 11.5Gb 0x3995a02010
>  11811160064 11.0Gb 0x3995a02010
>  11274289152 10.5Gb 0x3995a02010
>  10737418240 10.0Gb 0x3995a02010
>  10200547328  9.5Gb 0x3995a02010
>   9663676416  9.0Gb 0x3995a02010
>   9126805504  8.5Gb 0x3995a02010
>   8589934592  8.0Gb 0x3995a02010
>   8053063680  7.5Gb 0x3995a02010
>   7516192768  7.0Gb 0x3995a02010
>   6979321856  6.5Gb 0x3995a02010
>   6442450944  6.0Gb 0x3995a02010
>   5905580032  5.5Gb 0x3995a02010
>   5368709120  5.0Gb 0x3995a02010
>   4831838208  4.5Gb 0x3995a02010
>   4294967296  4.0Gb 0x3995a02010
>   3758096384  3.5Gb 0x3995a02010
>   3221225472  3.0Gb 0x3995a02010
>   2684354560  2.5Gb 0x3995a02010
>   2147483648  2.0Gb 0x3995a02010
>   1610612736  1.5Gb 0x3995a02010
>   1073741824  1.0Gb 0x3995a02010
>    536870912  0.5Gb 0x3995a02010
> 
> 
> Can someone point me in the right direction?
> 
> Thanks
> Jason
-- 
Todd Miller <jm...@st...>

[Numpy-discussion] Numarray problem on Opteron system, Suse 9.1

[Jason R. <Jas...@al...>]

Greetings,

I'm running Suse 9.1 on a dual opteron system with 16GB of RAM.  I'm
using Python 2.3.3, Numeric 23.1 and numarray 0.9.

I'm trying to allocate large (>4GB) arrays.  Under Numeric, I get:

Python 2.3.3 (#1, Apr  6 2004, 09:45:08)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Numeric import *
>>> a=ones(2000000000,Int16);
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib64/python2.3/site-packages/Numeric/Numeric.py", line
578, in ones
    a=zeros(shape, typecode, savespace)
MemoryError: can't allocate memory for array
>>>

Under numarray:

Python 2.3.3 (#1, Apr  6 2004, 09:45:08)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from numarray import *
>>> a=ones(2000000000,Int16)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib64/python2.3/site-packages/numarray/numarraycore.py",
line 1111, in ones
    retarr = _fillarray(_gen.product(shape), 1, 0, type)
  File "/usr/lib64/python2.3/site-packages/numarray/numarraycore.py",
line 144, in _fillarray
    outarr = NumArray((size,), outtype)
ValueError: new_memory: invalid region size: -294967296.
>>>


I've verified that python, Numeric, and numarray are built and linked
against the 64bit libraries.

I've also verified that it's possible to allocate a >16GB Array with the
following program I found on one of the debian mailling lists.
:q:q:q!
#include <stdio.h>
#include <stdlib.h>
int main()  {  size_t n;  void *p;  double gb;
  for(gb=20;gb>.3;gb-=.5) {
        n= 1024L * 1024L * 1024L * gb;
        p = malloc( n );
        printf("%12lu %4.1lfGb %p\n",n,n/1024./1024./1024.,p);
        free(p); }  return 0;  }

 21474836480 20.0Gb (nil)
 20937965568 19.5Gb (nil)
 20401094656 19.0Gb (nil)
 19864223744 18.5Gb (nil)
 19327352832 18.0Gb (nil)
 18790481920 17.5Gb (nil)
 18253611008 17.0Gb (nil)
 17716740096 16.5Gb 0x3995a02010
 17179869184 16.0Gb 0x3995a02010
 16642998272 15.5Gb 0x3995a02010
 16106127360 15.0Gb 0x3995a02010
 15569256448 14.5Gb 0x3995a02010
 15032385536 14.0Gb 0x3995a02010
 14495514624 13.5Gb 0x3995a02010
 13958643712 13.0Gb 0x3995a02010
 13421772800 12.5Gb 0x3995a02010
 12884901888 12.0Gb 0x3995a02010
 12348030976 11.5Gb 0x3995a02010
 11811160064 11.0Gb 0x3995a02010
 11274289152 10.5Gb 0x3995a02010
 10737418240 10.0Gb 0x3995a02010
 10200547328  9.5Gb 0x3995a02010
  9663676416  9.0Gb 0x3995a02010
  9126805504  8.5Gb 0x3995a02010
  8589934592  8.0Gb 0x3995a02010
  8053063680  7.5Gb 0x3995a02010
  7516192768  7.0Gb 0x3995a02010
  6979321856  6.5Gb 0x3995a02010
  6442450944  6.0Gb 0x3995a02010
  5905580032  5.5Gb 0x3995a02010
  5368709120  5.0Gb 0x3995a02010
  4831838208  4.5Gb 0x3995a02010
  4294967296  4.0Gb 0x3995a02010
  3758096384  3.5Gb 0x3995a02010
  3221225472  3.0Gb 0x3995a02010
  2684354560  2.5Gb 0x3995a02010
  2147483648  2.0Gb 0x3995a02010
  1610612736  1.5Gb 0x3995a02010
  1073741824  1.0Gb 0x3995a02010
   536870912  0.5Gb 0x3995a02010


Can someone point me in the right direction?

Thanks
Jason



-- 
Jason Ruiter
Research Scientist
Environment and Emerging Technologies Division
Altarum Institute
Ann Arbor, Michigan, USA
(v)734.302.4724 (f)734.302.4991 (m)248.345.4598
Jas...@Al...

[Numpy-discussion] ObjectArray

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

ObjectArray, in objects.py,  seems to offer a neat packaging capability.

The examples focus on sting data, but it appears capable of handling all 
simple types and some container types.

What is the intent?

Dictionaries seem OK, tuples are OK when the shape is not specified, but 
an instance of ObjectArray fails.

Colin W.

Re: [Numpy-discussion] RandomArray.random()

[Bruce S. <so...@ui...>]

Hi,
I would be prepared to at least look at it with numarray if you are prepared to
share the scripts or rather the relevant part of them. On the surface, it would
appear that this is a 32 vs 64 bit problem in defining the type precision. 

Regards
Bruce

---- Original message ----
>Date: Thu, 3 Jun 2004 14:18:56 +0300
>From: Janne Sinkkonen <jan...@hu...>  
>Subject: [Numpy-discussion] RandomArray.random()  
>To: num...@li...
>
>Related to a recent discussion on random numbers:
>
>People using RandomArray.random() on 64-bit architectures should also be aware 
>that sometimes the function returns exactly zero or one, which in turn causes 
>problems in many other routines which generate e.g. multinomial or dirichlet 
>variates.
>
>I'm not absolutely sure that the problem persists in the newest version of 
>Numeric, and I have not tested it on numarray. Anyway, I have seen it both in 
>Alphas and now later in an AMD Opteron machine - over the years.
>
>Unfortunately, as we do not have had time to dig any deeper around here, we 
>have just used wrapper with a test and a loop.
>
>-- 
>Janne
>
>
>
>-------------------------------------------------------
>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

[Numpy-discussion] rank-0 arrays: Something useful

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

One can use rank 0 arrays instead of scalars to automatically promote 
type of scalar-array
operations:

 >>> from numarray import *
 >>> a = arange(10, type=Int16)
 >>> a * 10
array([ 0, 10, 20, 30, 40, 50, 60, 70, 80, 90], type=Int16)  # same type
 >>> a * array(10, type=Int32)
array([ 0, 10, 20, 30, 40, 50, 60, 70, 80, 90])              # Type 
promoted to Int32

Is there any way to economically set the type of the operation result?
something like:
multiply(a,b, type=xxx)   # Doesn't work
instead of:
(a*b).astype(xxx)


  Nadav.

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

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

> 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

I see the logic of the recursing but it was unexpected in this 
particular example. The rank parameter is a solution, but I don't think 
it is very elegant to be honest. rank=1 should certainly not be the 
default, because it would not work if the rank of the desired object 
array is not one... For example, I want to make object arrays of 
arbitrary rank containing numarrays, so I would need to specify the 
rank anyway.

How about stopping the recursion as soon as an object is found that is 
not a sequence, or that is a sequence of but of a different type? In my 
example the outer sequence is a list and the objects are arrays, so as 
soon as a array is seen the recursion would stop, giving the desired 
behavior.

Is this idea too complex? If not, could some optional argument switch 
to this behaviour? Or maybe some special value for rank (-1) could be 
used for that? The rank parameter would still be useful if you want to 
stop the recursion in a nested list, then you must give some kind of 
hint anyway.

It would give the desired behavior in many cases, so I would actually 
prefer to see something like that as the default. Maybe my suggestion 
would not break things to much since nesting different types of 
sequence to generate a homogeneous object array may not be done often 
anyway (its not what you want usually, I guess).

Cheers, Peter