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

[Numpy-discussion] Problem of downloading Numeric 22.0 win 32 py 2.2 exe

[jean.moser <jea...@wa...>]

Hi everybody !

I tried to download Numpy trough Belnet Mirror site. On the Wizard of =
prof. Dubois I could read "Python ver. 2.2 found in registry". On the =
next window nothing happend on the field "Installation in progress". On  =
the next system window I had a message saying that the program would =
stop due to a non-accepted operation.I asked for details and I could =
read:
"Num has caused a page bug in the=20
    kernel module 32-py 2.3 exe"

Can you help me ?

Jean
   =20

Re: [Numpy-discussion] Small integers not promoted for calculations

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

I logged this on SF.  I extended the type promotion mappings to include
the lower precision integer types and committed it to CVS.  I was going
to give you a link in the ViewCVS so you could look it over,  but that
info appears to be stale.

Try this tomorrow:
http://cvs.sourceforge.net/viewcvs.py/numpy/numarray/Packages/LinearAlgebra2/Lib/

Thanks,
Todd

-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

[Numpy-discussion] Small integers not promoted for calculations

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

This may have been logged already.

Colin W.

#tz.py
import numarray as N
import numarray.linear_algebra as L
b= N.array([[1, 2], [8, 3]], type= N.Int8)
print b
if b.type() not in L.LinearAlgebra2._array_kind:
  # Undocumented feature - Int8 or In16 not handled, try promotion
  b= b.astype(N.Int32)
  pass
c= L.inverse(b)
print c
pass

Traceback (most recent call last):
  File 
"C:\PROGRA~1\Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", 
line 307, in RunScript
    debugger.run(codeObject, __main__.__dict__, start_stepping=0)
  File 
"C:\PROGRA~1\Python23\lib\site-packages\Pythonwin\pywin\debugger\__init__.py", 
line 60, in run
    _GetCurrentDebugger().run(cmd, globals,locals, start_stepping)
  File 
"C:\PROGRA~1\Python23\lib\site-packages\Pythonwin\pywin\debugger\debugger.py", 
line 591, in run
    exec cmd in globals, locals
  File "C:\Documents and Settings\cjw\Work\Test\tz.py", line 10, in ?
    c= L.inverse(b)
  File 
"C:\PROGRA~1\Python23\lib\site-packages\numarray\linear_algebra\LinearAlgebra2.py", 
line 141, in inverse
    return solve_linear_equations(a, num.identity(a.getshape()[0]))
  File 
"C:\PROGRA~1\Python23\lib\site-packages\numarray\linear_algebra\LinearAlgebra2.py", 
line 121, in solve_linear_equations
    t =_commonType(a, b)
  File 
"C:\PROGRA~1\Python23\lib\site-packages\numarray\linear_algebra\LinearAlgebra2.py", 
line 60, in _commonType
    kind = max(kind, _array_kind[t])
KeyError: Int8
 >>>

[Numpy-discussion] compilation issues

[<jo...@jo...>]

On Wed, 01 Oct 2003 10:39:16 +0200 Jochen K=FCpper wrote:

Jochen> Moreover I have a compilation issue which is probably a gcc bug, but
Jochen> here we go:=20
Jochen> ,----
Jochen> | > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/n=
umarray -I/usr/include/python2.2 -c Src/_ufuncComplex32module.c -o build/te=
mp.linux-i686-2.2/_ufuncComplex32module.o -g -march=3Dpentium4 -pipe -Wall
Jochen> | Src/_ufuncComplex32module.c: In function `multiply_Complex32_redu=
ce':
Jochen> | Src/_ufuncComplex32module.c:401: unable to find a register to spi=
ll in class `FLOAT_REGS'
Jochen> | Src/_ufuncComplex32module.c:401: this is the insn:
Jochen> | (insn 65 63 67 (set (reg/v:DF 10 st(2) [74])
Jochen> |         (float_extend:DF (subreg:SF (reg/v:DI 21 rxmm0 [71]) 0)))=
 133 {*extendsfdf2_1} (nil)
Jochen> |     (nil))
Jochen> | Src/_ufuncComplex32module.c:401: confused by earlier errors, bail=
ing out
Jochen> `----

Ok, got a reply from the gcc team: bug confirmed for 3.2.x, fixed in 3.3.1.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] latest cvs issues

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

On Wed, 2003-10-01 at 07:55, Jochen K=C3=BCpper wrote:
> On 01 Oct 2003 06:28:45 -0400 Todd Miller wrote:
>=20
> Todd> On Wed, 2003-10-01 at 04:39, Jochen K=C3=BCpper wrote:
>=20
> >> | # Set to 0 if you have your own platform optimized BLAS and LAPACK.
> >> | # When I tried this under RH8.0 i386 Linux, there was at least one
> >> | # unresolved symbol.
>=20
> [...]
>=20
> Todd> Excellent.  I guess the comment should disappear.
>=20
> You take it out then?:)
>=20
Done.

--=20
Todd Miller 			jm...@st...
STSCI / ESS / SSB

Re: [Numpy-discussion] latest cvs issues

[<jo...@jo...>]

On 01 Oct 2003 06:28:45 -0400 Todd Miller wrote:

Todd> On Wed, 2003-10-01 at 04:39, Jochen K=FCpper wrote:

>> | # Set to 0 if you have your own platform optimized BLAS and LAPACK.
>> | # When I tried this under RH8.0 i386 Linux, there was at least one
>> | # unresolved symbol.

[...]

Todd> Excellent.  I guess the comment should disappear.

You take it out then?:)


>> Latest cvs gives the following test error:

[...]

Todd> This is a known bug in Python, fixed in 2.2.2 and up.

Ok, guess we have to upgrade then.


>> Moreover I have a compilation issue which is probably a gcc bug, but
>> here we go:=20

[The problem was '-march=3Dpentium4'.]

Todd> What version of Python and gcc was this? (I don't normally use
Todd> /usr/bin/python, but stock RH 8.0 seems to work OK for me)

gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)

I did file a gcc bug report, as it looks like an issue with its
optimizer or architecture specific back-end.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] Migrating Char arrays

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

A Dimecres 01 Octubre 2003 10:57, Marc Poinot va escriure:
> Francesc Alted wrote:
> > >>> from numarray import strings
>
> This solves the python lib problem, but not the API problem. In the API,
> I've got some arrays, and when I want to store these arrays in CGNS I
> cannot decide if an UInt32 is a string or not. Then I'll have to manage my
> string arrays as specific types, but not arrays...

I use something like:

    isinstance(arr, numarray.strings.CharArray)

in my C extensions. I'm using Pyrex to do that and it is responsible to
generate the appropriate C code, so, a priori, this is also possible from C.

> I'll have to add an attribute to arrays to indicate that it is a string,
> if so then I should store it in CGNS as C1 array.

That's another possibility

>
> Is there a reason why Char type is not taken into account in numarray ?
> Well known data representation or storage systems as netCDF or HDF, or
> even ADF (our CGNS storage system) have a Char type...

In the numarray.records module there is a Char type defined as:

class Char:
    """ data type Char class"""
    bytes = 1
    def __repr__(self):
        return "CharType"

CharType = Char()

But this is not defined widely in all the numarray package. Perhaps there is
a good reason for not doing that, but I can't figure it now.

-- 
Francesc Alted

Re: [Numpy-discussion] latest cvs issues

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

On Wed, 2003-10-01 at 04:39, Jochen Küpper wrote:
> Some observations:
> 
> In addons.py I found the following statement:
> ,----
> | # Set to 0 if you have your own platform optimized BLAS and LAPACK.
> | # When I tried this under RH8.0 i386 Linux, there was at least one
> | # unresolved symbol.
> `----

It was my comment...

> Which symbol was that? 

I didn't remember then and certainly don't now.  I was trying to brace
the reader for the possibility that "optimized library activation" might
need further work.

> It seems to work for me on RedHat 8.0 using
> RedHat's BLAS and LAPACK.
> 

Excellent.  I guess the comment should disappear.
> 
> 
> Latest cvs gives the following test error:
> ,----
> | Test of inplace operations and rich comparisons
> | Traceback (most recent call last):
> |   File "<stdin>", line 1, in ?
> |   File "/usr/lib/python2.2/site-packages/numarray/testall.py", line 19, in test
> |     result = eval(p+".test()")
> |   File "<string>", line 0, in ?
> |   File "/usr/lib/python2.2/site-packages/numarray/ma/dtest.py", line 635, in test
> |     test8()
> |   File "/usr/lib/python2.2/site-packages/numarray/ma/dtest.py", line 434, in test8
> |     x *= 2.0
> | TypeError: can't multiply sequence to non-int
> | >>>
> `----

This is a known bug in Python, fixed in 2.2.2 and up.

> 
> 
> Moreover I have a compilation issue which is probably a gcc bug, but
> here we go: 
> ,----
> | > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/numarray -I/usr/include/python2.2 -c Src/_ufuncComplex32module.c -o build/temp.linux-i686-2.2/_ufuncComplex32module.o -g -march=pentium4 -pipe -Wall
> | Src/_ufuncComplex32module.c: In function `multiply_Complex32_reduce':
> | Src/_ufuncComplex32module.c:401: unable to find a register to spill in class `FLOAT_REGS'
> | Src/_ufuncComplex32module.c:401: this is the insn:
> | (insn 65 63 67 (set (reg/v:DF 10 st(2) [74])
> |         (float_extend:DF (subreg:SF (reg/v:DI 21 rxmm0 [71]) 0))) 133 {*extendsfdf2_1} (nil)
> |     (nil))
> | Src/_ufuncComplex32module.c:401: confused by earlier errors, bailing out
> `----
> (If I compile with -march=pentium3 it works just fine.)
> 
> Maybe someone has a comment here? (If I have some more time I'll file
> a gcc bug report.)

What version of Python and gcc was this?  (I don't normally use
/usr/bin/python, but stock RH 8.0 seems to work OK for me)

> Greetings,
> Jochen
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Migrating Char arrays

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

Francesc Alted wrote:
> 
> >>> from numarray import strings
> 
This solves the python lib problem, but not the API problem. In the API,
I've got some arrays, and when I want to store these arrays in CGNS I cannot
decide if an UInt32 is a string or not. Then I'll have to manage my string
arrays as specific types, but not arrays...
I'll have to add an attribute to arrays to indicate that it is a string,
if so then I should store it in CGNS as C1 array.

Is there a reason why Char type is not taken into account in numarray ?
Well known data representation or storage systems as netCDF or HDF, or
even ADF (our CGNS storage system) have a Char type...

-MP-
-----------------------------------------------------------------------
 Marc POINOT             Alias: marcvs        Email: po...@on...
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: els...@on...
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr

[Numpy-discussion] latest cvs issues

[<jo...@jo...>]

Some observations:

In addons.py I found the following statement:
,----
| # Set to 0 if you have your own platform optimized BLAS and LAPACK.
| # When I tried this under RH8.0 i386 Linux, there was at least one
| # unresolved symbol.
`----
Which symbol was that? It seems to work for me on RedHat 8.0 using
RedHat's BLAS and LAPACK.



Latest cvs gives the following test error:
,----
| Test of inplace operations and rich comparisons
| Traceback (most recent call last):
|   File "<stdin>", line 1, in ?
|   File "/usr/lib/python2.2/site-packages/numarray/testall.py", line 19, i=
n test
|     result =3D eval(p+".test()")
|   File "<string>", line 0, in ?
|   File "/usr/lib/python2.2/site-packages/numarray/ma/dtest.py", line 635,=
 in test
|     test8()
|   File "/usr/lib/python2.2/site-packages/numarray/ma/dtest.py", line 434,=
 in test8
|     x *=3D 2.0
| TypeError: can't multiply sequence to non-int
| >>>
`----



Moreover I have a compilation issue which is probably a gcc bug, but
here we go:=20
,----
| > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/numarray =
-I/usr/include/python2.2 -c Src/_ufuncComplex32module.c -o build/temp.linux=
-i686-2.2/_ufuncComplex32module.o -g -march=3Dpentium4 -pipe -Wall
| Src/_ufuncComplex32module.c: In function `multiply_Complex32_reduce':
| Src/_ufuncComplex32module.c:401: unable to find a register to spill in cl=
ass `FLOAT_REGS'
| Src/_ufuncComplex32module.c:401: this is the insn:
| (insn 65 63 67 (set (reg/v:DF 10 st(2) [74])
|         (float_extend:DF (subreg:SF (reg/v:DI 21 rxmm0 [71]) 0))) 133 {*e=
xtendsfdf2_1} (nil)
|     (nil))
| Src/_ufuncComplex32module.c:401: confused by earlier errors, bailing out
`----
(If I compile with -march=3Dpentium3 it works just fine.)

Maybe someone has a comment here? (If I have some more time I'll file
a gcc bug report.)

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] Migrating Char arrays

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

Hi Marc,

A Dimarts 30 Setembre 2003 18:21, Marc Poinot va escriure:
>
> Is there something in numarray that could replace the Numeric interface
> for this string type? Is it difficult to add a 'Character' type?
> Is the (undocumented) CharArrayType the solution for this?

Yes, it is. See:

>>> from numarray import strings
>>> strings.array(["asd", "aa"])
CharArray(['asd', 'aa'])
>>> a=strings.array(["asd", "aa"])
>>> a[1]
'aa'
>>> a.raw()[1]   # If you want to get *all* spaces and nulls in strings
'aa '

This is undocumented in the manual, but it's quite well described in the doc
strings:

>>> help(strings.array)

Cheers,

-- 
Francesc Alted

[Numpy-discussion] Migrating Char arrays

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

Hi all,

I'm migrating my pyCGNS package to numarray. I think that numarray is
better suited for the in-memory share of array I'd like to achieve.

Now, with Numeric, I use to create arrays with integers, floats, but 
also char type.

In CGNS (http://www.cgns.org) we have types I4, I8, R4 and R8, but
also C1 which is an array of chars. It looks like, in numarray, we should
consider chars as unsigned ints. This is not false from a system point
of view, but from an application point of view I have to make a difference
between *real* char arrays, and unsigned int arrays. In other words, when
I have a C1 array, I have to translate it as a String, when I have an I4
or even I8, I have to translate it as Integer array. Now I only have
integers arrays, and I have to find out a way to know that my array of int
is a string. The CGNS->numarray translation is OK, but now I'm loosing
information when I'm going back numarray->CGNS.

You can say: It's up to your application to understand that this list of ints
is a string.

I'll reply: So why don't you consider a list of bytes, it's up to the application
to know that you're 32 or 64 bits...

Is there something in numarray that could replace the Numeric interface
for this string type? Is it difficult to add a 'Character' type?
Is the (undocumented) CharArrayType the solution for this?

Marcvs [alias Not using unicode...]

-----------------------------------------------------------------------
 Marc POINOT             Alias: marcvs        Email: po...@on...
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: els...@on...
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr

Re: [Numpy-discussion] numarray unfriendly to user defined types

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

On Fri, 2003-09-26 at 12:20, Tim Hochberg wrote:
> Todd Miller wrote:
> I'd make the same comment for this case as for the above case except 
> that all else being equal, subclasses should prevail over superclasses.
> 
> >I don't have a solution yet, but am hopeful that more free candy will
> >fall from the sky... or YAGNI.  Perry pointed out that similar problems
> >exist for *any* Python class hierarchy, so we're not alone, and perhaps
> >should forget about this until it matters.  If someone sees an easy
> >fix,  now would be better than later.
> >  
> >
> Here's some quick thoughts. In order for this to work out sensibly you 
> want the order between classes to be transistive and you probably also 
> always want to be able to insert a class into the order between any two 
> classes  This is equivalent to deciding the op priority based on a 
> comparison based on some real number associated with each class. This 
> leads to something like:
> 

Once again I think your ideas solve the problem, so thanks.  I have a
few things I wanted to bounce off you.

>    
> class NumArrayFamily:
>     op_priority = 0.0
>    
> # This makes it compatible with the current proposal , but isn't 
> strictly necessary.
> class DeferredToByNumarray(NumArrayFamily):
>     op_priority = 1000.0
>    
> class NumArrary(..., NumArrayFamily):
>     # ...
>     def __add__(self, object):
>         if isinstance(object, NumArrayFamily):
>             if ((object.op_priority > self.object.op_priority) or
>                 (object.op_priority == self.object.op_priority) and 
> issubclass(object, self.__class__)):
>                     return other.__radd__(self)
>         return ufunc.add(self, other)
> 
> 
> class MySubclassOfNumarray(NumArray):
>     op_priority = 10.0 # deffered to by NumArray, but defers to 
> DeferredToByNumarray classes.


As I understand it, 2.2 new style object subclass r-operators
automatically get priority (subclass.__radd__ is called in preference to
superclass.__add__).  I think this has two implications:

1) the ==/subclass term won't work, because __add__ will never get
called.

2) we have to redefine __radd__ as well to implement the priority
scheme.   I'm not sure the isinstance is necessary for __radd__,  but I
like the symmetry.

How does this look:

class DeferredToByNumArray: # name seems a little off now, but whatever
	pass

class NumArray(..., DeferredToByNumArray):
	op_priority = 0

	def __add__(self, object):
		if (isinstance(object, DeferredToByNumArray) and 
		    object.op_priority > self.op_priority):
			return object.__radd__(self)
		return ufunc.add(self, object)

	def __radd__(self, object):
		if (isinstance(object, DeferredToByNumArray) and
		    object.op_priority > self.op_priority):
			return object.__add__(self)
		return ufunc.add(object, self)

class MyForeignClass(DeferredToNumArray):
	op_priority = 1.0

class MySubclassOfNumArray(NumArray):
	op_priority = -1.0

> Of course the user still has to be careful to make sure the priority 
> order makes sense and you could have big problems when combining 
> packages with disprate ideas about priority levels, but I'm not sure how 
> you can get away from that.

As long as there's a scheme in place to resolve potential conflicts with
a little discussion,  I think your solution is already ahead of the
demand.

I told Colin last week I'd raise this issue on c.l.py.  I have decided
not to (although someone else could obviously do it if they are still
concerned about it),  because (a) the problem is solved,  (b) explaining
the problem well enough to get usable input is difficult and I've got
other stuff to do.

Thanks again for these ideas,

Todd

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

Re: [Numpy-discussion] Re: Cygwin compilation

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

Beautiful.  Thanks Jochen!


Todd

On Tue, 2003-09-30 at 09:58, Jochen Küpper wrote:
> With the current patch agianst cvs HEAD numarray compiles and passes
> all tests on current Cygwin:
> 
> cvs diff -u generate.py ChangeLog
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> Index: generate.py
> ===================================================================
> RCS file: /cvsroot/numpy/numarray/generate.py,v
> retrieving revision 1.14
> diff -u -u -r1.14 generate.py
> --- generate.py 16 Sep 2003 20:02:41 -0000      1.14
> +++ generate.py 30 Sep 2003 13:56:25 -0000
> @@ -51,6 +51,9 @@
>      LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0
>  elif sys.platform == "win32":
>      LP64, HAS_UINT64, HAS_FLOAT128 = 0, 0, 0
> +elif sys.platform == "cygwin":
> +    LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0
> +    EXTRA_LINK_ARGS += ["-L/lib", "-lm", "-lc", "-lgcc", "-L/lib/mingw", "-lmingwex"]
>  elif sys.platform == "darwin":
>      LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0
>      EXTRA_COMPILE_ARGS.extend(["-Ddarwin"])
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/numpy/numarray/ChangeLog,v
> retrieving revision 1.1
> diff -u -u -r1.1 ChangeLog
> --- ChangeLog   20 Apr 2002 16:13:38 -0000      1.1
> +++ ChangeLog   30 Sep 2003 13:56:25 -0000
> @@ -1,3 +1,13 @@
> +2003-09-30  Jochen Küpper  <jo...@jo...>
> +
> +       * generate.py (codeargs): Add cygwin case to link against libmingwex.
> +       This is a little tricky as _ufinc.dll needs to be linked against
> +       libmingwex, but libnumarray.dll normally picks up wrong symbols from
> +       this library. Therefore we explicitely add libm, libc, and libgcc before
> +       the mingw libraries to avoid the latter and still have them available to
> +       resolve the FE symbols. We also explicitely have to add -L/lib before
> +       -L/lib/mingw to check for normal cygwin libraries first.
> + 
>  2002-04-20  Jochen Küpper  <jo...@jo...>
>  
>         * MANIFEST.in: Updated.  
> @@ -9,5 +19,5 @@
>  
>         * Local Variables:
>         * mode: auto-fill
> -       * fill-column: 79
> +       * fill-column: 80
>         * End:
> 
> Greetings,
> Jochen
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Re: Cygwin compilation

[<jo...@jo...>]

With the current patch agianst cvs HEAD numarray compiles and passes
all tests on current Cygwin:

cvs diff -u generate.py ChangeLog
Warning: No xauth data; using fake authentication data for X11 forwarding.
Index: generate.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/numpy/numarray/generate.py,v
retrieving revision 1.14
diff -u -u -r1.14 generate.py
=2D-- generate.py 16 Sep 2003 20:02:41 -0000      1.14
+++ generate.py 30 Sep 2003 13:56:25 -0000
@@ -51,6 +51,9 @@
     LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
 elif sys.platform =3D=3D "win32":
     LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 0, 0
+elif sys.platform =3D=3D "cygwin":
+    LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
+    EXTRA_LINK_ARGS +=3D ["-L/lib", "-lm", "-lc", "-lgcc", "-L/lib/mingw",=
 "-lmingwex"]
 elif sys.platform =3D=3D "darwin":
     LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
     EXTRA_COMPILE_ARGS.extend(["-Ddarwin"])
Index: ChangeLog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/numpy/numarray/ChangeLog,v
retrieving revision 1.1
diff -u -u -r1.1 ChangeLog
=2D-- ChangeLog   20 Apr 2002 16:13:38 -0000      1.1
+++ ChangeLog   30 Sep 2003 13:56:25 -0000
@@ -1,3 +1,13 @@
+2003-09-30  Jochen K=FCpper  <jo...@jo...>
+
+       * generate.py (codeargs): Add cygwin case to link against libmingwe=
x.
+       This is a little tricky as _ufinc.dll needs to be linked against
+       libmingwex, but libnumarray.dll normally picks up wrong symbols from
+       this library. Therefore we explicitely add libm, libc, and libgcc b=
efore
+       the mingw libraries to avoid the latter and still have them availab=
le to
+       resolve the FE symbols. We also explicitely have to add -L/lib befo=
re
+       -L/lib/mingw to check for normal cygwin libraries first.
+=20
 2002-04-20  Jochen K=FCpper  <jo...@jo...>
=20
        * MANIFEST.in: Updated.=20=20
@@ -9,5 +19,5 @@
=20
        * Local Variables:
        * mode: auto-fill
=2D       * fill-column: 79
+       * fill-column: 80
        * End:

Greetings,
Jochen
=2D-=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

[Numpy-discussion] Re: Cygwin compilation

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

On Tue, 2003-09-30 at 04:44, Jochen K=C3=BCpper wrote:

> Should work, but I get the following strange behavior:
> ,----
> | > python setup.py build
> | Using EXTRA_COMPILE_ARGS =3D []
> | running build
> | running build_py
> | copying Lib/numinclude.py -> build/lib.cygwin-1.5.5-i686-2.3/numarray
> | running build_ext
> | building 'numarray._ufunc' extension
> | gcc -shared -Wl,--enable-auto-image-base -march=3Dpentium3 -mcpu=3Dpent=
ium4 -O2 -Wall -pipe build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o -L=
/usr/lib/python2.3/config -lpython2.3 -o build/lib.cygwin-1.5.5-i686-2.3/nu=
marray/_ufunc.dll -L/lib/mingw -lmingwex
> | build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o(.text+0x14f): In fu=
nction `_CheckFPErrors':
> | /home/software/programming/numeric/numarray/Src/_ufuncmodule.c:136: und=
efined reference to `_fetestexcept'
> | build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o(.text+0x17b):/home/=
software/programming/numeric/numarray/Src/_ufuncmodule.c:142: undefined ref=
erence to `_feclearexcept'
> | collect2: ld returned 1 exit status
> | error: command 'gcc' failed with exit status 1
> |=20
> | > gcc -shared -Wl,--enable-auto-image-base -march=3Dpentium3 -mcpu=3Dpe=
ntium4 -O2 -Wall -pipe build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o =
-L/usr/lib/python2.3/config -lpython2.3 -o build/lib.cygwin-1.5.5-i686-2.3/=
numarray/_ufunc.dll -L/lib/mingw -lmingwex
> `----
>=20
> That is, it does not work when called from setup.py. When I just copy
> 'n' paste the link statement to the command-line, it just works.(#$%)
>=20
> Any ideas??

You could try replacing gcc in order to dump the environment or perhaps
add a switch to run gcc in a more verbose mode and see if any
differences pop up.  distutils-sig?

Have you checked the #ifdef clause in _CheckFPErrors in _ufuncmodule.c
for cygwin/mingw?  Apparently I added it, and I wasn't sure if it was
valid to compile for cygwin and link against mingw.

One other thing:  HAS_UINT64 should work.

Regards,
Todd
=20
--=20
Todd Miller 			jm...@st...
STSCI / ESS / SSB

[Numpy-discussion] Re: Cygwin compilation

[<jo...@jo...>]

On 29 Sep 2003 17:05:09 -0400 Todd Miller wrote:

>> _ufunc.dll needs to be linked against /usr/lib/libmingwex.a. Doing
>> that manually seems to work fine.

Todd> In the file generate.py, a clause for sys.platform =3D=3D "cygwin?"
Todd> probably needs to be added. Then, define EXTRA_LINK_ARGS for
Todd> cygwin.

Ok, did that.
,----[cvs diff -u generate.py]
| Warning: No xauth data; using fake authentication data for X11 forwarding.
| Index: generate.py
| =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| RCS file: /cvsroot/numpy/numarray/generate.py,v
| retrieving revision 1.14
| diff -u -u -r1.14 generate.py
| --- generate.py 16 Sep 2003 20:02:41 -0000      1.14
| +++ generate.py 30 Sep 2003 08:33:38 -0000
| @@ -51,6 +51,9 @@
|      LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
|  elif sys.platform =3D=3D "win32":
|      LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 0, 0
| +elif sys.platform =3D=3D "cygwin":
| +    LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 0, 0
| +    EXTRA_LINK_ARGS +=3D ["-L/lib/mingw -lmingwex"]
|  elif sys.platform =3D=3D "darwin":
|      LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
|      EXTRA_COMPILE_ARGS.extend(["-Ddarwin"])
`----

Should work, but I get the following strange behavior:
,----
| > python setup.py build
| Using EXTRA_COMPILE_ARGS =3D []
| running build
| running build_py
| copying Lib/numinclude.py -> build/lib.cygwin-1.5.5-i686-2.3/numarray
| running build_ext
| building 'numarray._ufunc' extension
| gcc -shared -Wl,--enable-auto-image-base -march=3Dpentium3 -mcpu=3Dpentiu=
m4 -O2 -Wall -pipe build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o -L/u=
sr/lib/python2.3/config -lpython2.3 -o build/lib.cygwin-1.5.5-i686-2.3/numa=
rray/_ufunc.dll -L/lib/mingw -lmingwex
| build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o(.text+0x14f): In func=
tion `_CheckFPErrors':
| /home/software/programming/numeric/numarray/Src/_ufuncmodule.c:136: undef=
ined reference to `_fetestexcept'
| build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o(.text+0x17b):/home/so=
ftware/programming/numeric/numarray/Src/_ufuncmodule.c:142: undefined refer=
ence to `_feclearexcept'
| collect2: ld returned 1 exit status
| error: command 'gcc' failed with exit status 1
|=20
| > gcc -shared -Wl,--enable-auto-image-base -march=3Dpentium3 -mcpu=3Dpent=
ium4 -O2 -Wall -pipe build/temp.cygwin-1.5.5-i686-2.3/Src/_ufuncmodule.o -L=
/usr/lib/python2.3/config -lpython2.3 -o build/lib.cygwin-1.5.5-i686-2.3/nu=
marray/_ufunc.dll -L/lib/mingw -lmingwex
`----

That is, it does not work when called from setup.py. When I just copy
'n' paste the link statement to the command-line, it just works.(#$%)

Any ideas??


>> Is it save to use this mingw library in "normal" Cygwin programs?

Todd> I don't know. I didn't get any farther than this, perhaps not as
Todd> far. I got the impression that mingw was a minimal library
Todd> intended for porting gcc (but it has IEEE stuff), while the
Todd> cygwin libc is intended for real programs (but has no IEEE stuff
Todd> because it is a lightweight knock off of glibc used to bypass
Todd> the GPL).

Well, as I see it Cygwin is a Unix emulation layer for Windows,
whereas MINGW is a port of gcc and some other GNU tools to Windows
(not using Cygwin at all).

But looking around using it this way should be ok. Maybe someone who
knows cygwin better can speak up here? I would carbon-copy this email
to the cygwin list, but that is subscribers only nowadays:(



>> Moreover I have the follwoing test error:
>> ,----
>> | Failure in example: log10([1+1j])
>> | from line #2267 of numarray.numtest
>> | Expected: array([ 0.150515+0.34109409j])
>> | Got: array([ 0.150515+5.21807245j])
>> `----

Todd> One of our guys found a bug in the complex log10 function; both
Todd> the expected result and the implementation were changed.

Seems to be resolved.

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] Crash with numarray testall.py

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

I confirmed this as a problem under Windows and Linux, and also for 
Python-2.2.3 as well as Python-2.3.1.  

It should be pointed out that this is not a problem related to
Python-2.3.1, nor does the problem occur unless you try to use numarray
from it's own directory. 

For now, self-test/use numarray like this: 

> cd C:\somewhere_else 
> python 
>>> import numarray.testall as testall 
>>> testall.test() 
.. 
>>> import numarray 
.. 

I filed it as a bug on Source Forge. 

Todd 

On Thu, 2003-09-25 at 15:08, Colin J. Williams wrote: 
> 
> C:\Program Files\Python23\Lib\site-packages\numarray>python
> Python 2.3.1 (#47, Sep 23 2003, 23:47:32) [MSC v.1200 32 bit (Intel)] on 
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import testall
> 
> The 21K file created by Windows to contain information about the crash 
> is not readable.
> 
> Windows XP and numarray 0.7 used.
> 
> Colin W.
> 
> 
> 
> -------------------------------------------------------
> 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] numarray unfriendly to user defined types

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

On Sat, 2003-09-27 at 15:53, Colin J. Williams wrote:
> Tim,
> 
> Todd refers to your original post.  The only thing I've found is a 
> reference to a pre and post addition of zero, the latter was said not to 
> work.  Both work for me, see below:
> 
>  >>> zero= 0
>  >>> zero + _num.arange(5)
> array([0, 1, 2, 3, 4])
>  >>> _num.arange(5) + zero
> array([0, 1, 2, 3, 4])
> 
> If I'm barking up the wrong tree, could you point me to your original 
> posting in the archive please?
> 

It's not the wrong tree,  but there's more than one case:  objects which
look like numeric sequence work but always return numarrays,  objects
which do not look like a numeric sequence raise an exception.

Here's a link to the numpy-discussion-list archives on Source Forge:

http://sourceforge.net/mailarchive/forum.php?thread_id=3154046&forum_id=4890


> Colin W.
>  >>>
> Todd Miller wrote:
> 
> >On Fri, 2003-09-26 at 13:31, Colin J. Williams wrote:
> >  
> >
> >>Todd,
> >>
> >>This scheme seems rather complex.  The purpose isn't clear to me.
> >>
> >>What is the problem which this arrangement is intended to solve?
> >>    
> >>
> >
> >Bottom line, currently:  
> >	
> >numarray + another_class --> exception
> >
> >It would be nice if:  
> >
> >numarray + another_class --> another_class.__radd__(numarray)
> >
> >Also, look backward at Tim's original post on this subject.
> >
> >  
> >
> >>Could I suggest that some scheme along the lines of the Python PEP's be 
> >>used to set out the Why's and Wherefore's?
> >>
> >>    
> >>
> >Sounds good for next time.
> >
> >  
> >
> >>It might also be useful to copy this discussion to comp.lang.python as 
> >>that newsgroup has people experienced with classes.  
> >>    
> >>
> >
> >OK,  I'll stop being a chicken.  Everyone, get ready for the sound of a
> >pin dropping on c.l.py.
> >
> >  
> >
> >>The problem appears 
> >>to be Python related rather than a problem of numerical analysis.
> >>    
> >>
> >
> >Yes indeed.
> >
> >  
> >
> >>Colin W.
> >>
> >>Todd Miller wrote:
> >>
> >>    
> >>
> >>>I tried out DeferredToByNumArray yesterday morning and was able to get
> >>>it to work as planned with numarray and MA.  So yay!
> >>>
> >>>Yesterday afternoon,  I stopped by Perry's office for a final check, and
> >>>not surprisingly,  there are some aspects of this solution that we've
> >>>overlooked.  So not yay!
> >>>
> >>>Perry pointed out two ways that the DeferredToByNumArray scheme may fall
> >>>apart as our inheritance hierarchy becomes richer:
> >>>
> >>>1)  Imagine not one, but two independent subclasses of NumArray, each of
> >>>which want NumArray to defer to them.  Now imagine them trying to
> >>>inter-operate with each other.  In this case, the meaning of the
> >>>expression is determined by the order of the operands, so A+B and B+A
> >>>will either return an A or a B depending on the expression order.
> >>>
> >>>2)  Imagine again two subclasses of numarray, but this time imagine B as
> >>>a subclass of A.  Here again, both might want to defer to numarray, and
> >>>again, A+B and B+A return different types driven by the type order of
> >>>the expression.
> >>>
> >>>I don't have a solution yet, but am hopeful that more free candy will
> >>>fall from the sky... or YAGNI.  Perry pointed out that similar problems
> >>>exist for *any* Python class hierarchy, so we're not alone, and perhaps
> >>>should forget about this until it matters.  If someone sees an easy
> >>>fix,  now would be better than later.
> >>>
> >>>Todd
> >>>On Wed, 2003-09-24 at 19:55, Tim Hochberg wrote:
> >>> 
> >>>
> >>>      
> >>>
> >>>>Todd Miller wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>On Wed, 2003-09-24 at 18:27, Tim Hochberg wrote:
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Hi Todd,
> >>>>>>
> >>>>>>There are three ways to spell "defer to me" on the table (the precise 
> >>>>>>details of
> >>>>>>each spelling are, of course, still open for debate):
> >>>>>>
> >>>>>> 1.  numarray.defer_to(my_class)
> >>>>>>
> >>>>>> 2. class ArrayLike(numarray.DeferTo):
> >>>>>>       # ...
> >>>>>>
> >>>>>> 3. class ArrayLike:
> >>>>>>       _numarray_defer_to = True
> >>>>>>      # ...
> >>>>>>
> >>>>>>I'd prefer a non-registration solution since those are both 
> >>>>>>aesthetically displeasing and leave you open to the situation where a 
> >>>>>>class in module A gets registered by module B, but module C expects it 
> >>>>>>not to be registered and everything breaks. Not all that likely, I 
> >>>>>>admit, but let's avoid the registration version if we can.
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>I was picturing this as module A registering it's own classes only. 
> >>>>>Nevertheless, inverting the problem and distributing the registration as
> >>>>>you suggested is better.
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>The case you describe probably will describe the majority of actual use 
> >>>>cases, and in fact describes mine. I'm trying to think ahead a bit to 
> >>>>cases may encounter as start using NumArray more extensively. Let's hope 
> >>>>this solution still looks good in six months!
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>>The other two solutions are almost equivalent. The one case where 3 has 
> >>>>>>an edge over 2 is if I have an object (not a class), I could potentially 
> >>>>>>set a _numarray_defer_to on the object before passing it to numarray 
> >>>>>>without having to mess with the class
> >>>>>>of the object at all. YAGNI, though.
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>I was more concerned about the potential impact of lots of multiple
> >>>>>inheritance, but that's probably just my own personal blend of FUD.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>The advantage of 2 in my view is that it *does* force you to subclass. 
> >>>>>>With 3, there will be the temptation to poke into some other  module and 
> >>>>>>set _numarray_defer_to on some poor unsuspecting class. This has the 
> >>>>>>same disadvantage as 1, that it could confuse some other poor 
> >>>>>>unsuspecting module. The correct way to do get a deferred class from a 
> >>>>>>third party module is to import and subclass. This works with either 2 
> >>>>>>or 3::
> >>>>>>
> >>>>>>import A
> >>>>>>
> >>>>>>class Klass2(a.Klass, numarray.DeferTo):   #2
> >>>>>>   #...
> >>>>>>
> >>>>>>class Klass3(a.Klass): #3 the good way
> >>>>>>    _numarray_defer_to = True
> >>>>>>   # ...
> >>>>>>
> >>>>>> A.Klass._numarray_defer_to = True #3 the evil way.
> >>>>>>
> >>>>>>Version 2 is cleaner and encourages you to do the right thing, so I'd 
> >>>>>>prefer that solution.
> >>>>>>
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>Good enough for me.  If no one else has any comments, then
> >>>>>numarray.DeferTo is where I'll start implementing.  Tomorrow.
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>One more minor thing. I'm not sure tha DeferTo is ideal as the mix-in 
> >>>>class name. It was perfect for the registration function name, but I'm 
> >>>>not sure it's so clear whether the class or numarray is being deferred 
> >>>>to when you say numarray.DeferTo. DeferToMe is more descriptive, but 
> >>>>seems sort of slangy. DeferredTo is better than DeferTo, but still not 
> >>>>as descriptive as DeferToMe. numarray.DefersTo reads perfect as long as 
> >>>>numarray is included but is a disaster if you read it on your own.  
> >>>>Below I've put down all the ideas I could come up with
> >>>>
> >>>>class CustomArray(numarray.DeferTo)
> >>>>class CustomArray(numarray.DefersTo)
> >>>>class CustomArray(numarray.DeferredTo)
> >>>>class CustomArray(numarray.DeferToMe)
> >>>>class CustomArray(numarray.DeferredToByNumarray)
> >>>>class CustomArray(DeferTo)
> >>>>class CustomArray(DefersTo)
> >>>>class CustomArray(DeferredTo)
> >>>>class CustomArray(DeferToMe)
> >>>>class CustomArray(DeferredToByNumarray)
> >>>>
> >>>>For me it's a toss up between DefferedTo, DeferToMe and 
> >>>>DeferredToByNumarray. The first is a little lacking in descriptive 
> >>>>power, the second is slangy and the third is wordy.
> >>>>
> >>>>-tim
> >>>>
> >>>>[not that this matters much....]
> >>>>
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>>regards,
> >>>>>>
> >>>>>>-tim
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>Thanks again,
> >>>>>Todd
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>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
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>    
> >>
> 
> 
> 
> 
> -------------------------------------------------------
> 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] numarray unfriendly to user defined types

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

Tim,

Todd refers to your original post.  The only thing I've found is a 
reference to a pre and post addition of zero, the latter was said not to 
work.  Both work for me, see below:

 >>> zero= 0
 >>> zero + _num.arange(5)
array([0, 1, 2, 3, 4])
 >>> _num.arange(5) + zero
array([0, 1, 2, 3, 4])

If I'm barking up the wrong tree, could you point me to your original 
posting in the archive please?

Colin W.
 >>>
Todd Miller wrote:

>On Fri, 2003-09-26 at 13:31, Colin J. Williams wrote:
>  
>
>>Todd,
>>
>>This scheme seems rather complex.  The purpose isn't clear to me.
>>
>>What is the problem which this arrangement is intended to solve?
>>    
>>
>
>Bottom line, currently:  
>	
>numarray + another_class --> exception
>
>It would be nice if:  
>
>numarray + another_class --> another_class.__radd__(numarray)
>
>Also, look backward at Tim's original post on this subject.
>
>  
>
>>Could I suggest that some scheme along the lines of the Python PEP's be 
>>used to set out the Why's and Wherefore's?
>>
>>    
>>
>Sounds good for next time.
>
>  
>
>>It might also be useful to copy this discussion to comp.lang.python as 
>>that newsgroup has people experienced with classes.  
>>    
>>
>
>OK,  I'll stop being a chicken.  Everyone, get ready for the sound of a
>pin dropping on c.l.py.
>
>  
>
>>The problem appears 
>>to be Python related rather than a problem of numerical analysis.
>>    
>>
>
>Yes indeed.
>
>  
>
>>Colin W.
>>
>>Todd Miller wrote:
>>
>>    
>>
>>>I tried out DeferredToByNumArray yesterday morning and was able to get
>>>it to work as planned with numarray and MA.  So yay!
>>>
>>>Yesterday afternoon,  I stopped by Perry's office for a final check, and
>>>not surprisingly,  there are some aspects of this solution that we've
>>>overlooked.  So not yay!
>>>
>>>Perry pointed out two ways that the DeferredToByNumArray scheme may fall
>>>apart as our inheritance hierarchy becomes richer:
>>>
>>>1)  Imagine not one, but two independent subclasses of NumArray, each of
>>>which want NumArray to defer to them.  Now imagine them trying to
>>>inter-operate with each other.  In this case, the meaning of the
>>>expression is determined by the order of the operands, so A+B and B+A
>>>will either return an A or a B depending on the expression order.
>>>
>>>2)  Imagine again two subclasses of numarray, but this time imagine B as
>>>a subclass of A.  Here again, both might want to defer to numarray, and
>>>again, A+B and B+A return different types driven by the type order of
>>>the expression.
>>>
>>>I don't have a solution yet, but am hopeful that more free candy will
>>>fall from the sky... or YAGNI.  Perry pointed out that similar problems
>>>exist for *any* Python class hierarchy, so we're not alone, and perhaps
>>>should forget about this until it matters.  If someone sees an easy
>>>fix,  now would be better than later.
>>>
>>>Todd
>>>On Wed, 2003-09-24 at 19:55, Tim Hochberg wrote:
>>> 
>>>
>>>      
>>>
>>>>Todd Miller wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>On Wed, 2003-09-24 at 18:27, Tim Hochberg wrote:
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>Hi Todd,
>>>>>>
>>>>>>There are three ways to spell "defer to me" on the table (the precise 
>>>>>>details of
>>>>>>each spelling are, of course, still open for debate):
>>>>>>
>>>>>> 1.  numarray.defer_to(my_class)
>>>>>>
>>>>>> 2. class ArrayLike(numarray.DeferTo):
>>>>>>       # ...
>>>>>>
>>>>>> 3. class ArrayLike:
>>>>>>       _numarray_defer_to = True
>>>>>>      # ...
>>>>>>
>>>>>>I'd prefer a non-registration solution since those are both 
>>>>>>aesthetically displeasing and leave you open to the situation where a 
>>>>>>class in module A gets registered by module B, but module C expects it 
>>>>>>not to be registered and everything breaks. Not all that likely, I 
>>>>>>admit, but let's avoid the registration version if we can.
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>I was picturing this as module A registering it's own classes only. 
>>>>>Nevertheless, inverting the problem and distributing the registration as
>>>>>you suggested is better.
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>The case you describe probably will describe the majority of actual use 
>>>>cases, and in fact describes mine. I'm trying to think ahead a bit to 
>>>>cases may encounter as start using NumArray more extensively. Let's hope 
>>>>this solution still looks good in six months!
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>>The other two solutions are almost equivalent. The one case where 3 has 
>>>>>>an edge over 2 is if I have an object (not a class), I could potentially 
>>>>>>set a _numarray_defer_to on the object before passing it to numarray 
>>>>>>without having to mess with the class
>>>>>>of the object at all. YAGNI, though.
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>I was more concerned about the potential impact of lots of multiple
>>>>>inheritance, but that's probably just my own personal blend of FUD.
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>The advantage of 2 in my view is that it *does* force you to subclass. 
>>>>>>With 3, there will be the temptation to poke into some other  module and 
>>>>>>set _numarray_defer_to on some poor unsuspecting class. This has the 
>>>>>>same disadvantage as 1, that it could confuse some other poor 
>>>>>>unsuspecting module. The correct way to do get a deferred class from a 
>>>>>>third party module is to import and subclass. This works with either 2 
>>>>>>or 3::
>>>>>>
>>>>>>import A
>>>>>>
>>>>>>class Klass2(a.Klass, numarray.DeferTo):   #2
>>>>>>   #...
>>>>>>
>>>>>>class Klass3(a.Klass): #3 the good way
>>>>>>    _numarray_defer_to = True
>>>>>>   # ...
>>>>>>
>>>>>> A.Klass._numarray_defer_to = True #3 the evil way.
>>>>>>
>>>>>>Version 2 is cleaner and encourages you to do the right thing, so I'd 
>>>>>>prefer that solution.
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Good enough for me.  If no one else has any comments, then
>>>>>numarray.DeferTo is where I'll start implementing.  Tomorrow.
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>One more minor thing. I'm not sure tha DeferTo is ideal as the mix-in 
>>>>class name. It was perfect for the registration function name, but I'm 
>>>>not sure it's so clear whether the class or numarray is being deferred 
>>>>to when you say numarray.DeferTo. DeferToMe is more descriptive, but 
>>>>seems sort of slangy. DeferredTo is better than DeferTo, but still not 
>>>>as descriptive as DeferToMe. numarray.DefersTo reads perfect as long as 
>>>>numarray is included but is a disaster if you read it on your own.  
>>>>Below I've put down all the ideas I could come up with
>>>>
>>>>class CustomArray(numarray.DeferTo)
>>>>class CustomArray(numarray.DefersTo)
>>>>class CustomArray(numarray.DeferredTo)
>>>>class CustomArray(numarray.DeferToMe)
>>>>class CustomArray(numarray.DeferredToByNumarray)
>>>>class CustomArray(DeferTo)
>>>>class CustomArray(DefersTo)
>>>>class CustomArray(DeferredTo)
>>>>class CustomArray(DeferToMe)
>>>>class CustomArray(DeferredToByNumarray)
>>>>
>>>>For me it's a toss up between DefferedTo, DeferToMe and 
>>>>DeferredToByNumarray. The first is a little lacking in descriptive 
>>>>power, the second is slangy and the third is wordy.
>>>>
>>>>-tim
>>>>
>>>>[not that this matters much....]
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>>regards,
>>>>>>
>>>>>>-tim
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Thanks again,
>>>>>Todd
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>
>>>>-------------------------------------------------------
>>>>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
>>>>   
>>>>
>>>>        
>>>>
>>    
>>

Re: [Numpy-discussion] numarray unfriendly to user defined types

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

Todd,

This scheme seems rather complex.  The purpose isn't clear to me.

What is the problem which this arrangement is intended to solve?

Could I suggest that some scheme along the lines of the Python PEP's be 
used to set out the Why's and Wherefore's?

It might also be useful to copy this discussion to comp.lang.python as 
that newsgroup has people experienced with classes.  The problem appears 
to be Python related rather than a problem of numerical analysis.

Colin W.

Todd Miller wrote:

>I tried out DeferredToByNumArray yesterday morning and was able to get
>it to work as planned with numarray and MA.  So yay!
>
>Yesterday afternoon,  I stopped by Perry's office for a final check, and
>not surprisingly,  there are some aspects of this solution that we've
>overlooked.  So not yay!
>
>Perry pointed out two ways that the DeferredToByNumArray scheme may fall
>apart as our inheritance hierarchy becomes richer:
>
>1)  Imagine not one, but two independent subclasses of NumArray, each of
>which want NumArray to defer to them.  Now imagine them trying to
>inter-operate with each other.  In this case, the meaning of the
>expression is determined by the order of the operands, so A+B and B+A
>will either return an A or a B depending on the expression order.
>
>2)  Imagine again two subclasses of numarray, but this time imagine B as
>a subclass of A.  Here again, both might want to defer to numarray, and
>again, A+B and B+A return different types driven by the type order of
>the expression.
>
>I don't have a solution yet, but am hopeful that more free candy will
>fall from the sky... or YAGNI.  Perry pointed out that similar problems
>exist for *any* Python class hierarchy, so we're not alone, and perhaps
>should forget about this until it matters.  If someone sees an easy
>fix,  now would be better than later.
>
>Todd
>On Wed, 2003-09-24 at 19:55, Tim Hochberg wrote:
>  
>
>>Todd Miller wrote:
>>
>>    
>>
>>>On Wed, 2003-09-24 at 18:27, Tim Hochberg wrote:
>>> 
>>>
>>>      
>>>
>>>>Hi Todd,
>>>>
>>>>There are three ways to spell "defer to me" on the table (the precise 
>>>>details of
>>>>each spelling are, of course, still open for debate):
>>>>
>>>>  1.  numarray.defer_to(my_class)
>>>>
>>>>  2. class ArrayLike(numarray.DeferTo):
>>>>        # ...
>>>>
>>>>  3. class ArrayLike:
>>>>        _numarray_defer_to = True
>>>>       # ...
>>>>
>>>>I'd prefer a non-registration solution since those are both 
>>>>aesthetically displeasing and leave you open to the situation where a 
>>>>class in module A gets registered by module B, but module C expects it 
>>>>not to be registered and everything breaks. Not all that likely, I 
>>>>admit, but let's avoid the registration version if we can.
>>>>   
>>>>
>>>>        
>>>>
>>>I was picturing this as module A registering it's own classes only. 
>>>Nevertheless, inverting the problem and distributing the registration as
>>>you suggested is better.
>>> 
>>>
>>>      
>>>
>>The case you describe probably will describe the majority of actual use 
>>cases, and in fact describes mine. I'm trying to think ahead a bit to 
>>cases may encounter as start using NumArray more extensively. Let's hope 
>>this solution still looks good in six months!
>>
>>    
>>
>>>>The other two solutions are almost equivalent. The one case where 3 has 
>>>>an edge over 2 is if I have an object (not a class), I could potentially 
>>>>set a _numarray_defer_to on the object before passing it to numarray 
>>>>without having to mess with the class
>>>>of the object at all. YAGNI, though.
>>>>   
>>>>
>>>>        
>>>>
>>>I was more concerned about the potential impact of lots of multiple
>>>inheritance, but that's probably just my own personal blend of FUD.
>>>
>>> 
>>>
>>>      
>>>
>>>>The advantage of 2 in my view is that it *does* force you to subclass. 
>>>>With 3, there will be the temptation to poke into some other  module and 
>>>>set _numarray_defer_to on some poor unsuspecting class. This has the 
>>>>same disadvantage as 1, that it could confuse some other poor 
>>>>unsuspecting module. The correct way to do get a deferred class from a 
>>>>third party module is to import and subclass. This works with either 2 
>>>>or 3::
>>>>
>>>> import A
>>>>
>>>> class Klass2(a.Klass, numarray.DeferTo):   #2
>>>>    #...
>>>>
>>>> class Klass3(a.Klass): #3 the good way
>>>>     _numarray_defer_to = True
>>>>    # ...
>>>>
>>>>  A.Klass._numarray_defer_to = True #3 the evil way.
>>>>
>>>>Version 2 is cleaner and encourages you to do the right thing, so I'd 
>>>>prefer that solution.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>Good enough for me.  If no one else has any comments, then
>>>numarray.DeferTo is where I'll start implementing.  Tomorrow.
>>> 
>>>
>>>      
>>>
>>One more minor thing. I'm not sure tha DeferTo is ideal as the mix-in 
>>class name. It was perfect for the registration function name, but I'm 
>>not sure it's so clear whether the class or numarray is being deferred 
>>to when you say numarray.DeferTo. DeferToMe is more descriptive, but 
>>seems sort of slangy. DeferredTo is better than DeferTo, but still not 
>>as descriptive as DeferToMe. numarray.DefersTo reads perfect as long as 
>>numarray is included but is a disaster if you read it on your own.  
>>Below I've put down all the ideas I could come up with
>>
>>class CustomArray(numarray.DeferTo)
>>class CustomArray(numarray.DefersTo)
>>class CustomArray(numarray.DeferredTo)
>>class CustomArray(numarray.DeferToMe)
>>class CustomArray(numarray.DeferredToByNumarray)
>>class CustomArray(DeferTo)
>>class CustomArray(DefersTo)
>>class CustomArray(DeferredTo)
>>class CustomArray(DeferToMe)
>>class CustomArray(DeferredToByNumarray)
>>
>>For me it's a toss up between DefferedTo, DeferToMe and 
>>DeferredToByNumarray. The first is a little lacking in descriptive 
>>power, the second is slangy and the third is wordy.
>>
>>-tim
>>
>>[not that this matters much....]
>>
>>
>>    
>>
>>>>regards,
>>>>
>>>>-tim
>>>>   
>>>>
>>>>        
>>>>
>>>Thanks again,
>>>Todd
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>
>>
>>
>>-------------------------------------------------------
>>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] Cygwin compilation

[<jo...@jo...>]

I just compiled/installed numarray-0.7 on (latest) Cygwin.

_ufunc.dll needs to be linked against /usr/lib/libmingwex.a. Doing
that manually seems to work fine. Adding it to the setup files is not
as simple, as libnumarray.dll does not link any more as some wrong
functions seem to be picked up from the MINGW library as well (and the
pow cannot be resolved. Explicitely adding -lm does not help).

How is this planned to work. Where needs the sequence
"-L/usr/lib/mingw -lmingwex" be put?

Is it save to use this mingw library in "normal" Cygwin programs?

Same happens with cvs HEAD.


Moreover I have the follwoing test error:
,----
| Failure in example: log10([1+1j])
| from line #2267 of numarray.numtest
| Expected: array([ 0.150515+0.34109409j])
| Got: array([ 0.150515+5.21807245j])
`----

Greetings,
Jochen
--=20
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert=E9, =C9galit=E9, Fraternit=E9                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: [Numpy-discussion] numarray unfriendly to user defined types

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

On Fri, 2003-09-26 at 13:31, Colin J. Williams wrote:
> Todd,
> 
> This scheme seems rather complex.  The purpose isn't clear to me.
> 
> What is the problem which this arrangement is intended to solve?

Bottom line, currently:  
	
numarray + another_class --> exception

It would be nice if:  

numarray + another_class --> another_class.__radd__(numarray)

Also, look backward at Tim's original post on this subject.

> 
> Could I suggest that some scheme along the lines of the Python PEP's be 
> used to set out the Why's and Wherefore's?
> 
Sounds good for next time.

> It might also be useful to copy this discussion to comp.lang.python as 
> that newsgroup has people experienced with classes.  

OK,  I'll stop being a chicken.  Everyone, get ready for the sound of a
pin dropping on c.l.py.

> The problem appears 
> to be Python related rather than a problem of numerical analysis.

Yes indeed.

> 
> Colin W.
> 
> Todd Miller wrote:
> 
> >I tried out DeferredToByNumArray yesterday morning and was able to get
> >it to work as planned with numarray and MA.  So yay!
> >
> >Yesterday afternoon,  I stopped by Perry's office for a final check, and
> >not surprisingly,  there are some aspects of this solution that we've
> >overlooked.  So not yay!
> >
> >Perry pointed out two ways that the DeferredToByNumArray scheme may fall
> >apart as our inheritance hierarchy becomes richer:
> >
> >1)  Imagine not one, but two independent subclasses of NumArray, each of
> >which want NumArray to defer to them.  Now imagine them trying to
> >inter-operate with each other.  In this case, the meaning of the
> >expression is determined by the order of the operands, so A+B and B+A
> >will either return an A or a B depending on the expression order.
> >
> >2)  Imagine again two subclasses of numarray, but this time imagine B as
> >a subclass of A.  Here again, both might want to defer to numarray, and
> >again, A+B and B+A return different types driven by the type order of
> >the expression.
> >
> >I don't have a solution yet, but am hopeful that more free candy will
> >fall from the sky... or YAGNI.  Perry pointed out that similar problems
> >exist for *any* Python class hierarchy, so we're not alone, and perhaps
> >should forget about this until it matters.  If someone sees an easy
> >fix,  now would be better than later.
> >
> >Todd
> >On Wed, 2003-09-24 at 19:55, Tim Hochberg wrote:
> >  
> >
> >>Todd Miller wrote:
> >>
> >>    
> >>
> >>>On Wed, 2003-09-24 at 18:27, Tim Hochberg wrote:
> >>> 
> >>>
> >>>      
> >>>
> >>>>Hi Todd,
> >>>>
> >>>>There are three ways to spell "defer to me" on the table (the precise 
> >>>>details of
> >>>>each spelling are, of course, still open for debate):
> >>>>
> >>>>  1.  numarray.defer_to(my_class)
> >>>>
> >>>>  2. class ArrayLike(numarray.DeferTo):
> >>>>        # ...
> >>>>
> >>>>  3. class ArrayLike:
> >>>>        _numarray_defer_to = True
> >>>>       # ...
> >>>>
> >>>>I'd prefer a non-registration solution since those are both 
> >>>>aesthetically displeasing and leave you open to the situation where a 
> >>>>class in module A gets registered by module B, but module C expects it 
> >>>>not to be registered and everything breaks. Not all that likely, I 
> >>>>admit, but let's avoid the registration version if we can.
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>I was picturing this as module A registering it's own classes only. 
> >>>Nevertheless, inverting the problem and distributing the registration as
> >>>you suggested is better.
> >>> 
> >>>
> >>>      
> >>>
> >>The case you describe probably will describe the majority of actual use 
> >>cases, and in fact describes mine. I'm trying to think ahead a bit to 
> >>cases may encounter as start using NumArray more extensively. Let's hope 
> >>this solution still looks good in six months!
> >>
> >>    
> >>
> >>>>The other two solutions are almost equivalent. The one case where 3 has 
> >>>>an edge over 2 is if I have an object (not a class), I could potentially 
> >>>>set a _numarray_defer_to on the object before passing it to numarray 
> >>>>without having to mess with the class
> >>>>of the object at all. YAGNI, though.
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>I was more concerned about the potential impact of lots of multiple
> >>>inheritance, but that's probably just my own personal blend of FUD.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>The advantage of 2 in my view is that it *does* force you to subclass. 
> >>>>With 3, there will be the temptation to poke into some other  module and 
> >>>>set _numarray_defer_to on some poor unsuspecting class. This has the 
> >>>>same disadvantage as 1, that it could confuse some other poor 
> >>>>unsuspecting module. The correct way to do get a deferred class from a 
> >>>>third party module is to import and subclass. This works with either 2 
> >>>>or 3::
> >>>>
> >>>> import A
> >>>>
> >>>> class Klass2(a.Klass, numarray.DeferTo):   #2
> >>>>    #...
> >>>>
> >>>> class Klass3(a.Klass): #3 the good way
> >>>>     _numarray_defer_to = True
> >>>>    # ...
> >>>>
> >>>>  A.Klass._numarray_defer_to = True #3 the evil way.
> >>>>
> >>>>Version 2 is cleaner and encourages you to do the right thing, so I'd 
> >>>>prefer that solution.
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>Good enough for me.  If no one else has any comments, then
> >>>numarray.DeferTo is where I'll start implementing.  Tomorrow.
> >>> 
> >>>
> >>>      
> >>>
> >>One more minor thing. I'm not sure tha DeferTo is ideal as the mix-in 
> >>class name. It was perfect for the registration function name, but I'm 
> >>not sure it's so clear whether the class or numarray is being deferred 
> >>to when you say numarray.DeferTo. DeferToMe is more descriptive, but 
> >>seems sort of slangy. DeferredTo is better than DeferTo, but still not 
> >>as descriptive as DeferToMe. numarray.DefersTo reads perfect as long as 
> >>numarray is included but is a disaster if you read it on your own.  
> >>Below I've put down all the ideas I could come up with
> >>
> >>class CustomArray(numarray.DeferTo)
> >>class CustomArray(numarray.DefersTo)
> >>class CustomArray(numarray.DeferredTo)
> >>class CustomArray(numarray.DeferToMe)
> >>class CustomArray(numarray.DeferredToByNumarray)
> >>class CustomArray(DeferTo)
> >>class CustomArray(DefersTo)
> >>class CustomArray(DeferredTo)
> >>class CustomArray(DeferToMe)
> >>class CustomArray(DeferredToByNumarray)
> >>
> >>For me it's a toss up between DefferedTo, DeferToMe and 
> >>DeferredToByNumarray. The first is a little lacking in descriptive 
> >>power, the second is slangy and the third is wordy.
> >>
> >>-tim
> >>
> >>[not that this matters much....]
> >>
> >>
> >>    
> >>
> >>>>regards,
> >>>>
> >>>>-tim
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>Thanks again,
> >>>Todd
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>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] numarray incompatibility: searchsorted

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

I logged this on Source Forge.  Thanks for the comments.

Todd

On Fri, 2003-09-26 at 13:06, Tim Hochberg wrote:
> 
> There are some compatibility and doc issues and perhaps a bug in 
> numarray.searchsorted. The compatibility issue is that 
> Numeric.searchsorted(a, v) accepts either a sequence or scalar value for 
> v. Numarray.searchsorted accepts only sequence values.
> 
> Second, the doc issue. The docstring for numarray.searchsorted states::
> 
>   searchsorted(bins, values)
>     searchsort(bins, values) returns the array of greatest indices 'i'
>     such that each values[i] <= bins[i].
> 
> I assume that should really read something more like::
> 
>   searchsorted(bins, values)
>     searchsort(bins, values) returns the array A[j] of greatest indices 'i'
>     such that each values[j] <= bins[i].
> 
> Third, the possible bug:
> 
> # na = numarray, np = NumPy
>  >>> na.searchsorted([1,2,3,4], [2.5, 3.5])
> array([1, 2])
>  >>> np.searchsorted([1,2,3,4], [2.5, 3.5])
> array([2, 3])
> 
> Hmmm. It appears that numarray result does match the numarray docs, (at 
> least as I read them), but I like the Numeric behaviour better.  The 
> Numeric behaviour also matches the behaviour of the bisect module, which 
> is described as::
> 
>     bisect = bisect_right(a, x, lo=0, hi=None)
>         Return the index where to insert item x in list a, assuming a is 
> sorted.
> 
>         The return value i is such that all e in a[:i] have e <= x, and 
> all e in
>         a[i:] have e > x.  So if x already appears in the list, i points 
> just
>         beyond the rightmost x already there.
> 
>         Optional args lo (default 0) and hi (default len(a)) bound the
>         slice of a to be searched.
> 
> I'd recomend matching the behaviour of the two existing modules (bisect 
> and Numeric).
> 
> -tim
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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

[Numpy-discussion] numarray incompatibility: searchsorted

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

There are some compatibility and doc issues and perhaps a bug in 
numarray.searchsorted. The compatibility issue is that 
Numeric.searchsorted(a, v) accepts either a sequence or scalar value for 
v. Numarray.searchsorted accepts only sequence values.

Second, the doc issue. The docstring for numarray.searchsorted states::

  searchsorted(bins, values)
    searchsort(bins, values) returns the array of greatest indices 'i'
    such that each values[i] <= bins[i].

I assume that should really read something more like::

  searchsorted(bins, values)
    searchsort(bins, values) returns the array A[j] of greatest indices 'i'
    such that each values[j] <= bins[i].

Third, the possible bug:

# na = numarray, np = NumPy
 >>> na.searchsorted([1,2,3,4], [2.5, 3.5])
array([1, 2])
 >>> np.searchsorted([1,2,3,4], [2.5, 3.5])
array([2, 3])

Hmmm. It appears that numarray result does match the numarray docs, (at 
least as I read them), but I like the Numeric behaviour better.  The 
Numeric behaviour also matches the behaviour of the bisect module, which 
is described as::

    bisect = bisect_right(a, x, lo=0, hi=None)
        Return the index where to insert item x in list a, assuming a is 
sorted.

        The return value i is such that all e in a[:i] have e <= x, and 
all e in
        a[i:] have e > x.  So if x already appears in the list, i points 
just
        beyond the rightmost x already there.

        Optional args lo (default 0) and hi (default len(a)) bound the
        slice of a to be searched.

I'd recomend matching the behaviour of the two existing modules (bisect 
and Numeric).

-tim